MPLS Part I: The Search for IP Quality of Service
Quality of Service (QoS) and Class of Service (CoS) are two buzzwords many net admins hear on a daily basis. A can of alphabet soup could not likely spell out all the acronyms and jargon surrounding QoS, CoS, voice over, committed information rate, and related technologies, but the net admin can often turn to Internet standards to provide solutions to today's and tomorrow's networking needs. Multiprotocol Label Switching (MPLS) is one such standard that provides some of the building blocks for providing QoS over IP backbones.
Although MPLS is not limited to IP, do not be fooled by its name. MPLS's major application will be used to add features required for QOS features for the Internet protocol. Before taking a closer look at MPLS, I will examine some of the history of the Internet Protocol and QoS fundamentals.
IP has served the Internet community well and, besides the publicity created by the World Wide Web, is one of the most important technologies that has allowed the tremendous growth of the Internet. The TCP/IP protocol suite has ensured system interoperability and open standards for all computer systems from the lowest cost personal computer running a single-user, single-tasking system to the largest multi-user, multi-system operating environments on the planet. In addition to wide OS support, IP has received wide media support that has ensured its support in all but the most legacy-conscious networks.
IP's strongest characteristics have been its connectionless design and its store-and-forward (or hop-by-hop) routing support. IP allows a host to be connected to the Internet without any knowledge of the network except a default router to send all non-local traffic to. Although a bit oversimplified, this allows the host to communicate with any other IP host regardless of OS, the physical media, or path involved.
In the simplest form, IP packets are forwarded based upon the destination address. Of course, the route for the destination can be a default route (represented by a 0.0.0.0 in a routing table), a supernet that includes the destination network, the destination network, or even a host-specific routing entry.
Policies and Traffic Shaping
Policy-based routing added functionality to the routing algorithm available within IP internetworks. Although policy-based routing was not likely foreseen by early IP developers, the IP protocol connectionless design ensures future routing implementations, or practices, will not likely break applications as long as reasonable network connectivity is provided. Policy-based routing allows routing decisions to be made based upon other bits stored within the IP packet in addition to the destination address. Examples include source address, source or destination port (TCP, UDP), and a combination of these as well as any other bits within the packet. For example, all http traffic could be routed through a shorter path to ensure a quicker response for user interaction. An ISP might route NetNews through a high-latency satellite link to keep the non-time sensitive, but large bandwidth hog off the backbone.
The original IP designers did designate one byte as a type of services that can be used for policy based routing; however, its use has not been widely adopted, nor are there common practices. Thus, each network manager applies policy differently based upon local need. A formal use of the byte is defined in RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, so common practices are being implemented. Additionally, network engineers and designers are asking developers to include support for controlling the bits in both hosts and routers.
In addition to policy-based routing, traffic shaping can be deployed to attempt to guarantee bandwidth with the possible affect of starving other network applications. Traffic shaping uses internal queuing and algorithms to route or switch important traffic prior to not-so-important traffic. For example, an organization can guarantee a certain percentage of a leased connection to its Web server. This could ensure that incoming email does not affect the customers surfing experience to the site. (This type of management is more accurately called Class of Service (CoS), but the difference between the two is usually a question of granularity. Certain applications such as voice over IP imply QoS, but depending on the application, this is not necessarily true.)
The biggest weakness with policy-based routing and traffic shaping for attempted Quality of Service is that its use is typically limited to networks under one management's control, and the implementation can become management intensive and cumbersome as the number of apps requiring QoS rises. Larger pipes and vendor innovations, however, have made for some cutting edge designed networks beyond what anyone envisioned with IPv4.
Even with these limitations, QoS functionality is required and being sought for large interconnected networks without losing the large investment in IP networks. Voice and data convergence is a big push for QoS functionality, but service providers also wish to tap further into VPN solutions. Currently, service providers offer transport for VPNs and, in many cases, provide access to the VPN through tunneling protocols. With a QoS backbone, providers can provide granular-proven bandwidth that formerly would require a private network to guarantee the bandwidth. Additionally, flexible, customized services can be provided by service providers to meet ever changing enterprise needs. For example, bandwidth on demand through the backbone or Frame Relay characteristics such as bursting could be provided to the customer.
Two of the most limiting factors for QoS functionality with IP backbones are the lack of end-to-end classifying of traffic and slow (when compared to label or cell switching) hop-to-hop routing algorithms based upon the destination address. Local network managers can shape traffic with little affect if the Internet cloud is not providing the necessary bandwidth. Also, label switching is based upon a much shorter address label, which means quicker forwarding by the router involved. (Note that the end-to-end functionality required by QoS would likely have killed IP if it had been an original requirement.)
The Internet Engineering Task Force (IETF) realized that the current practices do not scale well to internetworking and often lend themselves to closed vendor-specific solutions. Therefore, the MPLS Working Group was assigned the task of defining protocol functionality for forwarding (switching within the MPLS and routing speaking of layer 3 forwarding) packets that provides open standards and functionality to the Internet community. The MPLS Working Group's Web page at http://www.ietf.org/html.charters/ \
mpls-charter.html should be your starting point for MPLS. MPLS's documentation includes the framework document, the architecture, stack encoding, and several other documents.
MPLS is not the ultimate end to providing QoS across IP networks, rather its goal is to provide end-to-end forwarding equivalence class, which means that all traffic of the same class is switched in the same matter. This basic building block and addition to IP breaks the major hurdles of end-to-end classification and optimizes switching decisions with the smaller address (label).
MPLS should be portable to any networking technology, but the popular networking technologies Ethernet, Frame Relay, and ATM are where vendors are placing immediate emphasis on deployment. Since the label must ride with the frame in framed networks such as Ethernet, there are cases where fragmentation is required to squeeze the label into the original frame. Network designers will recognize this encapsulation method as popular for protocol tunneling and VPNs in current networks. Unfortunately, a lot of the comparisons of implementations and functionality stop there. Unlike the layer 3 IP address, the label address is not a globally significant address, but rather has only local significance. Thus, it changes (is swapped) as the packet traverses the network. (MPLS is not the first protocol to use local significant addressing -- Frame Relay's Data-Link Connection Identifier [DLCI] identifies circuits but also has only local significance.)
The MPLS switching algorithm predetermines the path for the traffic as determined by the network management. IP network managers may be surprised to see an IP network that determines the routing path at the networks entry (ingress) and where the layer three address is no longer examined within the the MPLS network (domain).
In the June issue, I will cover the MPLS topology including the MPLS domain, the label switching router (LSR), the MPLS ingress and egress nodes, flows, streams, and stream merging. Additionally, the label format and the label distribution protocol will be covered. Although MPLS is usually deployed with network devices, I'll also point you to some host-based MPLS development sites.
About the Author
Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for Software Spectrum, Inc. as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: firstname.lastname@example.org.