MPLS DiffServ-aware Traffic Engineering

Ina Minei, Software Engineer
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
408 745 2000 or 888 JUNIPER
www.juniper.net
Part Number: 200048-001

1. Executive

Summary Differentiated Services (DiffServ) enables scalable network designs with multiple classes of service. MPLS traffic engineering (TE) enables resource reservation, fault-tolerance, and optimization of transmission resources. MPLS DiffServ-TE combines the advantages of both DiffServ and TE. The result is the ability to give strict Quality of Service (QoS) guarantees while optimizing use of network resources. The QoS delivered by MPLS DiffServ-TE allows network operators to provide services that require strict performance guarantees such as voice and to consolidate IP and ATM/FR networks into a common core.

2. Introduction

In today’s competitive market, service providers seek to increase their revenues while at the same time keeping capital and operational expenditures down. From a practical point of view, this means (1) providing new revenue-generating services, such as voice and guaranteed bandwidth for business-critical applications and (2) migrating Layer 2 services from legacy networks such as ATM and FR into the IP network infrastructure, thus eliminating the need to maintain several physical networks. The challenge lies in the fact that both the new and the legacy services usually require strict service level agreements (SLAs). 

The SLAs define the service quality experienced by traffic transiting the network and are expressed in terms of latency, jitter, bandwidth guarantees, resilience in the face of failure, and downtime. The SLA requirements translate to two conditions: (1) different scheduling, queuing, and drop behavior based on the application type; and (2) bandwidth guarantees on a per-application basis. 

To date, service providers have rolled out revenue-generating services in their networks using DiffServ alone. By assigning applications to different classes of service and marking the traffic appropriately, the first condition was met. However, to receive strict scheduling guarantees, it is not enough to mark traffic appropriately. If the traffic follows a path with inadequate resources to meet performance characteristics such as jitter or latency requirements, the SLAs cannot be met. In principle, service providers could solve this problem by using overprovisioning to avoid congestion altogether. Besides being wasteful with regards to resource utilization, this approach of “throwing bandwidth at the problem” cannot provide any guarantees when congestion is caused by link and/or node failures. 

MPLS traffic engineering (MPLS-TE) sets up label-switched-paths (LSPs) along links with available resources, thus ensuring that bandwidth is always available for a particular flow and avoiding congestion both in the steady state and in failure scenarios. Because LSPs are established only where resources are available, overprovisioning is not necessary. Further optimization of transmission resources is achieved by allowing LSPs not to follow the shortest path, if the available resources along the shortest path are not sufficient. An added benefit of MPLS is that built-in mechanisms such as link protection and fast reroute provide resilience in the face of failure. The catch is that MPLS-TE is oblivious of the class of service (CoS) classification, operating on the available bandwidth at an aggregate level across all classes. 

MPLS DiffServ-TE makes MPLS-TE aware of CoS, allowing resource reservation with CoS granularity and providing the fault-tolerance properties of MPLS at a per-CoS level. By combining the functionalities of both DiffServ and TE, MPLS DiffServ-TE delivers the QoS guarantees to meet strict SLAs such as the ones required for voice, ATM, and Frame Relay. 

Note that even if resources are reserved on a per-CoS basis, and even if traffic is properly marked to conform to the CoS appropriate for the application, the SLAs still cannot be guaranteed unless further mechanisms, such as policing and admission control, are set in place to ensure that the traffic stays within the limits assumed when the resource reservation was made. 

Section 3 of this paper introduces DiffServ and TE, presenting a few application scenarios and discussing how each of these technologies alone cannot provide a satisfactory solution. Section 4 gives an in-depth view of the MPLS DiffServ-TE technology as defined in the IETF standards. Section 5 highlights some of the advantages of the JUNOS DiffServ- TE implementation.

3. DiffServ and TE – The Current Tools

This section introduces the two building blocks of MPLS DiffServ-TE, DiffServ and TE, and explains why it is necessary to combine them in order to guarantee QoS in practical application scenarios.

3.1 DiffServ 

The initial efforts to provide quality of service (QoS) in IP networks were based on a per- application-flow model (IntServ), in which individual applications requested QoS guarantees directly from the network. The RSVP signaling protocol was used to distribute the requests to the nodes in the network, and state needed to be maintained for each flow at every hop along the way. With millions of flows traversing IP networks, this approach proved to be unscalable and overly complex, and a more “coarse-grained” model was developed in the form of DiffServ. DiffServ approaches the problem of QoS by dividing traffic into a small number of classes and allocating network resources on a per-class basis. To avoid the need for a signaling protocol, the class is marked directly on the packet, in the 6-bit DiffServ Code Point (DSCP) field. The DSCP field is part of the original type of service (ToS) field in the IP header. The IETF redefined the meaning of the little-used ToS field, splitting it into the 6- bit DSCP field and a 2-bit Explicit Congestion Notification (ECN) field, as shown in figure 1. 

Figure 1: ToS and DSCP + ECN 

The DSCP determines the QoS behavior of a packet at a particular node in the network. This is called the per-hop behavior (PHB) and is expressed in terms of the scheduling and drop preference that a packet experiences. From an implementation point of view, the PHB translates to the packet queue used for forwarding, the drop probability in case the queue exceeds a certain limit, the resources (buffers and bandwidth) allocated to each queue, and the frequency at which a queue is serviced. The IETF defined a set of 14 standard PHBs as follows:
- Best effort (BE). Traffic receives no special treatment. 
- Expedited forwarding (EF). Traffic encounters minimal delay and low loss. From a practical point of view, this means a queue dedicated to EF traffic for which the arrival rate of packets is less than the service rate, so delay, jitter and loss due to congestion is unlikely. Voice and video streams are typical examples of traffic mapped to EF: they have constant rates and require minimal delay and loss. 
- Twelve assured forwarding (AF) PHBs. Each PHB is defined by a queue number and a drop preference. The IETF recommends using four different queues with three levels of preference each, yielding a total of twelve distinct AF PHBs. The convention for naming the AF PHBs is AFxy, where x is the queue number and y is the level of drop preference. Thus, all packets from AF1y will be put in the same queue for forwarding, ensuring that packets from a single application cannot be reordered if they differ only in the drop preference. The AF PHBs are applicable for traffic that requires rate assurance but that does not require bounds on delay or jitter. 

Although the IETF defined recommended DSCP values for each of the standard PHBs, vendors allow network operators to redefine the mapping between the DSCP and the PHB, and to define non standard PHBs. The important thing to keep in mind is that once the packet is marked with a particular DSCP value, its QoS treatment is defined at each hop it crosses. Thus, to ensure consistent QoS behavior, it is imperative to maintain consistent DSCP-to-PHB mappings. This requirement brings us to the notion of a DiffServ domain, which is a set of DiffServ capable nodes with 1) a common set of defined PHBs, 2) the same DSCP-to-PHB mappings, and 3) a unified service provisioning policy. Usually a DiffServ domain operates under a single administrative authority. At the edge of a DiffServ domain, the traffic is marked with the DSCP values that yield the desired per hop behavior and ultimately the desired QoS.

Figure 2: A DiffServ domain. Voice traffic is marked at the entrance to the domain with EF, data traffic with BE. Every hop examines the DSCP bits and maps the traffic to a different queue. 

To summarize, DiffServ provides differential forwarding treatment to traffic, thus enforcing QoS for different traffic flows. It is a scalable solution that does not require per- flow signaling and state maintenance in the core. However, it cannot guarantee QoS if the path followed by the traffic does not have adequate resources to meet the QoS requirements.

6. Conclusion

The DiffServ-TE technology defined by the IETF provides strict service guarantees for different traffic types. Such guarantees allow service providers to deploy new services and achieve better resource utilization for existing services. The JUNOS implementation offers a standards-based, interoperable, and scalable implementation of DiffServ-TE, along with unique tools for ensuring that traffic stays within the limits of the resources that were reserved for it. 

7. References 

[DSTE- MAM] - Le Faucheur F., Lai K., Maximum Allocation Bandwidth Constraints Model for DS-TE - draft-ietf-tewg-diff-te-mam-01.txt 
DSTE-PROTO] - Le Faucheur F. et al, Protocol extensions for support of DS-aware MPLS TE - draft-ietf-tewg-diff-te-proto-05.txt 
[DSTE-RDM] - Le Faucheur F. et al, Russian Dolls Bandwidth Constraints Model for DS-TE - draft-ietf-tewg-diff-te-russian-04.txt 
[FRR] - Pan P. et al, Fast Reroute Extensions to RSVP-TE for LSP Tunnels - draft-ietf-mpls- rsvp-lsp-fastreroute-03.txt, work in progress 
[ISIS-TE] – Smit H., Li T., IS-IS extensions for Traffic Engineering - draft-ietf-isis-traffic-05.txt 
[MPLSTECH] – Davie B., Rekhter Y. , MPLS Technology and Applications 
[OSPF-TE] – Katz D. Yeung D., Traffic Engineering Extensions to OSPF - draft-katz-yeung- ospf-traffic-10.txt 
[RFC2475] – Blake S. et al, An Architecture for Differentiated Services – RFC 2475 
[RFC2702] - Awduche D. et al, Requirements for Traffic Engineering Over MPLS – RFC 2702 
[RFC3031] - Rosen E. et al, Multiprotocol Label Switching Architecture – RFC 3031
[RFC3036] – Anderson L. et al, LDP Specification – RFC 3036 
[RFC3209] - Awduche D. et al, RSVP-TE: Extensions to RSVP for LSP Tunnels - RFC 3209 
[RFC3270] - Le Faucheur F. et al, MPLS Support of Diff-Serv - RFC 3270 
[RFC3468] – Anderson L., Swallow G., The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols – RFC 3468 
[RFC3564]- Le Faucheur F. et al, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering - RFC 3564 

Acknowledgements

The author would like to thank Yakov Rekhter, Julian Lucek and Amir Tabdili for their comments, suggestions and insight; Mike Capuano, Hannes Gredler, Nischal Sheth and Chelian Pandian for their review; Aviva Garret for editing; and Susan Lane for production support.