DiffServ
DiffServ architecture relies on a broad differentiation between a small number of service classes. Packets are identified as belonging to one class or another through the content of the DiffServ field in the IP header. Packets are classified and marked at the network edge depending on the kind of traffic contract or SLA between the customer and the service provider. The different classes of packets then receive different per-hop behaviors (PHBs) in the nodes of the network core. Service differentiation also implies different tariffs depending on the QoS offering to flows and packets belonging to different classes. The DiffServ architecture consists of a set of functional elements embodied in the network nodes.
- Allocation of buffering and bandwidth aggregates corresponding to each PHB
- Packet classification (FEC)
- Traffic conditioning, metering, marking, and shaping
The sophisticated operations of packet classification are implemented at the edge of the network or in the customer equipment. The architecture avoids the requirement to maintain per-flow or per-user state within the network core.
The implementation, configuration, operation, and administration of the PHB groups supported of a DiffServ domain are dependent on sufficient resources being available. You must ensure that the amount of resources available is adequate, given the traffic conditioning parameters for contracted SLAs.
The DiffServ field (IETF RFC 2474) replaces the existing definitions of the TOS byte in IPv4 and the traffic class byte in IPv6. Six bits of the DiffServ field are used in the form if the differentiated services code point (DSCP) identifies the PHB to be received by a packet at each node.
In addition to traditional best effort, considered to be the default PHB, two other PHBs have been defined by the IETF. These are expedited forwarding (EF) (IETF RFC 2598) and assured forwarding (AF) (IETF RFC 2597). The EF PHB is designed to provide an end-to-end service with low packet loss, delay, and jitter and a guaranteed bit rate. It can be used to create a virtual leased line as described previously under MPLS-TE. The AF PHB group permits a service provider to offer differentiated levels of performance to different traffic aggregates received from customers. For example, AF packets can be divided into four subclasses with a separate resource allocation for each class.
Using DiffServ in MPLS (IETF RFC 3270) the following two types of LSPs exist:
- EXP-Inferred–PSC LSP (E-LSP)—Can transport different service classes and the differentiated handling of packets being carried out at the level of the LSR on the basis of the EXP field where up to eight PHBs per LSPs can be deployed.
- Label-Only-Inferred-PSC LSP (L-LSP)—Handles only one type of DiffServ aggregate, the label defining the LSP corresponding to a DiffServ class. The information on the DiffServ class is provided when the LSP is set up using LDP or RSVP protocol. An LSR can merge L-LSPs only if they belong to the same DiffServ class. The EXP field can be used for the discard priorities of DiffServ classes.
The advantages of E-LSP are that multiple PHBs (8) per LSP are supported, thus reducing the number of labels required; implementation is a bit easier in that you just need to configure LSRs to map EXP values to PHBs. The disadvantage is that, although 8 PHBs can be supported, DiffServ actually supports up to 64 PHBs and cannot be implemented when the shim header is not used—for example, in ATM or FR.
The advantages of L-LSP are that it can support an arbitrarily large number of PHBs in excess of 64 and can use multiple paths for different PHBs via traffic engineering. The disadvantages of L-LSP are that it consumes more labels and is more difficult to configure. For example, you need to configure LDP to signal PHBs during label establishment.
The majority of current deployments consist of less than 8 PHBs in the core. Actual deployment models on Router-LSRs consist of a single E-LSP for all CoS or 1 E-LSP per CoS (for example, 1 E-LSP for voice + 1 E-LSP for data). A strict priority queue exists for EF and a high weight exists for premium/AF (for example, 90%) with WRED for in and out-of contract. Additionally, a low weight exists for best effort (for example, 10%) with RED. The L-LSPs used today on ATM-LSRs might be required in the future on Router-LSRs, if and when more than 8 PHBs are needed.
MPLS DiffServ and MPLS TE can coexist because MPLS TE is designed as a tool to improve backbone efficiency independently of QoS. MPLS TE computes routes for aggregates across all classes and performs admission control over the "global" bandwidth pool for all classes (that is, MPLS TE does not consider the bandwidth allocated to each queue). MPLS TE and MPLS DiffServ can run simultaneously and provide their own benefits. For example, TE distributes aggregate load and DiffServ provides differentiation. This construct is referred to as differentiated services-traffic engineering (DS-TE). DS-TE makes MPLS TE aware of DiffServ in that DS-TE establishes separate tunnels for different classes and takes into account the "bandwidth" available to each class (for example, to queue).
DS-TE also considers separate engineering constraints for each class. Here are two examples: I want to limit voice traffic to 70% of link max., but I do not mind having up to 100% of best effort traffic, or I want an overbook ratio of 1 for voice but 3 for best effort.
DS-TE can take into account different metrics (for example, delay) and ensures that a specific QoS level of each DiffServ class is achieved. DS-TE provides a mechanism where different tunnels can satisfy various engineering constraints as summarized in Figure 3-23.
)
Figure 3-23 DS-TE Implementation Example
MPLS DiffServ and DS-TE are discussed further in Chapter 9.