MPLS: Breaking Through, A Status Report

By Bill Michael

MPLS: At the Edge and in the Core

One of the earliest advocates of voice-over-MPLS in the vendor community, and probably the best-known proponent of using MPLS for access networks, is a young company called Integral Access (Chelmsford, MA - 978-256-8833) that builds IADs and edge termination platforms to carry different types of IP traffic. From a high level, the Integral Access PurePacket system looks not unlike a multi-service DSL architecture: Both have CPE that collects and unifies a customer's voice and data traffic, and communicates with a box that aggregates and terminates this traffic at the service provider's edge. Where Integral Access differs is that its products (as their name suggests) are purely packet-based; so instead of employing ATM transport and its related QoS mechanisms and standards (e.g., AAL2 for VoATM), they looked for a way to accomplish similar functionality within the scope of IP. From the company's perspective, MPLS was a natural choice.

The efficiency and bandwidth utilization advantages of IP over ATM are by now well known. For Integral Access, MPLS provides a way to reap these benefits without having to sacrifice quality assurance. By implementing Label Switched Paths between their CPE and their network equipment, they can recognize different types of traffic (based on factors like IP and MAC addresses, originating port numbers, etc.) and group it into any of four classes of service categories, allocating different flows to particular paths accordingly. Since the LSPs are unique, performance can be monitored on a per-flow basis, and related back to individual applications, which enables a provider to offer several different classes of SLAs.

With respect to voice, the company has also been able to leverage a somewhat less obvious advantage of MPLS. Both the CPE and the edge device in this model serve as media gateways, to packetize and unpacketize voice that originates and terminates as standard TDM. Rather than using standard IP packet headers, however, Integral Access has done something unique: They actually replace the header with an MPLS label, instead of simply adding to it, thereby cutting down on overhead. While this isn't much of a concern in the core network, where bandwidth is abundant enough to make such distinctions unimportant, it can have a real impact in the access, especially where subscribers are running at sub-T1 rates. It also lets the edge and CPE devices avoid doing header compression, which can take up time. If the packets need to continue on over an IP connection past the edge device, Integral Access can add the header back on at that point, and send it along its way with MPLS labels still intact.

So far, the company's implementation of voice-over-MPLS has been proprietary, but they are currently working to reach interoperability with MPLS routers in the core, and plan to standardize their access interfaces as well, using the MPLS Forum as a foundation.

Also working on specific ways to optimize MPLS for deployment in the access network, though with a rather different spin on the topic, is LiquidLight (Duluth, GA - 678-812-2000), a startup focusing on bandwidth management for Optical Service Providers. As such, LiquidLight actually combines two envelope-pushing applications for MPLS - use in the access or metro area network, and integration of IP and optical technologies. The company calls its implementation “MPLS Lite,” since it attempts to limit the number of labels required and the frequency with which they are exchanged to achieve greater efficiency in a bandwidth-constrained environment. It also takes advantage of features provided within the standard itself, like “fast re-route” to offer a solution better suited to the access environment. LiquidLight's aim, by using MPLS in conjunction with a variety of QoS mechanisms, is to offer a way of better controlling performance, quality, and bandwidth allocation in both the local loop and metro area optical networks. One of the key implications of this type of model is that service providers are moving quickly toward extending optical networks closer to their subscribers, and bringing IP all the way to the customer to enable next-gen applications.

At the provider edge, the market for MPLS-enabled products is growing even more rapidly, and a very diverse group of vendors are getting involved in the standard, where once only IP router makers were concerned. One notable example is Celox Networks (Southborough, MA -508-305-7000), one of the newest companies to enter the subscriber aggregation segment, alongside vendors like Redback and Shasta (now a part of Nortel Networks). Celox is seeking to bring MPLS into a developing part of the network it terms the “services POP,” situated in between the metro area and the core. Its own product, the SCx 192, which the company describes as a service creation platform, can act as a Label Edge Router. The primary function of the SCx is to aggregate high volumes of subscriber traffic, segment and classify it, and apply service logic before forwarding it on at wire speed into the core.

One of the key initial applications Celox enables is VPNs - making its tie-in with MPLS a natural one. An implicit debate arises, however, over whether the LER functionality and VPN provisioning should be located in an IP router or in the type of platform that Celox proposes. While positioning the company as complementary, not competitive, with IP routers, Hugh Kelly, senior v.p. of marketing and business development, notes that one of the primary values MPLS offers is “a scalable means for service providers to accommodate the requirements of different kinds of traffic flows. It's a way of dealing with IP packets more efficiently than doing a full routing lookup on them.”

At the core, IP routers acting as LSRs simply examine the MPLS labels that have been applied by the Celox platform, and forward packets accordingly. This model suggests that IP routers at the edge should remain similarly focused and simplified, leaving QoS and application-related decisions to a more specialized system. Celox is testing its MPLS implementation with those of major core routers, but can also support native ATM QoS, emphasizing that a number of carriers are planning to retain ATM in their networks for some time to come.

While the movement of MPLS in terms of product development, interoperability, and application scenarios is clearly extending outward from the network core, there's still no doubt that the core is where most carriers are looking to begin their MPLS deployments. Both from a technical and a market perspective, MPLS is significantly easier to comprehend and define at the core than it is at the edge. This is where the bulk of the standardization process has been focused over time, it's where the most consensus has been reached on required functions and applications, and it's also where interoperability is closest to becoming a reality.