MPLS Part II: A Closer Look

Ron McCarty

In last month's column, I covered IP routing, IP policies and traffic shaping, and the purpose of MPLS. As promised, this month I will cover the MPLS topology and traffic terminology, and some host-based MPLS development sites to watch.

The Need for MPLS: Internet Service Provider Core Networks

ISPs, especially in the United States where bandwidth demand has been greatest, have integrated Asynchronous Transfer Mode (ATM) switches in the backbone as bandwidth needs have increased and ATM tariffs have dropped. Unfortunately, despite strong standards unification among vendors, the quality of service guaranteed with ATM has not been gained with IP over ATM. IP routing was often performed at the edge of the ATM network; until recently core ATM network providers did not have enough demand to integrate IP throughout a network core. However, as pointed out by IP proponents (and others who have reason to minimize ATM networking, such as gigabit supporters) the complexity of supporting at least two network infrastructures (ATM, IP, and often Frame Relay) should not be overlooked. Even ISPs willing to overcome the challenges of IP over ATM have realized that the cell switching provided by ATM could not be provided by their routers.

MPLS seeks to meet these challenges by providing switching based upon a layer 2 address (the label), and to not be specific to ATM. Additionally, quality and class of service classifications as mentioned last month, can be performed by MPLS giving ISPs (and other IP networks' cores) a speedy layer 2 switched network with the capability of providing value-added services based upon QoS, CoS, and VPN solutions.

MPLS Topology

MPLS can seem complex when first approached because much of the IETF's documentation is written specifically enough to encourage vendor and Internet acceptance. But, like IPSec standards, it is covered in many documents. After an understanding of the issues discussed last month, a closer look at the MPLS architecture is the next step in gaining a better understanding of MPLS. Refer to the MPLS Topology diagram (Figure 1) to see where the particular network element fits into the topology. Using the topology covered here, I will also explain what is happening within the switching algorithm within each element.

The MPLS ingress node is the first and only label switch router (LSR) that examines the IP address (layer 3) while the packet is in transit through the MPLS domain. The ingress LSR examines the packet to determine its forwarding equivalency class (FEC). The FEC determines the path traffic will take as well as possibly determining further classification of the traffic. For example, low-priority traffic may not only take a longer path through the network, it may also be placed in routing queues with low priorities within the backbone's routers.

FECs based upon IP source or destination address immediately come to mind as possibilities, but FEC definitions are only limited by vendors' creativity and customer demand. Since the definition takes place at the edge, every LSR within the domain does not need to know how the FEC is determined. As mentioned in the IETF docs, an FEC can be defined based upon the interface through which the traffic enters the network, the ingress FEC, or other criteria that cannot be determined by the IP header. Also note that an FEC can contain definitions that appear completely unrelated, but since the definitions are with the same FEC, the differing definitions will be treated the same throughout the network. (This may mean the traffic will take the same path, or multiple paths, based upon a load sharing or policy routing.)

The IETF MPLS forum mentions some FECs based upon the IP header in paragraph 2.2.2.1 of the Framework For MPLS at:

http://www.ietf.org/internet-drafts/  \
   draft-ietf-mpls-framework-05.txt

PQT (Port Quadruples with TOS) -- Same IP source address prefix, destination address prefix, TTL, IP protocol, and TCP/UDP source/destination ports and same IP header TOS field (including Precedence and TOS bits)

HP (Host Pairs) -- Same specific IP source and destination address (32 bit)

NP (Network Pairs) -- Same IP source and destination address prefixes (variable length)

DN (Destination Network) -- Same IP destination network address prefix (variable length)

ER (Egress Router) -- Same egress router ID (e.g., OSPF)

NAS (Next-hop AS) -- Same next-hop AS number (BGP)

DAS (Destination AS) -- Same destination AS number (BGP)

Once the FEC is determined, a label is encapsulated into the packet for transmission. (The addition of a label is referred to a push, and the removal is referred to as a pop.) The encapsulation is specific to the network being used (such as ATM, frame relay, or Ethernet), but a generic term, MPLS encapsulation, is used to describe the function.

The label, like its frame relay's Data Link Circuit Identifier (DLCI) and ATM's Virtual Path Identifier/Virtual Circuit Identifier (VPI/VCI) layer 2 addresses, has only local significance between the two LSRs in the communication. This is unlike the IP address, which requires global significance throughout the Internet. Once MPLS encapsulation is complete, the packet is switched to the appropriate LSR based upon that label. (In case you missed it above, this is the last time within the MPLS domain that the IP address is examined.)

The next LSR examines the label to determine the packet path, any QoS or CoS policies it should apply, and its new label and switches the packet accordingly. Of course, because there are never enough acronyms in the IT industry, the IETF defined one for this process: NHLFE. NHLFE stands for Next Hop Label Forwarding Entry. Note that MPLS actually supports multiple labels in order to support MPLS tunneling and other features, but this is beyond the scope of this column. For additional information, consult paragraph 3 of the IETF's MPLS Architecture document at:

http://www.ietf.org/internet-drafts/  \
   draft-ietf-mpls-arch-06.txt

The path that the packet has taken is called the label switch path (LSP) and can be compared to a virtual circuit. The LSP is not bi-directional. The return LSP can be the same path, but it is not defined by the same FEC policies.

Figure 1 does not show which protocols are used to distribute label information. The protocols are appropriately named Label Distribution Protocols (LDP). In addition to this generic term, the IETF MPLS working group formalized an LDP in the IETFs LDP Specification at:

http://www.ietf.org/internet-drafts/  \
   draft-ietf-mpls-ldp-06.txt

http://www.ietf.org/html.charters/mpls-charter.html

Although MPLS provides the speed and robustness of a layer 2 network, additional functionality for QoS is needed. MPLS is compatible with the Integrated Services Model defined in RFC 1633:

http://src.doc.ic.ac.uk/computing/  \
   internet/rfc/rfc1633.txt

http://www.ietf.org/html.charters/  \
   rsvp-charter.html

Host-Based MPLS

It would appear that MPLS would also be a welcome change to host's IP stacks since the principals can be applied to local networks; however, this is often not practical. Network and systems administrators and organizations have invested heavily on current IP LANs with switched Ethernet networks. Without a killer application that requires MPLS, organizations will expect applications to make other compromises with the stack to get near QoS. In addition, the complete security model of most organizations is based upon examination of the IP header. Internal, extranet, and Internet security models have been developed over years in many organizations and will not easily move to new technology without a major business need (application) for the technology.

There has, however, been some development of host-based MPLS stacks. Expect most host development to come from universities and the Open Source movement until a market arises for MPLS, which is questionable.

NIST switch, developed by the National Institute of Standards and Technology is available at:

http://is2.antd.nist.gov/itg/nistswitch/

Jim Leu's freely available MPLS support for Linux is available at:

ftp://nero.doit.wisc.edu/pub/mpls/

http://www.nortelnetworks.com/products/  \
   announcements/mpls/source/index.html

Stay tuned to MPLS, you'll see it changing the way the Internet works in the coming years.

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: ronald.mccarty@gte.net.