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. But advanced planning will start the project out on the right track to a successful deployment. So when the engineers start talking about pipes and hoses, don't worry, those terms are actually used in MPLS quality of service jargon.
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.
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.
To continue reading for free, register below or login
To read more you must become a member of SearchTelecom.com
>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. The easiest marking algorithm modifies the DiffServ Code Point (DSCP) value in the original IP packets. The packets are then transported across the MPLS network with MPLS experimental bits matching the value of the IP DSCP. This approach is called the uniform mode, as the MPLS experimental bits match IP DSCP value.
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.
Conclusion
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.
Once the QoS service definitions have been decided, implementation can be started:
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.
