8.5 Differentiated Services (DS)

The Differentiated Services (DS) concept is currently under development at the IETF DS working group. The DS specifications are defined in a number of IETF Internet drafts, but currently no RFC is available. Since the concepts involved are still in the development phase, some of the information and references are likely to change. The goal of DS development is to provide differentiated classes of service for Internet traffic to support various types of applications and specific business requirements. DS offers predictable performance (delay, throughput, packet loss, etc.) for a given load at a given time. A key advantage of DS over the IS model is that DS provides a scalable service for the Internet without the need for per flow state and signaling at every router hop. It eliminates the need to store information about each flow and can be deployed without requiring expensive and complicated end-to-end signaling (e.g., RSVP).

8.5.1 Service marking

DS-enabled networks classify packets according to one of a small number of aggregated flows, based on bit settings within the one-byte ToS field of the IPv4 header and the traffic class byte in the IPv6 header. The IETF DS working group has proposed to redefine the structure of this field in DS-capable networks, and this revised field is referred to as the DS byte (overriding the IPv4 TOS byte specifications in [8]). Figure 8.12 illustrates the structure of the DS byte.

Figure 8.12: The DS byte format.

Field definitions

DSCP—Six bits of the DS field are used as a Differentiated Services CodePoint (DSCP) to select the traffic class a packet will experience at each node.
- 000000—The IETF working group recommends this value for the default best-effort Per Hop Behavior (PHB).
- 101100—The IETF working group recommends this value for the Expedited Forwarding (EF) PHB.
CU—A two-bit Currently Unused (CU) field is reserved and can be assigned later.

The traffic class specified in the DS byte indicates whether packets should receive special handling or the default best-effort delivery. All network traffic inside a domain receives a service that depends on the traffic class specified in the DS byte. To provide SLA-conforming services, the following mechanisms must be combined in a network:

Setting bits in the DS byte (ToS octet) at network edges and administrative boundaries.
Using DS bits to indicate how packets are treated by the routers inside the network.
Conditioning marked packets at network boundaries in accordance with the QoS requirements.

The DS architecture currently provides service differentiation in one direction and is, therefore, asymmetric. Development of a complementary symmetric architecture is a subject of further work. Unlike IS, QoS guarantees with DS are static and stay for a long term in routers. This means that applications using DS don't need to set up QoS reservations for specific data packets. All traffic that passes DS-capable networks can receive a specific QoS. The data packets must be marked with the DS byte, which is interpreted by the routers in the network.

8.5.2 Per Hop Behavior (PHB)

Every DS-enabled network device must have access to information on how packets with different DS codepoints (DSCP) should be handled. This is referred to as the Per Hop Behavior (PHB). PHB describes the treatment a packet receives by each network node along the forwarding path. PHBs need to be defined in all routers in a DS-capable network in order to provide predictable end-to-end services. The PHB is basically a set of parameters that can be used by a router to determine how packets are scheduled for dispatch to an output interface.

There are a number of scheduling and congestion avoidance techniques available in commercial products today. DS requires routers with sophisticated scheduling disciplines to prioritize outbound packets and control the queue depth (using algorithms such as WFQ and RED) to minimize congestion on the network. Routers with only FIFO queuing cannot provide service differentiation and may potentially suffer periodic congestion. The exact handling a packet will receive inside a router is very much vendor dependent. For example, an IP packet could be forwarded to a router with eight different queues (0 = high priority, 8 = low priority), and the DS byte can be used to select which queue is most appropriate for forwarding the packet. Alternatively, a router can have a single queue with multiple drop priorities for data packets. The router uses the DS byte to select the drop preference for the packets in the queue. A value of zero would indicate that the router is most likely to drop this packet; whereas a value of seven means that the router is least likely to drop this packet.

To ensure that the PHBs in each router are consistent, a number of standard PHBs will be defined in future DS specifications (see Figure 8.12). All routers in a DS domain must know which service a packet with a specific PHB should receive. PHBs will be defined in groups. A PHB group is a set of one or more PHBs that can only be specified and implemented simultaneously, because of queue servicing or queue management policies that apply to all PHBs in one group. A default PHB must be available in all DS-compliant nodes. It represents the standard best-effort forwarding behavior available in existing routers. When no other agreements are in place, it is assumed that packets belong to this service level. Another PHB that is proposed for standardization is Expedited Forwarding (EF). EF requires high-priority treatment and is typically used for network control traffic (such as OSPF routing updates).

8.5.3 Design considerations

The attraction of the DS model when compared to the IS model is that it builds on existing best-effort service components without a major hardware and software overhaul. This makes it much more viable for service providers and equipment vendors alike. Since the DS model relies on soft-state information, it is considerably more flexible both to deploy and enhance.

Differentiated services domains

The setup of QoS guarantees is not made for specific end-to-end connections but for well-defined DS domains. The IETF working group defines a DS domain as a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. It can represent different administrative domains or autonomous systems, different trust regions, and different network technologies, such as cell or frame-based techniques, hosts, and routers. A DS domain comprises boundary components that are used to connect different DS domains to each other and interior components that are used only inside the domains. A DS domain normally comprises one or more networks under the same administration. This could be a corporate intranet or an ISP. Administrators of a DS domain are responsible for ensuring that adequate resources are provisioned and reserved to support the SLAs offered by the domain. This should be regularly monitored.

Boundary nodes

All data packets that travel from one DS domain to another must pass a boundary node, which can be a router, host, or firewall. A DS boundary node that handles traffic leaving a DS domain is called an egress node, and a boundary node that handles traffic entering a DS domain is called an ingress node. Normally, DS boundary nodes act both as ingress node and egress node depending on the traffic direction. The ingress node must make sure that the packets entering a domain receive the same QoS as in the previous domain. A DS egress node performs conditioning functions on traffic that is forwarded to a directly connected peering domain. The traffic conditioning is done inside a boundary node by a traffic conditioner. It classifies, marks and possibly conditions packets that enter or leave the DS domain. Figure 8.13 shows the cooperation of the traffic conditioner components. A traffic conditioner consists of the following components:

Classifier—A classifier selects packets based on their packet header and forwards the packets that match the classifier rules for further processing. The DS model specifies two types of packet classifiers:
- MultiField (MF) classifiers that can classify on the DS byte as well as on any other IP header field (e.g., the IP address and the port number, similar to an RSVP classifier).
- Behavior Aggregate (BA) classifiers, which classify only on the bits in the DS byte.
Meter—Traffic meters measure if the forwarding of the packets that are selected by the classifier corresponds to the traffic profile that describes the QoS for the SLA between customer and service provider. A meter passes state information to other conditioning functions to trigger a particular action for each packet that either does or does not comply with the requested QoS requirements.
Marker—DS markers set the DS byte of the incoming IP packets to a particular bit pattern. The PHB is set in the first six bits of the DS byte so that the marked packets are forwarded inside the DS domain according to the SLA between service provider and customer.
Shaper/dropper—Packet shapers and droppers cause conformance to some configured traffic properties, (e.g., a token bucket filter). They use different methods to bring the stream into compliance with a traffic profile. Shapers delay some or all of the packets. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. Droppers discard some or all of the packets. This process is known as policing the stream. A dropper can be implemented as a special case of shaper by setting the shaper buffer size to zero packets.

click to expand
Figure 8.13: DS traffic conditioner.

The traffic conditioner is primarily used in DS boundary nodes (although it may also be used in interior nodes). The main purpose of traffic conditioning in a boundary node is to ensure that consistent service mappings are applied as packets transit multiple domains (since different DS domains may support different PHB groups, the same entry in the DS byte can be interpreted differently in different domains). For example, routers inside Domain A may have only four queues available, whereas routers inside Domain B may have eight queues. For packets that require high-priority service originating in Domain A, the traffic conditioner must ensure that packets forwarded to Domain B have their PHBs mapped accordingly. In practice the DS byte may be remarked at every boundary component to ensure that the SLA is not violated. A Traffic Conditioning Agreement (TCA) within the SLA specifies the classifier rules (e.g., metering, marking, discarding, and traffic shaping) required to meet the SLA. The TCA parameters must be distributed to all boundary components of a DS network in order to guarantee that packets traversing different DS domains receive a consistent end-to-end level of service.

Interior nodes

Interior nodes (i.e., routers with traffic management features) within a DS domain control the forwarding behavior for packets based on the contents of the DS byte. Since the DS byte is not normally modified within a DS domain, all interior routers must implement consistent forwarding policies. Packets with different PHB settings will receive different levels of service (depending upon the particular QoS-PHB mapping). Since all interior routers within a domain use the same policy functions for incoming traffic, traffic conditioning within an interior node is simply handled by the packet classifier. The classifier selects packets based on their PHB value (or other IP header fields) and then passes these packets to scheduling functions within the node, where they are prioritized and dispatched from queues in a manner appropriate to the required service quality. When packets reach the edge of a domain, they are processed by a boundary router, where they are potentially remarked (to ensure consistent PHB) before being forwarded to the next domain.

Source domains

A source domain is a domain that contains one or more nodes that originate traffic that receives a particular level of service (e.g., a video server within a customer domain requesting a specific delay and throughput quality). Both traffic sources and intermediate nodes within a source domain can perform traffic classification and conditioning functions, and traffic may be marked by the traffic sources directly or by intermediate nodes before leaving the source domain. The first PHB marking of data packets is not done by the sending application; packets are marked by the source host platform or an intermediate router. Applications are, therefore, unaware of DS functions (which is in direct contrast with the IS model, where most applications must be modified to support RSVP). Packets are identified using their IP address and source port. For example, a customer has an SLA with a provider network that guarantees high-priority handling for packets sent by a videoconferencing application. The DS network must implement an appropriate policy to match this requirement. The videoconferencing application transmits packets using a specific port that can be recognized by MultiField (MF) classifiers; an MF classifier can examine the IP address and port number of an individual packet and so differentiate between different applications. Hence, if the source host contains a traffic conditioner with an MF classifier, it can mark IP packets with the appropriate PHB value (i.e., by setting the DS codepoint), as they are being made ready for dispatch. If the source host does not possess this functionality, then the first router encountered in the source domain that supports traffic conditioning handles the initial PHB marking by classifying packets and then setting the correct DS codepoint. Note that the use of the DS codepoint effectively aggregates flows with similar service requirements. The source DS domain is responsible for ensuring that all aggregated flows forwarded to external domains conform to their SLA requirements. The boundary node of the source domain should also monitor incoming traffic to establish that service levels are conformed to and may police, shape, or remark packets if necessary.