ARN

MPLS explained

Johna Till Johnson provides a detailed look at Multiprotocol Label Switching

The key thing to remember about MPLS is that it's a technique, not a service -- so it can be used to deliver anything from IP VPNs to Metro Ethernet services, or even to provision optical services. So although carriers build MPLS backbones, the services that users buy may not be called MPLS. They could be called anything from IP VPN to Metro Ethernet -- or whatever the carriers' marketing departments dream up next.

The fundamental concept behind MPLS is that of labeling packets. In a traditional routed IP network, each router makes an independent forwarding decision for each packet based solely on the packet's network-layer header. Thus, every time a packet arrives at a router, the router has to "think through" where to send the packet next.

With MPLS, the first time the packet enters a network, it's assigned to a specific forwarding equivalence class (FEC), indicated by appending a short bit sequence (the label) to the packet. Each router in the network has a table indicating how to handle packets of a specific FEC type, so once the packet has entered the network, routers don't need to perform header analysis. Instead, subsequent routers use the label as an index into a table that provides them with a new FEC for that packet.

This gives the MPLS network the ability to handle packets with particular characteristics (such as coming from particular ports or carrying traffic of particular application types) in a consistent fashion. Packets carrying real-time traffic, such as voice or video, can easily be mapped to low-latency routes across the network -- something that's challenging with conventional routing. The key architectural point with all this is that the labels provide a way to "attach" additional information to each packet -- information above and beyond what the routers previously had.

Layer 2 or Layer 3?

There's been a lot of confusion over the years about whether MPLS is a Layer 2 or Layer 3 service. But MPLS doesn't fit neatly into the OSI seven-layer hierarchy. In fact, one of the key benefits of MPLS is that it separates forwarding mechanisms from the underlying data-link service. MPLS can be used to create forwarding tables for ATM or frame relay switches (using the existing ATM or DLCI header) or for plain old IP routers by appending MPLS tags to IP packets.

The bottom line is that network operators can use MPLS to deliver a wide variety of services. The two most popular implementations of MPLS are layer 3 BGP/MPLS-VPNs (based on RFC 2547) and Layer 2 (or pseudowire) VPNs.

RFC 2547 VPNs have been implemented by most of the major world service providers, including AT&T, Verizon, BT and many others. The fundamental characteristics of a 2547 is that traffic is isolated into MPLS-VPNs as it enters the network.

Interior routers have no knowledge of IP information beyond the label-only base forwarding decisions on the MPLS label. BGP is used by edge routers to exchange knowledge of VPNs, thus enabling service providers to isolate traffic from multiple customers or even the Internet over a shared backbone.

There are several flavors of layer 2 MPLS services, but what they have in common is that a Layer 2 packet (or ATM cell or frame relay frame) is encased in an MPLS header and forwarded through the MPLS core. When it reaches the other side, the packet's labels are removed, and the packet that arrives at the ultimate destination exactly where it entered the MPLS network. Thus, Layer 2 MPLS services effectively extend services such as Ethernet or frame relay across an IP WAN.

Page Break

What are the different types of MPLS?

The version of MPLS that's generally used to encapsulate connection-oriented frame relay and ATM services is called pseudo Wire Edge to Edge Emulation (PWE3). PWE3 defines point-to-point tunnels across the MPLS backbone, and thus works well for circuit-oriented networking protocols. PWE3 can also be used to support connectionless LAN protocols, but it's not the preferred solution.

For connectionless protocols (primarily Ethernet) there's a different specification, called virtual private LAN service (VPLS). VPLS addresses some of the specific challenges with extending Ethernet across the metropolitan area or WAN, most notably scalability and availability. Another emerging spec is the ITU's transport-MPLS (T-MPLS), which is designed to simplify deployment of Ethernet services

It's worth noting that MPLS isn't the only game in town when it comes to Ethernet services, though. Several vendors --including Nortel, Extreme and Siemens-- are promoting an alternative approach called Provider Backbone Transport, or PBT, for metropolitan area Ethernet.

PBT is based on using existing IEEE 802.1 VLAN tags to deliver Ethernet services across a provider network. PBT competes head-to-head with T-MPLS, and the jury's still out on which one will gain the most traction.

Finally, a variant of MPLS called Generalized Multiprotocol Label Switching (GMPLS) gives routers the ability intelligently signal the optical layer, enabling providers to establish, change or tear down optical links in real time. Thus, service providers can provision "optical wavelength" services based on MPLS.

Page Break

Sidebar: Steps to take: assess, RFP, implement

Step 1: Assess your network needs

Document the following:

1. Number of sites and bandwidth to each.

2. Devices and device configurations.

3. Your applications. How many applications do you have? What are they? How often are they used, and by whom?

4. Application characteristics. Describe the network characteristics of your applications. Are they store-and-forward (i.e., latency insensitive)? Or interactive? How "chatty" are they? In typical usage scenarios, how much bandwidth do they consume? How does that vary by time of day/week/month/year?

5. Other networks. Be sure to include applications that may be on other networks -- particularly video and voice). You'll want to document your current and planned voice, video and conferencing use.

6. Future plans. Network capacity requirements may change dramatically when that new ERP application rolls into production in 2009. Be sure to include any upcoming application .

7. Document to the best of your abilities your current availability and service guarantees. You'll need them to craft meaningful SLAs with your providers downstream.

Step 2: The RFP

When developing the request for proposals, there are a few key issues that are specific to MPLS-based services, including:

-- Timing. How far in advance you should start this process depends on the number of sites, the number of geographies and your starting state. But any comprehensive RFP process should be started a minimum of six months before the desired circuit turn-up. Eight months is better. Very early MPLS adopters invested several years in discussions with their carriers, but that's no longer necessary.

-- Service and access types. As noted, there are many different "flavors" of MPLS-based services. From a user perspective, the biggest distinction lies in the access technologies: Are services provided over copper or optical connections? What about wireless options? Is the carrier delivering native Ethernet, IP, or legacy services such as frame relay and ATM? Can remote users be connected in via VPNs? Ask service providers to offer details of each service they propose, including the specs they're based on and the gear they're using.

-- Network-to-network interfaces (NNIs). As much as possible, try to keep your sites on a single carrier's network (with the possible exception of having multiple carriers link to critical sites for redundancy). Ask about your carriers' NNI strategies, because few providers will offer end-to-end SLAs to offnet sites. Ask providers if they have a "short list" of other providers with whom they've established effective NNIs. Have them describe the certification process for adding providers to this list, what service guarantees can be made, and how they're enforced, and how cross-NNI troubleshooting is handled. The more you know, the more effectively you can manage cross-carrier connections.

-- Also ask about (and budget for) ongoing monitoring. Your carrier will assure you that the provider will monitor 'everything you need.' Trust, but verify -- you'll want tools of your own to keep the carrier honest.

-- Assess your backup options -- in many cases, backup for frame networks is provided by the same ISDN network that doubles as a videoconferencing infrastructure. With MPLS, not only is your overall bandwidth increasing, but your ISDN network may be going away. Ask carriers to discuss backup options in detail.

--Make sure you ask for details about quality of service and service-level guarantees. Most providers try to brush you off on these details -- don't let them.

Page Break

Step 3: Implementation

Once you've received responses to your RFP, plan to roll up your sleeves and dig into the details. You'll want to prune down the responses to a "short list" of two to three carriers who can address your requirements, and work with them to craft agreements that meet your technical, financial and operational goals. Be sure to take into consideration the fact that use will change as bandwidth becomes available and that it may affect contract terms and conditions, particularly minimum annual revenue commitments. Eschew mini-MARCs (commitments to purchase particular amounts of particular types of service, such as voice) in favor of an overall combined MARC.

Plan to focus on the following:

-- Mapping your application requirements to the appropriate class of service. The carrier's techs won't necessarily understand that your ERP app is mission-critical and needs real-time performance -- so you'll need to work with them to define and price a network that offers the appropriate services to your current and planned applications.

-- Contractual support for your go-forward strategy. If you're planning to migrate to VoIP , you'll want to be sure your contract doesn't penalize you for doing so. Specifically, if you need to increase bandwidth to accommodate voice and video traffic, make sure your access circuits can handle the load, and that your contract doesn't include clauses that make increases prohibitively expensive.

-- Capacity planning and expansion. Nail down the terms and conditions under which the carriers will expand your network, either by adding new sites or by growing the bandwidth to existing sites. What will it cost? How long will it take? And how much advance notice must you provide?

Do as much of this "predesign" work before you sign the contract, and make sure you understand exactly what you're committing to.

If you've done all of the above, the actual service turn-up process should be fairly straightforward, if not entirely painless. Keep in mind a few operational strategies that will help minimize the angst:

If you're planning to converge voice and data via VoIP, at the same time you're rolling out MPLS, tackle each project separately. I wouldn't say you need to actively hold off on VoIP while launching your MPLS network, but make sure to devote enough resources to both.

Your carrier may urge you to upgrade equipment, particularly CPE and branch-office WAN routers. If possible, take them up on it. The time and energy consumed by reconfiguring and upgrading older WAN gear is generally much greater than you'd think -- and technology has advanced fairly significantly in the past two to three years, particularly for branch-office equipment.

Finally, think seriously about how your MPLS migration will affect the need for tech talent. As carriers assume responsibility for many of the architecture, configuration and management functions, enterprises are finding they can get away with fewer hard-core techies. The need doesn't go away entirely -- you've always got to have someone who understands routing protocols -- but you'll need five such people, not 20.

That doesn't necessarily mean massive reductions-in-force, because companies are increasingly forming groups that focus data centers, which have unique requirements for bandwidth and availability (not to mention server, storage and facilities). And branch offices, which are growing at an average of 9 percent year over year, pose special challenges, particularly when it comes to handling security , support and service.