Quality of Service Solutions for Service Providers

Cisco IOS MPLS Quality of Service

Table Of Contents

White Paper


Cisco IOS MPLS Support for the DiffServ QoS Architecture

MPLS QoS Service Models

Point-to-Cloud Model

Point-to-Point Service Model



White Paper

Quality of Service


Comprehensive quality of service (QoS) functionality is a signature capability in Cisco IOS® Multiprotocol Label Switching (MPLS). QoS represents the set of techniques necessary to manage network bandwidth, delay, jitter, and packet loss. From a business perspective, it is essential to assure that the critical applications are guaranteed the network resources they need, despite varying network traffic load.

Service providers offering MPLS VPN and traffic engineering (TE) services can now differentiate themselves by providing varying levels of QoS for different types of network traffic. For example, voice-over-IP (VoIP) traffic receives service with assured minimums of delay and bandwidth, while e-commerce traffic might receive a minimum bandwidth guarantee (but not a delay guarantee). For traffic that needs a point-to-point (site-to-site) guarantee, Cisco DiffServ-Aware Traffic Engineering (DS-TE) engages to ensure QoS.

Cisco IOS MPLS Support for the DiffServ QoS Architecture

DiffServ is one of two QoS architectures for IP networks defined by the IETF. In this model, packets entering a DiffServ-enabled network are grouped into a small number of classes. For example, VoIP packets can be grouped into the premium class, while e-commerce HTTP packets are grouped into the gold class, and so on. Furthermore, each class has a color or mark associated with it. This makes packet classification extremely scalable and assures appropriate bandwidth and delay guarantees in the network core. Thus, when they enter the network, packets are marked based on classification policies at the network boundary nodes. The boundary nodes also apply traffic conditioning functions to control the amount of traffic entering the network. Traffic conditioning includes shaping (smoothing the rate at which packets are sent into the network) and policing (dropping packets that are in excess of a subscribed-to rate; or re-coloring the ones exceeding the rate, so that the probability of dropping them increases when there is congestion in the core). Each node within the network then applies different queuing and dropping policies on every packet based on the marking that packet carries.

Cisco IOS MPLS supports the IETF DiffServ architecture by making the rich set of Cisco QoS functions MPLS aware, and by enabling the features to act on the MPLS packets (Table 1).

Table 1  QoS Functions and Corresponding Cisco IOS Enabling Features

QoS Functions
Cisco IOS Enabling Features

Traffic Classification

Access Control List matching

Traffic Marking

DiffServ Code Point (DSCP)

MPLS Experimental (EXP) field

Congestion Management

Low-Latency Queuing (LLQ)

Class-Based Weighted Fair Queuing (CBWFQ)

Congestion Avoidance

Weighted Random Early Detection (WRED)

Traffic Conditioning

Shaping and Policing

Figure 1 IETF Differentiated Services (DiffServ) Architecture

Two general approaches are used to mark MPLS traffic for QoS handling within an MPLS network in the first method, the DiffServ "coloring" information is carried in the experimental (EXP) field of the MPLS shim header. This field allows for eight different QoS markings. Label Switched Paths (LSPs) using this approach are called E-LSPs, signifying that QoS information is inferred from the EXP field.

Alternatively, IETF specifications allow for a second method of carrying the DiffServ information. Here, the label associated with each MPLS packet carries the portion of the DiffServ marking that specifies how a packet should be queued. The dropping precedence portion of the DiffServ marking is carried either in the EXP field, if an MPLS shim header is being used, or on fields available for this purpose on underlying technologies (for example, CLP bit for ATM and DE bit for Frame Relay). Switching paths within the MPLS network using this approach are called L-LSPs, signifying that QoS information is inferred, in part, from the MPLS label.

LSPs supporting DiffServ may be established with bandwidth reservation. That is, bandwidth requirements for a label switched path could be signaled at LSP establishment time. Bandwidth reservation could be used to perform admission control on the DiffServ resources that have been provisioned. Though admission control can be performed on an LSP basis, the QoS design within the MPLS network is DiffServ-based, taking advantage of the scalability benefits implicit in that QoS architecture.

MPLS QoS Service Models

With Cisco IOS MPLS, service providers can use either or both of two approaches to implement QoS guarantees to customers: the "point-to-cloud" model and "point-to-point" model.

Point-to-Cloud Model

Service providers (SPs) offering QoS services will want to provide an Ingress Committed Rate (ICR) guarantee and an Egress Committed Rate (ECR) guarantee, possibly for each service class offered. ICR refers to the traffic rate coming into the SP network, given a particular treatment (Premium, Gold, and so on) throughout the SP network. ECR refers to the traffic rate that is given a particular treatment from the SP to the customer site. As long as traffic doesn't exceed ICR and ECR limits, the network provides bandwidth and delay guarantees. For example, as long as HTTP traffic doesn't exceed 1 Mbps (into the network and out of the network to the customer site), bandwidth and low delay are guaranteed. This is the point-to-cloud model because, for QoS purposes, the SP need not keep track of traffic destinations, as long as it the destinations are within the ICR/ECR bounds. (This model is also sometimes called the "hose" model). (See Figure 2)

Figure 2 Cisco MPLS VPN QoS: The "Point-to-Cloud" Model

With Cisco IOS MPLS, a service provider's QoS guarantees can be "transparent" to customers. That is, a service provider can provide these guarantees in a nonintrusive way. Customer sites can deploy a consistent, end-to-end DiffServ implementation without having to adapt to a service provider's QoS implementation. A service provider can prioritize a customer's priority traffic without remarking the DSCP field of the IP packet. A separate marking is used to provide QoS within the MPLS network and it is discarded when the traffic leaves the MPLS domain. The QoS marking delivered to the destination network corresponds to the marking received when the traffic entered the MPLS network.

Point-to-Point Service Model

For the more stringent applications, where a customer desires a point-to-point guarantee, a virtual data pipe needs to be constructed to deliver the highly critical traffic. For example, an enterprise may want two hub sites or data centers connected with high service level agreement guarantees. DiffServ-Aware Traffic Engineering (DS-TE) engages, automatically choosing a routing path that satisfies the bandwidth constraint for each service class defined (such as Premium, Gold, Silver, or Bronze). DS-TE also relieves the service provider from having to compute the appropriate path for each customer, and each service class, per customer. This is referred to as the point-to-point model (sometimes also called the "pipe" model). (See Figure 3)

Figure 3 Cisco's Solution for MPLS guaranteed bandwidth services

: The "Point-to-Point" Model


Cisco QoS is a key technology that enhances existing MPLS services and allows service providers to build new revenue-generating services. The Cisco IOS MPLS QoS model is built around the IP QoS model, providing a natural fit between the two technologies. Service providers can offer differentiated services to customers and still preserve customers' internal QoS policies. Moving forward, DiffServ-Aware Traffic Engineering will add to QoS Transparency by allowing service providers to create TE tunnels based on DiffServ markings. This will enable service providers to provision guaranteed pipes for creating virtual leased lines and voice trunking offerings.


Le Faucheur, et al., "MPLS Support for Differentiated Services", work in progress, draft-ietf-mpls-diff-ext-08.txt, February 2001

Blake et al., "An Architecture for Differentiated Services", RFC-2475, December 1998

Rosen et al., "Multiprotocol Label Switching Architecture", RFC-3031, January 2001