Jan. 20, 2011, 10:08 p.m.
posted by mp
MPLS Support for DiffServ
MPLS supports DiffServ with minimal adjustments to the MPLS and DiffServ architectures.MPLS does not introduce any modifications to the traffic-conditioning and PHB concepts defined in DiffServ. A label switching router (LSR) uses the same traffic-management mechanisms (metering, marking, shaping, policing, queuing, and so on) to condition and implement the different PHBs for MPLS traffic. An MPLS network may use traffic engineering to complement its DiffServ implementation. RFC 3270 defines MPLS support for the DiffServ architecture.
An MPLS network may implement DiffServ to support a diverse range of QoS requirements and services in a scalable manner. MPLS DiffServ is not specific to the transport of IP traffic over an MPLS network. An MPLS network may be carrying other types of traffic for which DiffServ does not apply (for example, ATM or Frame Relay). An MPLS DiffServ implementation is concerned only with supporting the PHBs that can satisfy the QoS requirements of all the types of traffic it carries. In addition, an MPLS network can grow without having to introduce major changes to its DiffServ design as the number of label switched paths (LSPs) in the network increases. These characteristics play an important role in the implementation of large MPLS networks that can transport a wide spectrum of traffic.
MPLS support for DiffServ introduces two types of LSPs with different service characteristics and operation. The first type, EXP-inferred-class LSP (E-LSP), can transport simultaneously multiple classes of traffic. The second type, Label-inferred-class LSP(L-LSP), transports a single class. They rely on different mechanisms to encode the DiffServ marking of the packet. In general, MPLS uses a label stack encoding based on shim headers that RFC 3032 defines. Figure illustrates the fields contained in the shim header. The specifications for MPLS DiffServ define two encodings for the DiffServ code point. In addition, these LSP types impose different LSP signaling requirements. The changes in the encoding of DiffServ marking and the use of signaling are the two important areas where MPLS DiffServ differs from the original specification.
MPLS Shim Header
RFC 3270 formally defines E-LSPs as EXP-inferred-PSC LSPs and L-LSP as Label-only-inferred-PSC LSPs. The section "DiffServ Terminology" provided a formal definition of a PSC earlier in this chapter. You can simply equate the term to a class of traffic.
ATM LSRs, Frame Relay LSRs, and LSRs with label switching controlled ATM (LC-ATM) interfaces use a native encoding for the top label rather than the shim header. This has important implications for the implementation of DiffServ on those devices. Given their decreasing use, this book does not focus on their details.
MPLS support for DiffServ defines E-LSP as a type of LSP that can carry simultaneously multiple classes of traffic. LSRs use the EXP field in the shim header to infer the PHB that a packet requires. As Figure shows, the EXP contains three bits that can take eight possible values. The size of this field implies that an E-LSP can transport up to eight classes of service. An E-LSP carries fewer classes if some of those classes consume multiple markings (for example, AF1 which may use two or three markings). The specifications do not define recommended EXP values for the existing DiffServ PHBs (EF, AF n, CS n Default). Furthermore, they do not define any structure on the three-bit field. LSRs may set up E-LSPs with bandwidth reservation (generally for the purpose of admission control).
Figure illustrates a network using E-LSPs. In this case, there are two E-LSPs between node A and D. The network supports three classes: EF, AF1, and AF2. From top to bottom, the first E-LSP carries EF traffic; the second LSP multiplexes traffic of the three classes. Even though E-LSPs may carry multiple classes, the first E-LSP transports only EF traffic in this scenario. According to the E-LSP rules, all nodes perform PHB determination based on the EXP value of the packet. Notice that some EF traffic follows one E-LSP, whereas the rest follows the other E-LSP. Node A can split EF traffic if the node does not split EF microflows. Node C serves EF traffic without consideration of what LSP carries the EF traffic.
MPLS Network Using an E-LSP
MPLS support for DiffServ defines mechanisms for E-LSPs to signal mappings between EXP values and PHBs. An LSR associates EXP-to-PHB mappings for input labels and PHB-to-EXP mappings for output labels. Signaling is optional and takes place during LSP setup. RFC 3270 defines extensions to LDP (DiffServ TLV [ Type, Length, Value for Label Request, Label Mapping, Label Release, and Notification messages) and RSVP (DiffServ object for Path messages) and their appropriate processing. The signaling identifies the LSP as an E-LSP and specifies the mappings between EXP values and PHBs that it will use. LSRs can use static but configurable mappings to avoid these signaling extensions for E-LSPs. An LSR should map all EXP values to the Default PHB if the LSP signaling did not specify a mapping and no preconfigured mapping exists.
ATM LSRs, Frame Relay LSRs, and LSRs with LC-ATM interfaces do not forward packets using an MPLS shim header encapsulation. The absence of a shim header implies the absence of the EXP field. Therefore, those devices cannot support E-LSPs. This restriction also applies to nonpacket networks that use generalized MPLS (GMPLS).
MPLS support for DiffServ defines L-LSP as a type of LSP that can only transport of a single class of traffic. LSRs infer the class associated with the a packet from the label and determine the exact PHB using the label in combination with the EXP field. Figure illustrates the mandatory mapping between <classes, EXP> and PHBs. LSRs learn the association between L-LSP labels and classes during LSP setup. L-LSPs require the use of DiffServ signaling extensions. In this case, LSRs use a different format of the LDP DiffServ TLV and RSVP DiffServ object. The signaling identifies the LSP as an L-LSP and specifies the class that the L-LSP will transport. As with E-LSPs, LSRs may set up L-LSPs with bandwidth reservation.
Figure illustrates an MPLS network using L-LSPs. In this case, there are four L-LSPs between node A and D. The network supports three classes: EF, AF1, and AF2. From top to bottom, the first L-LSP carries AF2, the second and third ones carry EF, and the fourth and last L-LSP carries AF1 traffic. Notice that node A splits EF traffic over two L-LSPs. Node A can divide EF traffic if the node does not split EF microflows. Even though Node C identifies EF traffic using the labels, that node serves EF traffic without consideration of what L-LSP is carrying the traffic (that is, the node does not provide a PHB per L-LSP, but per class).
MPLS Network Using L-LSPs
The use of E-LSPs and L-LSPs on an MPLS network is not mutually exclusive. LSRs maintain a DiffServ label context. This context indicates the LSP type (E-LSP or L-LSP), the PHBs that the LSP supports, and a mapping between the packet encapsulation and a PHB. For input labels, that mapping defines how the LSR can infer the PHB from the packet encapsulation. For output labels, that mapping defines how the LSR encodes the PHB. This context is populated with preconfigured mappings or through DiffServ information learned during LSP setup. Figure compares E-LSPs and L-LSPs.
Figure shows an MPLS network using L-LSPs and E-LSPs simultaneously. In this example, there are two E-LSPs between node E and node D and two L-LSPs between node A and D. The network supports three classes: EF, AF1, and AF2. In this example, node C transports both E-LSPs and L-LSPs. This node uses the DiffServ label context to determine the LSP type and the exact mapping that it should use to infer the PHB from the packet encapsulation. LSRs serve the packets according to their PHB regardless of the LSP and its type. The LSP details influence the PHB determination, but the PHB ultimately determines the packet treatment. In this example, nodes A and E use one type of LSPs exclusively. However, each of them could alternatively use a combination of E-LSPs and L-LSPs to reach node D.
MPLS Network Combining L-LSPs and E-LSPs
ATM LSRs, Frame Relays LSRs, and LSRs with LC-ATM interfaces do not forward packets using an MPLS shim header encapsulation. The absence of a shim header implies the absence of the EXP field. However, those devices can still support DiffServ using their native encapsulation to implement L-LSPs. ATM LSRs and LSRs with LC-ATM interfaces use the native label encoding and the ATM CLP (Cell Loss Priority bit for PHB determination. Frame Relay LSRs use their native label encoding and the Frame Relay DE bit for PHB determination. RFC 3270 describes in detail the procedures that apply in those cases.
DiffServ Tunneling Models over MPLS
MPLS LSPs support for DiffServ defines three models of interaction between DiffServ markings in different layers of encapsulation. A simple example is an IP packet that has received the MPLS encapsulation. There is one PHB marking in the MPLS encapsulation and a PHB marking in the DiffServ field of the IP packet. There are three models to handle the interaction between multiple markings: the pipe, short-pipe, and uniform models. The models define the procedures that an LSR can apply when a packet (either IP or MPLS) with an existing PHB marking enters and exits an LSP. The three models do not introduce any changes to the normal label swapping behavior of an LSR or any signaling requirements. These models apply equally to E-LSPs and L-LSPs.
The MPLS DiffServ tunneling models extend the concepts introduced in RFC 2983. That RFC defines the operation of DiffServ over IP tunnels. In many aspects, LSPs resemble IP tunnels.
RFC 3270 defines the MPLS DiffServ tunneling models for the transport of IP and MPLS traffic. However, the underlying concepts can apply to the transport of other types of traffic (for example, Ethernet) over an MPLS network.
The pipe model conceals the tunneled PHB marking between the LSP ingress and egress nodes. This model guarantees that there are no changes to the tunneled PHB marking through the LSP; even if an LSR along the path performs traffic conditioning and re-marks the traffic. All LSRs that the LSP traverses use the LSP PHB marking and ignore the tunneled PHB marking. This model proves useful when an MPLS network connects other DiffServ domains. The MPLS network can implement DiffServ and still be transparent for the connected domains. RFC 3270 defines this model as mandatory for MPLS networks supporting DiffServ.
Figure illustrates the operation of the pipe model. The LSP ingress determines the LSP PHB marking it will encode in the pushed encapsulation. It may consider the existing PHB marking of the packet for this purpose. It preserves the tunneled PHB marking when pushing the new label encapsulation. Be aware that the packet entering the LSP may be an IP or an MPLS packet. The LSP egress serves the packet according to the LSP PHB marking. This action implies that this node infers the packet PHB before the pop operation. Moreover, the LSP egress does not modify the tunneled PHB marking that the pop operation exposes. An LSP using the pipe model cannot use penultimate hop popping(PHP) because the LSP egress will not have access to the LSP PHB marking.
Pipe Tunneling Model
The short-pipe model represents a small variation of the pipe model. It also guarantees that there are no changes to the tunneled PHB marking, even if an LSR re-marks the LSP PHB marking. The short-pipe model shares the same ability of the pipe model to allow an MPLS network to be transparent from the DiffServ point of view. The short-pipe model differs, however, on how the LSP egress infers the packet PHB. The LSP egress uses the tunneled PHB marking to infer the packet PHB and serve the packet consequently. Given this difference with the pipe model, an MPLS network may implement LSPs using the short-pipe model regardless of whether LSRs perform PHP.
Figure demonstrates the details of the operation of the short-pipe model with PHP. The LSP ingress must determine the LSP PHB marking it will encode in the pushed encapsulation. It may consider the existing PHB marking of the packet. The LSP ingress also preserves tunneled PHB marking when pushing the new label encapsulation. The short-pipe and pipe models share the same procedure for the LSP ingress. It infers the packet PHB from the LSP PHB marking before performing the pop operation. The penultimate hop does not modify the tunneled PHB marking that the pop operation exposes. The LSP egress infers the packet PHB from the tunneled PHB marking in the header used for packet forwarding.
Short-Pipe Tunneling Model with PHP
Figure shows the details of the short-pipe model for LSPs that do not experience PHP. The operation of the LSP ingress remains the same as before. The penultimate hop performs the label swapping operation and serves the packet according to the corresponding E-LSP or L-LSP procedures. The LSP egress infers the packet PHB from the tunneled PHB marking in the header used for packet forwarding. This action implies that the LSP egress infers the packet PHB after the label pop. As with all previous models, this node forwards the tunneled PHB marking unmodified. The short-pipe model offers the external behavior regardless of whether PHP happens.
Short-Pipe Tunneling Model Without PHB
The uniform model makes the LSP an extension of the DiffServ domain of the encapsulated packet. In this model, a packet only has a single meaningful PHB marking (which resides in the most recent encapsulation). LSRs propagate the packet PHB to the exposed encapsulation when they perform a pop operation. This propagation implies that any packet re-marking is reflected on the packet marking when it leaves the LSP. The LSP becomes an integral part of the DiffServ domain of the packet as opposed to the transparent transport that the pipe and short-pipe models provided. This model proves useful when an MPLS network connects other DiffServ domain and all networks (including the MPLS network) need to behave as a single DiffServ domain.
Figure illustrates the operation of the uniform model with PHP. The LSP ingress encodes the existing packet PHB marking in the pushed encapsulation. When the packet receives the new encapsulation, the encapsulated PHB marking becomes irrelevant. The penultimate hop infers the packet PHB before the pop operation and encodes it in the exposed encapsulation.
Uniform Tunneling Model with PHP
Figure shows the details of the uniform model for LSPs without PHP. The operation of the LSP ingress remains the same. The penultimate hop performs a regular label swapping operation. The LSP egress always infers the PHB before the pop operation and propagates the PHB marking to the exposed encapsulation. The uniform model offers the same external behavior regardless of whether the LSP uses PHP. Figure and 1-9 summarize the operation of the three tunneling modes with PHP and without PHP, respectively.
Uniform Tunneling Model Without PHP