Differentiated services

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Differentiated services or DiffServ is a computer networking architecture that specifies a simple and scalable mechanism for classifying and managing network traffic and providing quality of service (QoS) on modern IP networks. DiffServ can, for example, be used to provide low-latency to critical network traffic such as voice or streaming media while providing simple best-effort service to non-critical services such as web traffic or file transfers.

DiffServ uses a 6-bit differentiated services code point (DSCP) in the 8-bit differentiated services field (DS field) in the IP header for packet classification purposes. The DS field replaces the outdated IPv4 TOS field.[1]

Background[edit]

Modern data networks carry many different types of services, including voice, video, streaming music, web pages and email. Many of the proposed QoS mechanisms that allowed these services to co-exist were both complex and failed to scale to meet the demands of the public Internet. In December 1998, the IETF published RFC 2474 - Definition of the Differentiated services field (DS field) in the IPv4 and IPv6 headers, which replaced the IPv4 TOS field with the DS field. In the DS field, a range of eight values (Class Selectors) is used for backward compatibility with the IP precedence specification in the former TOS field. Today, DiffServ has largely supplanted TOS and other layer-3 QoS mechanisms, such as integrated services (IntServ), as the primary architecture routers use to provide QoS.

Traffic management mechanisms[edit]

DiffServ is a coarse-grained, class-based mechanism for traffic management. In contrast, IntServ is a fine-grained, flow-based mechanism. DiffServ relies on a mechanism to classify and mark packets as belonging to a specific class. DiffServ-aware routers implement per-hop behaviors (PHBs), which define the packet-forwarding properties associated with a class of traffic. Different PHBs may be defined to offer, for example, low-loss or low-latency service.

Rather than differentiating network traffic based on the requirements of an individual flow, DiffServ operates on the principle of traffic classification, placing each data packet into one of a limited number of traffic classes. Each router on the network is then configured to differentiate traffic based on its class. Each traffic class can be managed differently, ensuring preferential treatment for higher-priority traffic on the network. The premise of Diffserv is that complicated functions such as packet classification and policing can be carried out at the edge of the network by edge routers. Since no classification and policing is required in the core router, functionality there can then be kept simple. Core routers simply apply PHB treatment to packets based on their markings. PHB treatment is achieved by core routers using a combination of scheduling policy and queue management policy.

A group of routers that implement common, administratively defined DiffServ policies are referred to as a DiffServ domain.[2]

While DiffServ does recommend a standardized set of traffic classes,[3] the DiffServ architecture does not incorporate predetermined judgments of what types of traffic should be given priority treatment. DiffServ simply provides a framework to allow classification and differentiated treatment. The standard traffic classes (discussed below) serve to simplify interoperability between different networks and different vendors' equipment.

Classification and marking[edit]

Network traffic entering a DiffServ domain is subjected to classification and conditioning. A traffic classifier may inspect many different parameters in incoming packets, such as source address, destination address or traffic type and assign individual packets to a specific traffic class. Traffic classifiers may honor any DiffServ markings in received packets or may elect to ignore or override those markings. For tight control over volumes and type of traffic in a given class, a network operator may choose not to honor markings at the ingress to the DiffServ domain. Traffic in each class may be further conditioned by subjecting the traffic to rate limiters, traffic policers or shapers.[4]

The per-hop behavior is determined by the DS field in the IP header. The DS field contains the 6-bit DSCP value.[5] Explicit Congestion Notification (ECN) occupies the least-significant 2 bits of the IPv4 TOS field and IPv6 traffic class (TC) field .[6][7][8]

In theory, a network could have up to 64 different traffic classes using the 64 available DSCP values. The DiffServ RFCs recommend, but do not require, certain encodings. This gives a network operator great flexibility in defining traffic classes. In practice, however, most networks use the following commonly defined per-hop behaviors:

  • Default Forwarding (DF) PHB — which is typically best-effort traffic
  • Expedited Forwarding (EF) PHB — dedicated to low-loss, low-latency traffic
  • Assured Forwarding (AF) PHB — gives assurance of delivery under prescribed conditions
  • Class Selector PHBs — which maintain backward compatibility with the IP precedence field.

Default Forwarding[edit]

A default forwarding (DF) PHB is the only required behavior. Essentially, any traffic that does not meet the requirements of any of the other defined classes uses DF. Typically, DF has best-effort forwarding characteristics. The recommended DSCP for DF is 0.[3]

Expedited Forwarding[edit]

The IETF defines Expedited Forwarding (EF) behavior in RFC 3246. The EF PHB has the characteristics of low delay, low loss and low jitter. These characteristics are suitable for voice, video and other realtime services. EF traffic is often given strict priority queuing above all other traffic classes. Because an overload of EF traffic will cause queuing delays and affect the jitter and delay tolerances within the class, admission control, traffic policing and other mechanisms may be applied to EF traffic. The recommended DSCP for EF is 101110B (46 or 2EH).

Voice Admit[edit]

The IETF defines Voice Admit behavior in RFC 5865. The Voice Admit PHB has identical characteristics to the Expedited Forwarding PHB. However Voice Admit traffic is also admitted by the network using a Call Admission Control (CAC) procedure. The recommended DSCP for voice admit is 101100B (44 or 2CH).

Assured Forwarding[edit]

The IETF defines the Assured Forwarding (AF) behavior in RFC 2597 and RFC 3260. Assured forwarding allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate. Traffic that exceeds the subscription rate faces a higher probability of being dropped if congestion occurs.

The AF behavior group defines four separate AF classes where all have the same priority. Within each class, packets are given a drop precedence (high, medium or low, where higher precedence means more dropping). The combination of classes and drop precedence yields twelve separate DSCP encodings from AF11 through AF43 (see table).

Assured Forwarding behavior group
Class 1 Class 2 Class 3 Class 4
Low drop probability AF11 (DSCP 10) AF21 (DSCP 18) AF31 (DSCP 26) AF41 (DSCP 34)
Med drop probability AF12 (DSCP 12) AF22 (DSCP 20) AF32 (DSCP 28) AF42 (DSCP 36)
High drop probability AF13 (DSCP 14) AF23 (DSCP 22) AF33 (DSCP 30) AF43 (DSCP 38)

Some measure of priority and proportional fairness is defined between traffic in different classes. Should congestion occur between classes, the traffic in the higher class is given priority. Rather than using strict priority queuing, more balanced queue servicing algorithms such as fair queuing or weighted fair queuing are likely to be used. If congestion occurs within a class, the packets with the higher drop precedence are discarded first. To prevent issues associated with tail drop, more sophisticated drop selection algorithms such as random early detection are often used.

Class Selector[edit]

Prior to DiffServ, IPv4 networks could use the IP precedence field in the TOS byte of the IPv4 header to mark priority traffic. The TOS octet and IP precedence were not widely used. The IETF agreed to reuse the TOS octet as the DS field for DiffServ networks. In order to maintain backward compatibility with network devices that still use the Precedence field, DiffServ defines the Class Selector PHB.

The Class Selector code points are of the binary form 'xxx000'. The first three bits are the IP precedence bits. Each IP precedence value can be mapped into a DiffServ class. CS0 maps to IP precedence 0, CS1 to IP precedence 1, and so on. If a packet is received from a non-DiffServ-aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class Selector code point.

There are many misleading informations of CS3 and CS5 on the internet. Please refer to the RFC 4594[9]. CS3 for CallControl is only being used by Cisco and also lacks the 802.11e Guidelines, refer to [10] chapter 4.2.2

The Signaling service class is RECOMMENDED for delay-sensitive client-server (traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between IP phone and soft-switch, soft-client and soft-switch, and media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. The RECOMMENDED DSCP marking for Signaling is CS5.

Service Class Markings
Service Class Name DSCP Name DSCP Value Application Examples
Network Control CS6 110000 Network routing
Telephony EF 101110 IP Telephony bearer
Signaling CS5 101000 IP Telephony signaling
Multimedia

Conferencing

AF41,AF42

AF43

100010,100100

100110

H.323/V2 video

conferencing (adaptive)

Real-Time

Interactive

CS4 100000 Video conferencing and

Interactive gaming

Multimedia

Streaming

AF31,AF32

AF33

011010,0111000

011110

Streaming video and

audio on demand

Broadcast Video CS3 011000 Broadcast TV & live events
Low-Latency

Data

AF21,AF22

AF23

010010,010100

010110

Client/server transactions

Web-based ordering

OAM CS2 010000 OAM&P
High-Throughput

Data

AF11,AF12

AF13

001010,001100

001110

Store and forward

applications

Standard DF (CS0) 000000 Undifferentiated

applications

Low-Priority

Data

CS1 001000 Any flow that has no BW

assurance

An overview of the correspondent RFC´s taken from RFC 4594:

RFC 4594
Service

Class

DSCP Conditioning at

DS Edge

PHB

Used

Queuing AQM
Network Control CS6 See Section 3.1 RFC2474 Rate Yes
Telephony EF Police using sr+bs RFC3246 Priority No
Signaling CS5 Police using sr+bs RFC2474 Rate No
Multimedia

Conferencing

AF41

AF42

AF43

Using two-rate,

three-color marker

(such as RFC 2698)

RFC2597 Rate Yes

per

DSCP

Real-Time

Interactive

CS4 Police using sr+bs RFC2474 Rate No
Multimedia

Streaming

AF31

AF32

AF33

Using two-rate,

three-color marker

(such as RFC 2698)

RFC2597 Rate Yes

per

DSCP

Broadcast Video CS3 Police using sr+bs RFC2474 Rate No
Low-

Latency Data

AF21

AF22

AF23

Using two-rate,

three-color marker

(such as RFC 2698)

RFC2597 Rate Yes

per

DSCP

OAM CS2 Police using sr+bs RFC2474 Rate Yes
High-

Throughput Data

AF11

AF12

AF13

Using two-rate,

three-color marker

(such as RFC 2698)

RFC2597 Rate Yes

per

DSCP

Standard DF Not applicable RFC2474 Rate Yes
Low-Priority

Data

CS1 Not applicable RFC3662 Rate Yes

Commonly used DSCP values[edit]

List of the commonly used DSCP values described in RFC 2475.

Commonly used DSCP values
DSCP value Hex value Decimal value Meaning Drop probability Equivalent IP precedence value
101 110 0x2e 46 Expedited forwarding (EF) N/A 101 Critical
000 000 0x00 0 Best effort N/A 000 - Routine
001 010 0x0a 10 AF11 Low 001 - Priority
001 100 0x0c 12 AF12 Medium 001 - Priority
001 110 0x0e 14 AF13 High 001 - Priority
010 010 0x12 18 AF21 Low 010 - Immediate
010 100 0x14 20 AF22 Medium 010 - Immediate
010 110 0x16 22 AF23 High 010 - Immediate
011 010 0x1a 26 AF31 Low 011 - Flash
011 100 0x1c 28 AF32 Medium 011 - Flash
011 110 0x1e 30 AF33 High 011 - Flash
100 010 0x22 34 AF41 Low 100 - Flash override
100 100 0x24 36 AF42 Medium 100 - Flash override
100 110 0x26 38 AF43 High 100 - Flash override

Design considerations[edit]

Under DiffServ, all the policing and classifying are done at the boundaries between DiffServ domains. This means that in the core of the Internet, routers are unhindered by the complexities of collecting payment or enforcing agreements. That is, in contrast to IntServ, DiffServ requires no advance setup, no reservation, and no time-consuming end-to-end negotiation for each flow.

The details of how individual routers deal with the DS field are configuration specific, therefore it is difficult to predict end-to-end behavior. This is complicated further if a packet crosses two or more DiffServ domains before reaching its destination. From a commercial viewpoint this means that it is impossible to sell different classes of end-to-end connectivity to end users, as one provider's Gold packet may be another's Bronze. DiffServ or any other IP based QoS marking does not ensure quality of the service or a specified service-level agreement (SLA). By marking the packets, the sender indicates that it wants the packets to be treated as a specific service, but it can only hope that this happens. It is up to all the service providers and their routers in the path to ensure that their policies will take care of the packets in an appropriate fashion.

The problem addressed by DiffServ does not exist in a system that has enough capacity to carry all traffic.

Bandwidth broker[edit]

A Bandwidth Broker in the framework of DiffServ is an agent that has some knowledge of an organization's priorities and policies and allocates bandwidth with respect to those policies.[11] In order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth Broker managing a domain will have to communicate with its adjacent peers, which allows end-to-end services to be constructed out of purely bilateral agreements.

DiffServ RFCs[edit]

  • RFC 2474 — Definition of the differentiated services field (DS field) in the IPv4 and IPv6 headers.
  • RFC 2475 — An architecture for differentiated services.
  • RFC 2597 — Assured forwarding PHB group.
  • RFC 2983 — Differentiated services and tunnels.
  • RFC 3086 — Definition of differentiated services per domain behaviors and rules for their specification.
  • RFC 3140 — Per hop behavior identification codes. (Obsoletes RFC 2836.)
  • RFC 3246 — An expedited forwarding PHB. (Obsoletes RFC 2598.)
  • RFC 3247 — Supplemental information for the new definition of the EF PHB (expedited forwarding per-hop behavior).
  • RFC 3260 — New Terminology and Clarifications for Diffserv. (Updates RFC 2474, RFC 2475 and RFC 2597.)
  • RFC 4594 — Configuration Guidelines for DiffServ Service Classes.
  • RFC 5865 — A differentiated services code point (DSCP) for capacity-admitted traffic. (Updates RFC 4542 and RFC 4594.)

DiffServ Management RFCs[edit]

  • RFC 3289 — Management information base for the differentiated services architecture.
  • RFC 3290 — An informal management model for differentiated services routers.
  • RFC 3317 — Differentiated services quality of service policy information base.

See also[edit]

References[edit]

  1. ^ RFC 3260
  2. ^ S3700HI Ethernet Switches Configuration Guide - QoS, Huawei, p. 7, retrieved 2016-10-07, A DiffServ domain is composed of a group of interconnected DiffServ nodes that use the same service policy and PHBs.
  3. ^ a b RFC 4594
  4. ^ RFC 2597 Section 3
  5. ^ RFC 2474
  6. ^ RFC 6088
  7. ^ Worldwide. "Implementing Quality of Service Policies with DSCP". Cisco. Retrieved 2010-10-16.
  8. ^ Filtering DSCP Archived July 29, 2016, at the Wayback Machine
  9. ^ RFC 4594
  10. ^ https://tools.ietf.org/id/draft-szigeti-tsvwg-ieee-802-11e-00.html
  11. ^ K. Nichols; V. Jacobson; L. Zhang (July 1999), A Two-bit Differentiated Services Architecture for the Internet, Network Working Group, RFC 2638

Further reading[edit]

External links[edit]