The first implementation of a Multiprotocol Label Switching (MPLS) virtual private network (VPN) service with guaranteed Quality of Service (QoS) is an experience of multiples in more than one way -- multiple layers of tasks await service provider engineers.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
What can you guarantee?
Before you start offering MPLS QoS to your customers, you should carefully evaluate what you can reasonably provide and how the guarantees will fit into your overall service portfolio. There are two basic models of QoS offered by service providers running MPLS-based networks.
- Pipe model -- or site-to-site QoS: Similar to those offered on Frame Relay or ATM networks, this type of QoS is called the pipe model -- as you are providing the quality on a point-to-point virtual pipe linking two sites.
- Hose method QoS: Alternatively, you can offer QoS guarantees on inbound and outbound traffic for each site. For example, you promise to deliver 10 Mbps of traffic sent by site X regardless of the destination of the traffic. This approach is called the hose model.
Obviously, the hose model is less precise than the pipe model. For example, if a high-speed site sends a 100 Mbps video stream to a low-speed site, most of the traffic will be lost before being delivered to the low-speed site, yet it will do so without violating the QoS guarantees. The hose model is also harder to engineer, as it is more difficult to reliably predict where the traffic will actually go.
With the pipe model, traffic engineering tools similar to those used in Frame Relay or ATM networks can be used to ensure optimum network performance. The hose model cannot be engineered so precisely. Therefore, the hose model should be used for only a relatively small percentage of the overall traffic mix.
The choice of the pipe or hose QoS model depends heavily on the type of VPN service offered. The pipe model is ideal for point-to-point services, including Any Transport over MPLS (AToM), point-to-point VPN services, or hub-and-spoke MPLS VPN services with no direct inter-spoke communication. The hose model is the only viable model for any-to-any service, including full mesh MPLS VPN service and Virtual Private LAN (VPLS) service.
Implementing MPLS QoS
All MPLS QoS implementations use the differentiated services (DiffServ) model. Routers use three bits, called Experimental bits for historical reasons, in the MPLS header of each packet transported across the MPLS network to differentiate the traffic. This allows eight traffic classes to be implemented; though one is usually reserved for default traffic class, leaving only seven actual classes. If you want to offer in-contract/out-of-contract QoS, similar to the DE bit in Frame Relay or CLP bit in ATM, then only four traffic classes will remain as one bit is needed for the out-of-contract indication. Four traffic classes should be enough to cover the needs of most service providers.
The traffic classification is usually performed by the service provider edge routers (PE routers). These routers should measure the compliance of the customer traffic, sort the traffic into MPLS traffic classes, optionally mark the out-of-contract traffic and drop excess traffic.
In most cases, the customers that care about QoS want to retain their DSCP markings for end-to-end QoS control. To satisfy this request, PE routers have to measure the traffic and set the MPLS Exp bits directly. The MPLS markings are retained from the ingress PE router to the egress PE router, giving this method the name short pipe mode.
Advanced customers might want to retain flexibility and decide to set the in-contract/out-of-contract bits themselves like they used to do on Frame Relay or ATM networks. In these designs, the MPLS label switched path (LSP) has to be extended to the ingress customer edge (CE) router, thus this method is called long pipe mode.
Regardless of the way the MPLS experimental bits were set on the network edge, they can be used to sort packets into output queues with different QoS parameters or to implement selective drop for out-of-contract packets on oversubscribed links.
Note: Don't forget that most routers operate in uniform mode, unless configured otherwise, copying IP DSCP values in MPLS experimental bits. As soon as you implement differentiated queuing on your core links, you should mark all the inbound traffic on your network edges with explicit value of MPLS experimental bits -- otherwise non-paying customers will be able to hijack your high-priority queues.
Improving QoS guarantees will help service providers differentiate themselves from their competitors. A few simple planning steps listed below will ensure that service providers are on the right track.
- Figure out what customers actually need. Copying competitor's models will not provide any advantage.
- Design QoS offering based on the expected traffic flows of services. For example:
- If SPs offer point-to-point services, the pipe model (guaranteeing end-to-end bandwidth or delay) is best.
Note: Networks can be engineered better when using the pipe model, but this model cannot be applied to all VPN services.
- If customers want to have full-mesh VPN connectivity, it is better to use the hose model which guarantees inbound and outbound bandwidth on each site.
Once the QoS service definitions have been decided, implementation can be started:
- Map the QoS service offerings into MPLS traffic classes. Remember, only three bits are available to mark traffic, and hardware implementation on networking gear might further limit the available choices.
- Protect yourself. Before configuring QoS mechanisms in the network core, ensure that regular customers cannot insert high-priority traffic into your network.
- Configure queues and selective drop of out-of-contract traffic. Determine in advance what traffic receives priority and what traffic needs to be dropped from your core links. Use the MPLS experimental bits to sort packets into output queues.
- Configure metering and marking. All inbound customer traffic should be marked or policed and metered.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks. He is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. For more expert advice from Ivan, you can read his blog, Cisco IOS hints and tricks.