Differentiated Services Model Differentiated Services Model

6.1.3 Differentiated Services Model Differentiated Services Model

The differentiated services (DiffServ) approach to providing QoS in a network is based on employing a well-defined set of blocks with which one can build a variety of services. It is based on the differentiated services code point (DSCP) byte and ToS byte of the IP packet. The DiffServ architecture provides a framework within which service providers can offer a wide range of services to customers, each service being differentiated based on the DSCP field in the IP packet. This value specifies the per-hop behavior (PHB) of the packet as it traverses the service provider network.

Differentiated Services Code Point Differentiated Services Code Point

To allow traffic to have different policies applied to it, some method of differen- tiation of packets is required. Within the IP header is an eight-bit field known as type of service(ToS), within which three bits are used as precedence, allowing for eight classes to be used. This field has recently been redefined by the IETF as the differentiated services code point (DSCP) and uses six bits of the field, allow- ing for 64 different classes. Figure 6.2 shows the details of the DSCP field (and also the precedence field) of the IP header. In the case of DSCP, the currently unused bits are not used and are reserved for future implementation.

Multiprotocol Label Switching (MPLS) has only three bits in the experimental (EXP) field of the MPLS (shim) header. The IP precedence bits (three left-most bits of the ToS field of the IP header) are copied to the EXP field of the MPLS header when the MPLS header is appended to the packet. This effectively means that full use of DSCP can only be made in links where MPLS is not enabled. All other links in the network run MPLS, but only the first three higher-order bits of DSCP can be used to classify traffic.

The limited number of bits in the MPLS header is not necessarily a drawback of MPLS. MPLS is used in the core network. The DSCP field of the IP header is

6.1

6.1 Quality of Service 159159

used to classify the customer traffic. In the core network, traffic from several customers can be aggregated into a single class. Typically, there are up to four classes in the core network: voice, priority, guaranteed bandwidth, and best-effort. Since the MPLS packet encapsulates the IP packet with the MPLS header, the DSCP field in the IP is not lost and can be recovered at the edge of the network when the MPLS header is stripped and the IP packet is forwarded to the customer.

DiffServ Architecture DiffServ Architecture

All the nodes that follow the DiffServ model are in a DiffServ domain. All the nodes on a DiffServ domain observe the PHB of a packet based on the DSCP value. Figure 6.3 shows the DiffServ architecture and the two functional building blocks, traffic conditioners and PHB.

Traffic conditioners are used to classify the IP packets by marking the ToS or DSCP field of the IP packet or the EXP bit of the MPLS packet. Traffic condi- tioners are applied when the traffic enters the DiffServ domain. These func- tions are implemented on the edge nodes of the DiffServ domain. Packets are policed and marked based on the traffic profile. The DSCP field of the packets is also marked based on the traffic profile. The traffic conditioner used to police the packet may drop the packets if they do not match the profile or may shape the traffic when it does not meet the requirements of the profile.

Version

length Len ID Offset TTL Protocol FCS IP-SA IP-DA Data IP packet ToS 1 byte Delay T h r o u g h p u t Reliability Precedence

Differentiated services code point

ECN

CU

FIGURE 6.2 FIGURE 6.2

160

160 CHAPTER 6CHAPTER 6 Quality of Service in IP-Based Services

PHB functionsmust be implemented on all of the nodes in the DiffServ domain. They allocate resources for the packets to be scheduled and transmitted out of each node and implement the drop policy when there is congestion.

DiffServ versus IntServ DiffServ versus IntServ

The DiffServ model is more scalable than the IntServ model and has fewer flows than the IntServ model. However, this model requires that the traffic conditioners and PHB be implemented in the DiffServ domain. Provisioning the services using the DiffServ model can be challenging because the traffic conditioners and PHB have to be correctly implemented on every interface of all the nodes in the Diff- Serv domain. It can be a tedious task to implement and verify the implementation on all of the nodes. The IntServ model on top of the DiffServ model is an interest- ing concept that can be used to take advantage of both models. While the DiffServ model will make it scalable, the IntServ model will assure that resources are made available to each flow for which the IntServ model is used.