Bits 'n' pieces of the Networked world

I had touched upon Multi-protocol Label Switching (MPLS) in one of the earlier issues, and mentioned that I'd come back to the topic sometime later. After having been privy to some information shared at the recent MPLS Congress, I feel that it is time for me to revisit the topic in the light of all of the industry advances. The recent past has seen rapid developments in this technology, with routing and switching companies helping move it from the research labs all the way into marketing collateral and RFPs. I have seen MPLS flavours being positioned aggressively by different vendors in the internetworking space over the last one year, and while its deployment might not exactly be in line with what is envisioned and enshrined in the RFCs, MPLS and its applications are definitely being used as differentiators.

MPLS Overview
At the risk of repetition, and for the first time readers of this issue, let me spend a few paragraphs giving a brief overview of the MPLS concept. MPLS started off as a standardized effort on the part of the Internet Engineering Task Force (IETF) to quicken switching in a multi-protocol environment and to aid in traffic engineering.

Consequently, it deals with the designation, routing, switching and forwarding of traffic flows through a network.

It combines the best of both routing and switching, and has perhaps brought the power of both IP and ATM together. While it does not fit into any part of the OSI model by itself, MPLS supports IP, ATM and Frame-Relay L2 protocols. It also provides interfaces to existing routing protocols such as BGP and OSPF, specifies mechanisms for controlling and managing traffic flows of varying granularity and perhaps most important, defines a labeling mechanism that maps IP addresses to simple, fixed-length labels.

These labels are at the core of the MPLS concept. How do they help? And what are they? Simply put, these labels are path identifiers. MPLS uses labels native to the media. They are encapsulated in Layer-2 headers along with the IP packet. See Figure 1.0. The MPLS header must include a label or a stack of labels. It may also include other information relevant to label forwarding like the Time to Live (TTL), Stack indicator, Class of Service, or the type of next-header indicator especially if it is non-IP. So now, routers along the path base their routing decision upon the labels, and do not get into stripping the packet open.

Labels and the FEC
Now remember, in a large traditional routed network, the routing decision essentially hinges upon the elements in the forwarding table viz. the destination address prefix, or the value of the Forward Equivalence Class (FEC). The FEC is evaluated at each router based on the IP header content, and this exercise not only proves costly (in terms of having routers with greater processing power), but also introduces a lot of overheads. Paths are derived from the SPF routing protocol, and packets with the same FEC follow this path.

MPLS allows for grouping of packets, and applying rules to them. This forms part of the FEC. Packets can now be assigned to the FEC, and the beauty of this is they are assigned just once, at the point of entry (ingress) into the network.

MPLS has its genesis in the need to forward a series of packets from the same ingress to the same egress on a given path, without evaluating the FEC at each intermediate node. The idea was to introduce a soft (or even hard) connection that would act as a path over which the packets would be switched using labels identifying the FEC. In doing this the FEC evaluation is done only once, when the packet enters the network. Here the FEC represents a group of packets having similar requirements for transport. Packets in one FEC group would be subjected to the same generic rule or treatment. After this, the label is inserted into the packet, and at each router, the label will be swapped, and packet with the new label is sent to the next hop. So the label assignment and removal are the concern of the ingress and egress node, while most of the other nodes are concerned with label swapping. (See Figure ).

Traditionally, routers are involved in analyzing an IP packet header, not just for determining the next hop, but also to determine a packet's precedence, or Class of Service. Some policies may then be applied to the packet based on the information so obtained. MPLS allows for this information to be inferred from the label, and it is fair to say that the label represents a combination of a routing based FEC, and a precedence or class of service. Since MPLS does not require labels to be analyzed, switches that are MPLS enabled can also do packet forwarding.

In a conventional network, routing decisions are enforced by algorithms that calculate the shortest path to a network, or one with the highest bandwidth rather than the one that is most optimal. Optimality is not an outcome of one or two factors, but one that is based on various metrics such as delay, congestion, jitter and bandwidth, apart from the number of 'hops'.

Data transmission
The data transmission in MPLS is through Label Switched Paths (LSPs), which are sort of virtual paths from the source to the destination. Like ATM, these LSPs can be established prior to data transmission, or can be set-up at flow time. MPLS labels serve as protocol-specific identifiers and are distributed using traditional routing protocols like BGP, OSPF or by the Label Distribution Protocols (LDP). MPLS has label stacking, which means that they can be provisioned once, and the same LSP can be used for multiple purposes.

At the heart of the network, MPLS has the concept of high-speed core Label Switching Routers (LSRs) which participate in the establishment of Label Switched Paths (LSPs) and are responsible for high-speed switching on these paths. At the Edges are the Label Edge Routers (LERs), or the Edge LSR that operate on the MPLS and access edges. The LERs are primarily concerned with the assignment and removal of labels as traffic enters into, or goes out of an MPLS network. (See Figure 1.0)

Route selection in MPLS
Label switching supports two explicit route selection models. One is the traditional "hop-by-hop" mode used in existing IP networks with protocols like OSPF. The second is by means of an explicit route selection. In MPLS the explicit route has to be specified at the time of label assignment. This makes it to be a more efficient protocol than IP since, the entire route is specified by either the ingress or egress LSPs. This route information is often picked up from topological data learned from a link state database, and makes the process of switching quite fast.
MPLS Lambda Switching (MPlS) / Generalized MPLS

With the market for optical switches and routers shifting gears over the last few years, MPLS Lambda switching has hit the ground running. MPL(ambda) switching has extended the MPLS paradigm into the optical domain, by using an MPLS-like control plane, to control the optical cross-connects, which are the fundamental building blocks of optical networks. It combines the control plane of MPLS with the point-and-click provisioning capabilities of photonic switches to offer a flexible service-based switching model.

The derivative protocols enable equipment in the service layer to dynamically request for bandwidth services from the transport layer using existing control-plane techniques. In addition to advertisements and path establishment, MPlS includes performance related information on the network. The Edge routers, which actually deal with services will use this information to dynamically manage the available wavelengths in the photonic layer.

MPLS is now a part of Generalized MPLS (GMPLS). The goals of GMPLS include extending MPLS support to multiple switching types including TDM (SONET), Wavelength (lambda) and Physical port (Fiber) switching. The extension of the MPLS control plane into the optical domain is largely accomplished by treating components like circuits, lambdas (wavelengths) fibers and bundles as labels.

GMPLS seeks to establish a single control-plane that would not be tied down to any particular vendor, technology or architectural approach. It also aims to facilitate parallel evolution in both the IP and Optical transmission domains, thereby lending credence to the much-touted 2-layer network. If this concept evolves further, it could simplify the integration of optical switches, optical transport mechanisms, and the original label-switching routers.

MPLS standards
That it is an emerging standard is evident by the fact that some of the first RFCs related to MPLS (RFC 3031-3038) came into existence as late as January 2001. (See Figure 3.0). The MPLS working group has so far produced over 40 Internet drafts, and is presently branching into new working groups like the Provider Provisioned VPNs (PPVPNs) and Common Control and Management Protocols (CCAMP). As always, interoperability issues are also being addressed at the famous University of New Hampshire Interoperability lab, and at the Advanced Internet lab at the George Mason University. While it too early to proclaim interoperability between vendors and implementations, if the MPLS concept has to succeed in the larger context of the Internet, it should happen in due course of time.

From a standards perspective, work on Label Distribution Protocols (LDP) is forthcoming. LDP is a set of procedures and negotiations where LSRs communicate with each other to exchange their label/FEC bindings, find out their MPLS capabilities and set up label-switched paths (LSPs). A number of LDPs are being standardized. Existing protocols are being extended to allow LDP to piggyback on them, leading to MPLS-BGP, MPLS-OSPF, MPLS-RSVP etc., while new ones like MPLS-LDP and MPLS-CR-LDP are being developed exclusively for label distribution.

A large part of the networking community is behind the development of MPLS-CR-LDP, while some vendors like Cisco and Juniper networks are promoting the concept of RSVP to establish ER-LSPs. Constraints introduce a lot of flexibility into traffic engineering. Some constraints like bandwidth, resource class, class of service and priority settings can be introduced to make the MPLS label have more "characteristics", and give it the proper treatment.

In other words, these are specified as "path attributes" for each LSP. The Constraint- based Shortest Path first (CSPF) algorithm deals with this. Organizations are aligning one way or the other, and at some point they are going to converge, and find themselves non-interoperable, and that is when the fun starts.

MPLS - Deployment issues
One must note that MPLS by itself is not a solution, but is a part of a whole. In other words it is but just a component in the switching and routing domain. Unlike popular misconception, the Integration of IP and ATM is but one of the applications of MPLS, and not the only one. It also does not make the routers run fast, by virtue of the algorithm itself, but being simpler than the IP forwarding algorithm certainly helps in speeding up the process.

In India, it would perhaps make some sense for only the large ISPs to deploy MPLS-enabled equipment in the near short-term, and not necessarily MPLS-ready. Even then I'd advocate a play of wait-and-watch for sometime. With VPNs becoming so critical to secure connectivity access MPLS VPNs might turn out to be a necessity in large ISP networks, and if properly deployed can enhance performance to a degree. It is wise to perform a detailed

requirement analysis as always before considering any deployment starting from a detailed lab test.

Most MPLS features have an impact on performance one way or the other, and this needs to be studied carefully. Scalability issues are still being addressed, as are load-sharing and the all-important security features.

All in all, MPLS and its applications have some way to go, before they can claim domain mindshare. They seem to be getting there as well. Without doubt, it is an exciting technology that is being adopted by many vendors in the IP, Optical and the ATM space. But for those interested in deployment, it might just be prudent to be a bit cautious for now, and save that extra dollar for a feature that is immediately usable.

Stay tuned, and Happy Networking!! NM - N. Shashi Kiran works for Nortel Networks at Santa Clara, as a Product Manager. The views expressed are his own, and not that of the organization. He can be reached at shashikiran_n@hotmail.com