An End-to-End QoS Architecture with the MPLS-Based Core

An End-to-End QoS Architecture with the MPLS-Based Core Victoria Fineberg, PE, Consultant, fineberg@illinoisalumni.org Cheng Chen, PhD, NEC, CChen@necam.com XiPeng Xiao, PhD, Redback, xiaoxipe@cse.msu.edu Abstract -- This article describes an architecture for providing the end-to-end QoS between customer premises using an MPLS-based Service Provider core network. It describes various protocols and technologies used in different networks constituting the overall transport and their interoperability. A special emphasis is given to the latest MPLS mechanisms such as MPLS support of the Differentiated Services and MPLS UNI. I. INTRODUCTION As the internetworking industry progresses from early offerings to a more competitive environment, Service Providers (SP) are considering new network features that would allow them to offer advanced services and generate additional revenues. The Quality of Service (QoS) technologies offer SPs the means of providing superior services thus setting them apart from the competition and making their operations more profitable. QoS is defined as a set of service requirements that need to be satisfied by the network while transporting a traffic flow. Various QoS mechanisms implemented in different networks serving user traffic produce the combined effect of service performance which determines the degree of user satisfaction. In early network implementations, the basic service requirements could be met with a good network design and adequate bandwidth. All traffic types were treated by the networks equally and were subject to the same deterioration during network congestion and failures. Presently, emerging advanced network technologies enable SPs to provide service differentiation. Meeting the transport requirements of a specific connection or flow with some level of guarantee requires a combination of network traffic engineering and QoS mechanisms applied to this flow. Traffic engineering forces the data flow into a path with the adequate capacity or into an alternative path in case of a failure. Along a traffic engineered path, the QoS mechanisms assure that the flow gets the appropriate treatment. Initially, the QoS mechanisms were defined for the TCP/IP networks, first as the IntServ (Integrated Services) architecture with RSVP (Resource reservation Protocol) as its signaling protocol, and then as the DiffServ (Differentiated Services) architecture. However, the TCP/IP networks operate on a hop-by-hop basis, and by their fundamental nature, cannot provide traffic engineering. The MPLS (Multi Protocol Label Switching) technology has emerged as the connection-oriented layer serving the connectionless IP networks, and therefore it provided the means for traffic engineering. By implementing QoS mechanisms in the MPLS networks, SPs can offer their customers QoS guarantees. The end-to-end path of a traffic flow usually traverses several environments including the end user s workstation and local, access and core networks. The user perception of quality is based on the end-to-end performance, and the specific QoS mechanisms of various components have to interoperate thus resulting in the end-to-end QoS. This article describes how QoS is accomplished in the local networks, the QoS mechanisms in the MPLS core, and the MPLS UNI (User to Network Interface). It builds upon the end-to-end QoS architecture defined in [E2E QoS] and emphasizes emerging MPLS capabilities. II. END-TO-END QOS WITH MPLS The end-to-end view of the QoS with MPLS is shown in Fig. 1 below. Figure 1 provides an overall view of how customer premises with Ethernet LAN are connected by an MPLS core network and illustrates various QoS mechanisms and their interoperability. Sections below address LAN (Local Area Network) QoS, Core QoS, and interworking of QoS at the LAN/Core boundaries.

VoIP GW VoIP VoIP GW Server Priority IP Data CE LER/PE LER/PE CE Server Host BE IP Data FE / GbE 802.3x 802.1D/Q MPLS UNI MPLS DiffServ with E-LSP or L-LSP PSC Host Customer LAN SP Core Network Customer LAN LAN QoS LAN to Core IW Core QoS LAN to Core IW LAN QoS Figure 1: End-to-end QoS with MPLS III. LAN QOS Ethernet is presently the most prevalent LAN technology at the enterprise customer premises. The initial Ethernet specification was based on the CSMA/CD (Carrier Sense Multiple Access / Collision Detection) technology and could not provide QoS. However, the technology has recently evolved towards the switched Ethernet implemented as point-to-point connections between exactly two stations on a segment. The switched Ethernet provided the basis for the full-duplex flowcontrolled operation where pairs of nodes receive and send data simultaneously, as defined in the IEEE 802.3x standard. Ethernet offers high transmission rates which presently include 10 Mbps, 100 Mbps Fast Ethernet (FE), and one Gigabit Ethernet (GbE). This high bandwidth in combination with the 802.3x operation is usually sufficient for the expedited treatment of the traffic flows in the LAN and may not require any additional mechanisms. But in order to provide further QoS assurance in the LAN, new standards have emerged. The IEEE 802.1Q and D standards expand the Ethernet frame header by four octets to include the Virtual LAN (VLAN) tagging and explicit user_priority information for data carried over Ethernet. The IEEE 802.1p user_priorities field (802.1p is now a part of 802.1D) uses three bits in the VLAN tag and allows to define up to eight types of traffic riding in the Ethernet frame. The 802.1D-compatible switches provide strict priority queuing and assure QoS for Voice over IP (VoIP) and other high priority traffic. Additional QoS mechanisms in the LAN may include RSVP which operates at the OSI layer 3, and mapping of RSVP onto the IEEE 802-style networks to provide service guarantees at layer 2. At present, these technologies are not widely implemented and are not further covered in this article. IV. CORE QOS The SP core network QoS approaches include a variety of methods ranging from over-provisioning to micro-control of core routers. While all approaches have their merits, an emerging standard for MPLS support of DiffServ is defined to provide hard QoS guarantees in a scalable manner. This section reviews router-based traffic management schemes, DiffServ architecture, MPLS architecture, and MPLS support of DiffServ. A. Router-based traffic management schemes The functional roles of the Core network routers include those of the edge routers and core routers. The edge routers interface SP s customers and other SP domains and therefore, they have to provide some traffic management functions including classification, metering, policing, and shaping. The

core routers are more likely just forward the packets. Traffic classification allows to identify which flow the packets belong to based on the packet header. Classified flows can then be metered, e.g., by measuring their rates and comparing them to the network policies. As the result of metering, packets may be dropped or shaped. Packet dropping is a discard mechanism also referred to as policing. Traffic shaping is the process of delaying packets within a traffic stream to cause it to conform to some defined traffic profile. Both core and edge routers may have egress packet buffers with corresponding queue servicing mechanisms. Scheduling defines in what order and amounts packets are forwarded from a queue to the egress interface. One of the most common scheduling algorithms is Weighted Fair Queuing (WFQ). To avoid flow tail drop during node congestion, routers frequently use Random Early Detection (RED) as a packet discard mechanism. B. DiffServ The router traffic management mechanisms described above could be applied to the traffic flows without discriminating between their treatment. But a basic premise of QoS is that traffic flows receive differential treatment based on their nature. The IETF has defined the DiffServ architecture to provide QoS to the aggregated traffic flows [DiffServ Def], [DiffServ Arch], [DiffServ Term]. DiffServ approach is based on a set of enhancements to the IP protocol that enable scalable service discrimination in the IP network without the need for a per-flow state and signaling at every hop that were used in IntServ. Queue servicing and packet discard in the DiffServ networks are based on the value of the DiffServ Code Point (DSCP) marked in the header of the incoming IP packet. Behavior Aggregate (BA) is defined as a collection of packets with the same DSCP value transmitted on a link in a particular direction. Ordered Aggregate (OA) is a set of BAs which share an ordering constraint. For example, a BA may define all packets that receive the same scheduling and packet discard treatment, whereas an OA may then define all packets that receive the same scheduling, possibly including different discard treatments. DiffServ implementation in a network results in the Per-Hop Behavior (PHB) of the traffic, i.e., in an externally observable forwarding treatment applied to BAs at DiffServ-compliant nodes. A PHB group that serves an OA is called PHB Scheduling Class, or PSC [DiffServ Term]. The principal standardized PHBs include Expedited Forwarding (EF) and Assured Forwarding (AF). EF is defined for traffic with the departure rate equal to or exceeding a specified configurable rate, and it is intended for real-time services with a configured throughput. AF allows four service classes of bursty traffic for a router queue assignment and three drop precedence levels to be used in Weighted RED (WRED). Each of these four classes is an example of an OA. C. MPLS in the Core The SP Core network is based on the MPLS technology [MPLS ARCH]. In the MPLS terminology, all network devices that participate in the MPLS networking are called MPLS Nodes. MPLS Nodes that also have a capability to process native layer-3 packets (i.e., can function as routers) are called Label Switched Routers (LSR). The edge LSRs are sometimes referred to as LERs (Label Edge Routers). While the LSR is the main node element of the MPLS network, several LSR variations have emerged to reflect new services being defined for the MPLS networks. Specifically, the definition of the MPLS-based VPNs [VPN] led to the need to define two edge routers, PE, Provider Edge, is the SP network, and the CE, Customer Edge in the customer network. In the MPLS VPN networks, the transit LSRs are called P (Provider router). Also, a wide acceptance of the Penultimate Hop Popping (PHP) technique has led to the distinction between the Egress LSR and its Penultimate Hop (PH). The LERs provide the interface between external IP networks and the internal Label Switched Paths (LSP), while the core LSRs provide transit services in the middle of the MPLS network. An LER originates or terminates an LSP and performs both the normal IP forwarding and the label-based forwarding. The Ingress LER accepts an IP packet and pushes an MPLS label onto it. The egress LER terminates the LSP by popping the MPLS label and resorting to the normal IP forwarding. If PHP is used, the PH does label popping and the egress LER does IP packet forwarding. The LSPs are determined by the first label in the path. FECs (Forwarding Equivalence Classes) act as a destination-based filter defining which IP packets

should be forwarded on a particular LSP. An LSP may carry more than one FEC, and a FEC may be split among several LSPs, for example, for load balancing. D. MPLS support of DiffServ From the discussion of DiffServ and MPLS, it becomes clear that each technology has its own advantages. DiffServ provides a scalable QoS approach, and MPLS provides the paths that could be traffic engineered. Combining these two approaches leads to a scalable hard QoS. [MPLS DiffServ] defines a solution for support of DiffServ over the MPLS networks. This solution allows the MPLS network administrator to select a mapping between the DiffServ BAs and the MPLS LSPs to achieve the best match for the DiffServ, Traffic Engineering and protection objectives within a particular network. For instance, it allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or separate LSPs. [MPLS DiffServ] defines two types of LSPs: 1. E-LSPs use the EXP field in the MPLS shim header to represent the packet's scheduling treatment and its drop precedence. They can transport up to eight BAs of a given FEC including multiple OAs. The mapping between EXP and PHB is either signaled or preconfigured. The label is used only for forwarding. This method requires simpler provisioning and conserves labels. 2. L-LSPs use the EXP field to represent the packet s drop precedence only, and the label is used to convey the scheduling treatment. They can transport a single OA. If the shim header is not used, the drop precedence is indicated in the encapsulating link layer specific selective drop mechanism (e.g., Cell Loss Priority (CLP) in ATM or Discard Eligibility (DE) in Frame Relay). PSC is explicitly signaled during the label establishment time and is applied based on the label value only (i.e., not considering the EXP value). Both E-LSPs and L-LSPs can be established with bandwidth reservation; the bandwidth reservation is signaled during the LSP establishment. With L- LSPs the bandwidth is dedicated to each PSC, whereas with E-LSPs the bandwidth is associated with the entire LSP possibly comprising several PSCs, and it cannot be associated with a specific router queue. For architectures where DiffServ is used on customer premises, [MPLS DiffServ] defines three interworking models. The Pipe Model and the Short Pipe Model preserve the customer-marked value of the DSCP across the MPLS network, and when a label is popped on the other side of the SP network, the same DSCP value is used again. The Uniform Model defines the DiffServ interworking at the boundaries between the customer and the SP domains. The customer-marked DSCP is mapped into the E-LSP or L-LSP and then it is mapped again on the other end. Thus combining MPLS with DiffServ provides the advantages of both technologies, the trafficengineered paths (LSPs) with the ability to provide differential treatment for various traffic classes. V. MPLS UNI In addition to well defined QoS mechanisms in the individual networks, the end-to-end QoS depends on the effective interoperability between different network domains. MPLS UNI is a new technology that serves this purpose. The MPLS Forum has defined the MPLS PVC UNI [MPLS UNI] to allow an interconnection of the MPLS-enabled Customer Premises Equipment (CPE) to the SP networks. Using an MPLS network interface rather than a non-mpls IP interface allows the CPE to use enhanced network services and QoS interworking when compared to a best-effort IP interface. It also allows MPLS interconnection with other CPE or with network services. The MPLS PVC UNI provides access to a provisioned Permanent Virtual Connection (PVC) LSP service for transport of MPLS encapsulated traffic across a public MPLS network. Each PVC LSP is characterized by the bandwidth parameters, identification attributes and bi-directional LSP binding attributes. The identification attributes include an MPLS label significant to the PVC UNI and an LSP Identifier which uniquely identifies the LSP within the public MPLS network. The main elements of the MPLS UNI are indicated in Fig. 2 below. The UNI is an interface between the PE and CE routers. Depending on the direction of an LSP, they form an upstream and downstream router pair as indicated in Fig. 2 using the notation of Ru and Rd. The unidirectional LSPs are labeled as PE-to-CE LSP and CE-to-PE LSP. The UNI is based on the Label Distribution Protocol (LDP) [LDP] which has been adopted the satisfy the UNI-specific requirements. Labels are distributed using the Downstream On-demand

procedure in the order from 1 to 4 as indicated in the Fig. The PE starts with a label request which includes the PE-to-CE LSP attributes. After the CE provides label binding, it issues a label request for the CE-to-PE LSP, using the same attributes. MPLS UNI is defined over variety of layer 2 encapsulation technologies including ATM, Frame Relay, Ethernet, PPP (Point to Point Protocol) and PoS (Packet over SONET/SDH). MPLS UNI Rd 1 2 PE-to-CE LSP data flow label request label binding Ru CE Ru Customer Premises 3 4 CE-to-PE LSP data flow label request label binding Rd PE SP Core Network Figure 2: MPLS UNI Architecture VI. CONCLUSIONS This article described miscellaneous aspects of the end-to-end QoS, and particularly the MPLS mechanisms that allow to traffic engineer the core networks and provide QoS guarantees. In also addressed interworking between different networks and the new MPLS UNI implementation agreement developed by the MPLS Forum. [6] [MPLS Arch] E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, January 2001. [7] [MPLS DiffServ] F. Le Faucheur, et al, MPLS Support of Differentiated Services, draft-ietf-mpls-diff-ext-09.txt, April, 2001. [8] [MPLS UNI] A. Malis, MPLS PVC User-to-Network Implementation Agreement: Baseline Text, MPLS Forum draft, 2002.45, March, 2002. [9] [VPN] Eric C. Rosen, et al, BGP/MPLS VPNs, draft-ietfppvpn-rfc2547bis-01.txt, January 2002. ACKNOWLEDGMENTS The authors are grateful for all constructive comments received at the MPLS Forum meetings and conferences calls. REFERENCES [1] [DiffServ Arch] S. Blake, et al, An architecture for Differentiated Services, RFC 2475, December 1998. [2] [DiffServ Def] K. Nichols, et al, Definition of the Differentiated Services field (DS field) in the IPv4 and IPv6 headers, RFC 2474, December 1998. [3] [DiffServ Term] D. Grossman, New Terminology and Clarifications for DiffServ, RFC 3260, April 2002. [4] [E2E QoS] V. Fineberg, A Practical Architecture for Implementing End-to-End QoS in an IP Network, IEEE Communications Magazine, January 2002. [5] [LDP] L. Andersson, et al, LDP Specification, RFC 3036, January 2001.

Authors Victoria Fineberg (fineberg@illinoisalumni.org) is a Senior Member of IEEE and a licensed Professional Engineer. After graduating with Masters Degree from the University of Illinois at Urbana-Champaign in 1989, Victoria joined AT&T Bell Laboratories which later became Lucent Technologies Bell Laboratories. Victoria s professional interests include interworking technologies, QoS, MPLS, VPN and VoIP. Presently, she works as a consultant. Dr. Cheng C. Chen (CChen@necam.com) received his PhD from Florida State University in 1981. He was a faculty member at the University of South Carolina in 1980 and at Temple University from 1981 through 1982. He has extensive working experience in network engineering including AT&T Bell Laboratories from 1982 through 1989, NEC America s Advanced Switching Laboratories from 1989 through 1994, MCI from 1994 through 1997, and again NEC America from 1997 to the present. He has published over twenty technical papers and holds two patents. He has taught telecommunications courses as an adjunct professor in SMU s Department of Electrical Engineering since January 2000. His research areas include IP/MPLS, QoS routing, traffic engineering, ATM switch performance, PNNI network engineering, network design, and network reliability engineering. Dr. XiPeng Xiao (xxiao@photuris.com) is Director of Product Management at Redback. Prior to that he was Director of Technical Marketing at Photuris Inc., an optical and data networking company where he worked with carriers and service providers and defined product architecture for Photuris. Prior to Photuris, XiPeng was Sr. Manager of Advanced Technology at Global Crossing Telecom. He deployed MPLS, VPN and DiffServ in Global Crossing s network. This MPLS system was the largest in the world for Internet Traffic Engineering (as of June 2001). XiPeng was also in charge of vendor evaluation and network integration in Global Crossing. Before joining Global Crossing, XiPeng worked for Ascend Communications on MPLS and QoS. XiPeng received his Ph.D. degree in computer science from Michigan State University. (xiaoxipe@cse.msu.edu)