But this success doesn’t mean that MPLS is finished evolving as a technology, as the Internet Engineering Task Force (IETF) has been working on a number of different improvements to MPLS that will allow it to be applied to transport architecture,  mobile backhaul and IPv6.

Perhaps the most important MPLS evolution will be MPLS Transport Profile (MPLS-TP), an MPLS expansion that is tailored for optical and transport networks. Andrew Malis, a member of the IETF’s Internet Architecture Board and a principal member of Verizon Communications’ technical staff, says that MPLS-TP is basically the same as MPLS but with key new features.

“MPLS-TP can take advantage of features such as Quality of Service and fast reroute and put that into optical and transport networks that have typically been based on TDM only,” he says. “It brings the benefit of packet switching to optical and transport networks.”  Additionally, MPLS-TP can run over any physical layer, from Ethernet to SONET/SDH to OTN.

Mike Capuano, the director of service provider marketing at Cisco, says that some transport service operators have been reluctant to use MPLS over their networks because standard MPLS doesn’t give them the level of control they feel they need. With MPLS TP, Capuano says transport operators will have the Operations, Administration and Maintenance (OAM) capabilities necessary for properly managing their network.

“Packet technologies have historically not had the same level of instrumentation that transport technologies like SONET/SDH,” he says. “So there’s been a lot of attention paid to giving Ethernet and MPLS those same features. In certain circumstances transport operators are more comfortable provisioning point-to-point links rather than using MPLS. With MPLS-TP they’ll be able to manually provision MPLS tunnels.”

MPLS over IPv6, LTE coming further down the line

While MPLS-TP will be the most immediate version of the technology to hit the market, engineers have also been hammering out ways to integrate MPLS with IPv6 networks and with 4G wireless Long Term Evolution networks. On the IPv6 side of things, Malis says that the major technological work is finished and that providers “can use MPLS to carry both IPv4 and IPv6 traffic.” But even though MPLS is now compatible with IPv6, it’s unlikely that it will become widely used in the near future since IPv6 traffic still only accounts for less than 1% of all Web traffic.

“IPv6 migration is obviously a big issue, but we don’t think it impacts MPLS as much,” Capuano says. “It’s more about service providers moving quickly to get to IPv6 before we run out of IPv4 addresses.”

Of more immediate interest is the potential to integrate MPLS with LTE technology and use it for mobile backhaul. InfoNetics analyst Michael Howard says that because LTE is an IP-based mobile data technology that it’s a perfect fit for MPLS. Malis echoes Howard’s sentiments and thinks that MPLS is an ideal technology to use for 4G mobile backhaul.

“3G networks are mostly based on ATM and 4G networks are based on Ethernet and IP,” he says. “LTE is focusing on IP over Ethernet as its standard backhaul technology and MPLS works quite well there.”

Malis says that designing an MPLS mobile backhaul system is particularly tricky because engineers have to have both clocking requirements and handoffs between stations. These features are key for a technology such as LTE, which Malis notes will eventually be relied upon not just for data but for voice and video streaming as well. But once MPLS can be successfully implemented on and LTE network, Malis thinks that it will be a major asset to LTE service quality, particularly when it comes to giving priority to voice and video packets.

“One of the real strengths of MPLS is its ability to do traffic engineering,” he says. “It’s going to be quite a while where carriers are in the process of transitioning to LTE, and the nice thing about MPLS is that it will give them one common infrastructure that they’ll get to use over and over.”

With as much hype as there has been recently around MPLS-TP, you would think this is some wild new thing.  While I was at the MPLS2009 conference, I would have to say that at least 40% of the speaking sessions were dedicated to this topic.  If you’re a “net-head”, you might be wondering – what is so special about this technology?  If you are a “circuit-head”, you might see something new and innovative.  This article is the first in a series on MPLS-TP which will focus on what it is, why it might be useful.  Upcoming articles will focus on OAM aspects and how it works.

Why MPLS-TP?

One of the main driving forces behind MPLS-TP is the bandwidth growth from new applications and services like IPTV, Mobile data, and triple play.  As providers struggle to beef up their bandwidth in the access and aggregation networks to support these applications, they are also trying to optimize and converge their networks to provide flexible data rates and lower cost through statistical multiplexing.

“Multi-Protocol Label Switching (MPLS) is a maturing packet technology and it is already playing an important role in transport networks and services.  However, not all of MPLS’s capabilities and mechanisms are needed and/or consistent with transport network operations.  There are also transport technology characteristics that are not currently reflected in MPLS.  Therefore, there is the need to define an MPLS Transport Profile (MPLS-TP) that supports the capabilities and functionalities needed for packet-transport network services and operations through combining the packet experience of MPLS with the operational experience and practices of existing transport networks.”  (RFC 5654)

If you look at a typical transport network such as SONET or OTN, most if not all connections are manually provisioned via a centralized management system.  But recognizing the inflexibility of SONET, the focus is now on providing a packet-based transport mechanism over the optical network while retaining all the benefits of the circuit-based network. 

The discussion of the circuit vs. packet network has been going on for decades.  Circuits are great when you have applications that are point-to-point with a fixed bandwidth and strict delay/jitter requirements.  I don’t know the latest numbers, but the vast majority of traffic these days is bursty, time insensitive traffic which is best suited for a packet technology that can provide bandwidth-on-demand.  So the next question is:  what kind of packets?

Some say Ethernet is the way to go, since it is prolific in the customer, access, and aggregation networks.  The problem with Ethernet is that it doesn’t operate in a connection-oriented way.  There is work being done to make Ethernet connection-oriented and PBB-TE is the primary technology in this area.  When Nortel was still in existence, this approach gained some traction amongst service providers, but now the momentum behind this approach seems to have slowed dramatically.

The other approach is to extend MPLS out from the packet core into the Aggregation and Access networks.  Since MPLS is already in the core, there is no need to change packet formats or technologies when going from the access/aggregation networks.  However, the transport functions need to be addressed.  MPLS-TP addresses the need for high-bandwidth packet services, along with in-band OAM, NMS-based provisioning, deterministic path protection with fast recovery time, and best of all it is standard based on joint work between ITU-T and IETF.

What is MPLS-TP?

MPLS Transport Profile is a subset of traditional MPLS capabilities that is geared toward providing typical transport-type functions such as:

Connection-oriented technology with traffic-engineering capabilities that allow deterministic control of the use of network resources. (nothing new here)

Unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths.  (something new here)

Physical separation of the control and management planes from the data plane.  That is, it must be possible to operate the control and management planes out-of-band. (definitely something new here)

Static provisioning of transport paths via the management plane. (not so new in concept, but a different way to implement)

The basic idea is to “dumb down” MPLS so that it doesn’t have to use a control plane and is not based on IP, and so it looks/behaves a lot more like a TDM network without the limitations of TDM.  But we need to add a few things in the way of OAM, resilience, and provisioning.

If you look at RFC 5654, it lists 115 requirements to date in various categories such as:

General/Layering (1-35) 

Data Plane (36-46)

Control Plane (47-55)

Recovery (56-109)

QoS  (110-115)

It is evident that the bulk of the RFC is spent in identifying recovery requirements for the data plane and control plane.  It identifies 1+1, 1:n protection in the dataplane for unidirectional and bidirectional traffic, and for P2P and P2MP LSPs.  There are a few requirements for recovery of a control plane (which is optional), and a bunch of requirements for recovery based on topology.  These types of features will enable MPLS-TP to behave more like a circuit network.

So in a nutshell, MPLS-TP looks alot like regular MPLS in the data plane:  same 32 bit header, same 20 bit label.  The differences are mainly in the control plane, management, and OAM. 

Conclusion

With the transport evolution migrating toward packets, MPLS-TP is in a key position to enable bandwidth growth and optimization while meeting the strict requirements of the traditional transport network in terms of resiliency, management, provisioning and quality of service.  All this while providing common functionality with the core network.  This one looks like a winner!  Stay tuned for the next article covering MPLS-TP OAM.

Copyright 2009 Exzaktec – All Rights Reserved

Introduction

Traditional arguments in the MPLS world include “which signaling protocol to use – LDP or RSVP-TE?”  The traditional response is “Use LDP when you want simplicity, use RSVP-TE when you want bandwidth guarantees and 50ms reroute around failure”.  Fair enough, but aren’t there any other parameters we should incorporate when making the decision for one or both of these protocols in our network?  The article examines the implementations where a provider might use both side-by-side and LDPoRSVP-TE.

Quick review of LDP and RSVP-TE

Looking at LDP – this is the simplest of the signaling protocols to use for MPLS.  Just by turning on LDP on the node/interface, labels automatically get advertised for each route in the routing table to all LDP peers.  It couldn’t be any more simple – instant LSPs.  That’s the good news.  A full mesh of LSPs is automatically created amongst all the interconnected nodes running LDP.

The not-so-good news is that you have LSPs to everything in the routing table – whether you need them or not.  We typically would never use an LSP to an interface address – but since interface addresses are in the routing table, labels are assigned and distributed for those addresses.  LDP FEC filtering (or conditional label advertising) can address this issue, but usually requires some extra configuration.

The other thing about LDP is the limited QoS capability.  We are able to use the EXP bits to incorporate “relative QoS” using LDP.  Relative QoS basically means prioritization and queue scheduling.  It is impossible to enforce guarantees with relative QoS, but with enough resources in the network this approach works well.

RSVP-TE creates an LSP when the parameters for the LSP are manually configured.  If the parameters can be met based on the information in the traffic engineering database, RSVP-TE signaling is used to establish the connection (LSP).  These parameters include destination and may include options such as:  bandwidth requirements, link attribute requirements, explicit route requirements, backup and fast re-route etc.

The good news is that the LSP setup using RSVP-TE can guarantee the bandwidth requested.  This is “hard QoS.”   (Keep in mind that this is at the LSP-level, so care must be taken into managing the traffic and services that use the LSP.)  Another piece of good news is that should there be a failure in the network, the LSP that is configured for Fast Reroute (FRR) can bypass the failure in 50ms or less.  Fast re-route is the packet-world’s version of SONet protection.  The idea is to try to make the packet layers as reliable as the circuit/physical layers.

The not-so-good news with RSVP-TE is that each LSP must be manually provisioned.  Think about a network with 20 PE’s that need to be connected with a full mesh of LSPs.  This requires the configuration of 19 LSP’s on each of the 20 nodes – otherwise known as the n-squared problem.  And what happens when one node is removed or added to the network?  This requires configuration to be done on all the nodes.  Remember LDP automatically creates this full mesh just by turning on the protocol.

Using both “side-by-side”

There certainly is no problem with using both in the network.  Providers may use LDP LSPs primarily for best-effort traffic and for customers who want a “bare bones”, inexpensive type of service.  They might also use RSVP-TE LSPs for those customers who are willing to pay extra for bandwidth guarantees and ultra-reliability.  From a configuration perspective, most vendors support both protocols simultaneously, so it’s really just a matter of implementation.

The question becomes where do you use each protocol?  If you turn on both everywhere, there may be a few difficulties:

            Duplicate full mesh of LSPs – lots of signaling overhead

            Identifying which traffic is using which LSPs – or having to statically map traffic flows to LSPs

            Reconvergence of LDP LSPs in the event of link/node failure

Another option is to turn on LDP everywhere, and build RSVP-TE tunnels as needed for those customers willing to pay a premium.  Then the question becomes does each premium customer get their own set of LSP’s or are they shared between customers?  If each customer gets dedicated TE LSPs, then the provider may have to run several LSPs between the same 2 endpoints, requiring much more administration and management.  Again, it’s a matter of implementation, so each service provider must decide how to roll-out its offerings. 

There is another option in using both LDP and RSVP-TE, and that is to use each in a specific part of the network.  The worry here is that we need end-to-end LSPs, and if LDP is turned on in only pieces of the network, LSPs will only work to those endpoints where we have a continuous labeling function.  If the LSP is broken, any services carried over that LSP will fail to reach the destination.

LDP over RSVP-TE

While this name  is somewhat misleading,  it appears to be the industry “defacto” standard that is used by vendors/providers describing this feature,  so we will have to go with it.  Technically, LDP does not run over RSVP-TE, but rather an LDP signaled LSP runs through a TE tunnel that was set-up with RSVP-TE.  So what we are talking about is the data-plane function, but this name “LDP over RSVP-TE” implies control-plane. 

The opportunity here is to use both protocols to set up LSPs in a “nested” implementation.  In this case LDP can be turned on at the edge, RSVP-TE across the core, and the RSVP-TE LSP acts as the “link” connecting two LDP peers together.  (The TE tunnel may need some special configuration parameters to support LDP signaling). These peers may not be directly physically connected as is the case with standard LDP, but now can be logically directly connected via this tunnel LSP.

The benefits of this approach are that the number of LSPs in the core is minimized and forwarding tables are kept small.  The number of LDP peers is minimized because the core nodes are not running LDP.  Another benefit is we can take advantage of FRR in the core and avoid the long convergence times of IP/LDP to keep traffic flowing.  This approach will require some engineering of course to make sure the TE LSPs are everywhere they need to be, but what good network doesn’t require some engineering?

Another opportunity for this type of implementation may seem counter-intuitive at first, but ultimately makes Moves/Adds/Changes in the network relatively pain-free.  The idea is to build point-to-point TE tunnels to directly attached neighbors.  These TE tunnels only go to the next hop, not end to end.  Then when LDP is run over those tunnels, the sessions are built to the directly connected neighbor.  Since the sessions are going through the tunnel, the LDP session is targeted even though the neighbor is directly physically connected.  In this case we are back to the situation where we are running LDP and RSVP everywhere, instead of being side-by-side, it’s stacked.

 Now when there is a change in the network – let’s say we add a node, the directly-connected neighbors of the new node will have RSVP and LDP sessions.  The RSVP LSP’s will be only to the next hop, and LDP will take care of advertising labels for this new node’s addresses to al the other nodes in the network.

We can also take advantage of the FRR protection we get with RSVP-TE so that if a failure occurs, the TE LSP is rerouted without dropping the LDP session.

In this implementation the data-plane becomes a bit tricky.  VPN packets will have a 3 label stack, but at each hop through the network, the nodes will have to perform a POP of the RSVP label, SWAP of the LDP label, and PUSH of a new RSVP label.

Conclusion

Vendors and Service Providers can get very creative when implementing MPLS signaling protocols.  Implementation can be one or the other, both side-by-side, or both in a hierarchy.  Not all vendors support the LDP over RSVP-TE feature, but amongst those that do, their customers have some sizeable implementations across the globe.  The primary benefit to this feature appears to be the manageability of moves/adds/changes while minimizing the size of the forwarding tables across the core.  How widespread the implementations might be remains to be seen.

Copyright – 2009 ExZAKtec – All rights reserved