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

Another day, another pile of great information.  I am still trying to sort through it all.  Today’s topics were MPLS-TP, Multicast, Mobility, and Experience.

The MPLS-TP section was kicked off by Loa Andersson from Ericsson.  He gave a standards update and discussed how the MPLS-TP specifications are actually being worked through quite quickly. He estimated that if there are no drastic changes, the specs should be completed mid-2011.

Luyuan Fang from cisco gave us some more justification for why we need MPLS-TP.   She is my new idol…she’s a great presenter, very knowledgeable, and she’s a nice person  – I wish she was giving all the sessions.  Some of the key points she made:  the reason for MPLS-TP is that is works with existing MPLS which leverages expertise and technologies; it provides a packet-based transport with features similar to existing circuit-based transport.  She also described some of the applications where MPLS-TP can be used. 

The next set of sessions were concerning multicast, but unfortunately they were more focused on the path computations used for multicast.  It has been a while since I have felt this dumb, but the terms and acronyms the presenters were tossing around went right over my head most of the time.  I am sure someone cares about how the best path and backup paths are computed, but it’s not me.  Just give me the output and show me what the network does with it.  Sorry…

The afternoon started with the extremely hot topic of mobility.  The speakers took different approaches to their sessions which made it more interesting.  One of the most interesting topics that I thought would be the biggest bore was the discussion on timing requirements for the mobile base stations.  Peter Roberts from Alcatel-Lucent did a great job with this session.  I never realized just how big a challenge this is, because not only do we need bit synchronization, but in the wireless world you need phase synchronization and time-of-day.  He explained the challenges that are being overcome with timing over packet – one of the biggest is having symmetric delays. 

Other discussions centered around Ethernet vs. MPLS-TP in the backhaul.   Pasula Reddy from Fujitsu spoke about the different motivations of the mobile provider and the backhaul provider (assuming they are not the same organization.  Esmael Dinan from Clearwire discussed their implementation for backhaul and some of the other options.  They are using microwave for their LTE implementation and straight Ethernet backhaul to an MPLS core.  The other option of course is running MPLS-TP across the backhaul network.  He said that because their microwave equipment supported native Ethernet, this was the most cost effective choice for their implementation.

The second part of the afternoon featured speakers from the providers who have real-world experience testing and implementing this.  Deutsche Telecom and Reliance Globalcom explained their strategies and implementations, then cisco gave a presentation on VPN services over DOCSIS.

The wrap up for the day was a vendor panel moderated by Dave McDysan from Verizon.  Representatives from Brocade, Cisco, Juniper, Ericsson, ALU, and IPInfusion all participated and answered questions on technology trends, standards compliance, and interoperability issues.

Another great day.  One more day then I will have a whole year to digest this stuff until 2010.

While this is day 2 of the conference, it is really the start of the general sessions so the kickoff was this morning.  The themes today were MPLS-TP, Seemless and Scalable MPLS, and High Availablity MPLS  with a little bit of cloud computing and SAN services thrown into the mix.  

 The keynote speech was given by Raymond Zhang from BT on the topic of cloud computing.  He asked the question:  “what if 90% of customer applications were in the network?”  How would we handle it?  He also made a comment that made me chuckle a little.  He said that in the networks we build the infrastructure to treat faults as exceptions, but software is written to deal with faults as the norm. HA!  I’m guessing he must be a windows user.

Next up was Yakov Rekhter from Juniper to discuss Local protection for LSP tail end node failure.  Yakov was informative as usual, and had excellent answers to the problem of “what happens when the end node (PE) fails?”  We have all kinds of mechanisms to deal with failures in the middle of the network, but that last node is the bugger that will kill the service if it dies.  One key point he made was that High Availability (HA) can NOT depend on routing convergence.  It must be independent.  The only way for HA MPLS networks is for fast recovery.   

He re-introduced the concept of LSP hierarchy (which I heard about at this conference a couple years ago) and stated that connectivity recovery options must support this concept of hierarchy.  So if the PE fails, the next hop P is the Point of Local Repair (PLR), and it must redirect traffic to a different PE.  The recovery PE must know what labels the original PE assigned, so it must have a different LFIB that is a mirror image of the primary.  He called this a “context-specific” LFIB.

Kireeti Kompella from Juniper was next and gave his talk on scaling MPLS to 100,000 nodes.  Many of his slides were the same as yesterday discussing the connectivity blueprint and the new terminology of Access Nodes, Service Nodes, etc.  His 2 talks were definitely related.  If MPLS pushes further out into the access network, then it has to scale.  His examples were MPLS to the DSLAM and MPLS to the cell site.  Think about how many cell sites there are and it automatically hits you that we have a scalability concern.

Nicolai Leymann from Deutsche Telecom was the service provider sanity check on this whole concept of scalability and seemless MPLS.  They are doing MPLS in the access and pseudowires from AN to the SN.  He said that the key is to separate services from transport, and in doing so you can move the services anywhere they need to be in the network.

Next was George Swallow from cisco on MPLS-TP and blurring the boundaries.  One comment he made was MPLS-TP not a radical new change, but a significant game changer.  Another point he made was if pseudowire service is end-to-end, then maybe we want MPLS-TP end-to-end as well, and if so, where is the boundary between packet and transport in this picture?  Very blurry.

After lunch was the Ethernet theme.  Andy Malis from Verizon kicked things off by discussing Verizon’s requirements for carrier Ethernet.  I had a chance to talk with him before his presentation and he made it clear to me that Verizon is doing PBB and MPLS-TP.  PBB-TE (PBT) is not a strategy for Verizon.  He went through the importance of the MEF standards as a common way to define services.  He also addressed the scalability comparison between H-VPLS and PBB+VPLS – guess who wins?

Luca Martini from cisco discussed his 10 years of pseudowires – where they came from and where they are going.  He commented on the fact that the standards bodies take so long to get things standardized, that his draft went through 153 revisions before it became RFC 4447.  RFC’s for multi-segment pseudowires are just about to come out, yet vendors have been supporting these pre-standard features for some time now.  The market does not wait for standards.

Other discussions today include Fast Restoration for VPLS, SAN services over MPLS, New Internet Architecture, Path Computation, and to wrap up the day Monique Morrow from cisco moderated a 10-person panel on emerging technologies.

Another very full day – hope I have some brain capacity left for tomorrow’s sessions.

Hello fellow techies.  If you are hungering for a rich meal of multicast VPNs with some MPLS-TP on the side, and MPLS in the Access for dessert – you have come to the right place.  These were the tutorial sessions today as the MPLS 2009 conference in Washington DC, and they were quite filling. In fact, I’m stuffed.

Let’s start with MPLS-TP.  Matthew Bocci and Lubo Tancevski from Alcatel-Lucent shared the near-impossible task of covering this topic in 1.5 hours.  They went through their slides extremely fast, such that even experts in this field would have missed quite a bit of what was said.  What I did catch was quite informative.  Much of the discussion was around defining what MPLS-TP is, or is not.  There were a few ideas floating around:  the presenters said that MPLS-TP is a subset of MPLS that is geared toward transport and not services.  Kireeti Kompella from Juniper brought up the point afterward that MPLS started as a transport mechanism, then we spent the last 10 years building services for it, and now we are stripping it back down to do just transport.  I must say he makes an excellent point, but everything in this industry comes full circle.  This is no different.

The presenters also spent a bit of time on OAM functions for MPLS-TP.  There are 3 ways to do OAM for MPLS-TP:

            Hop-by-hop through the control plane

            Out-of-band where replies come through a different path

            In-band – creating an associated channel

One of the requirements for MPLS-TP is that it be able to operate without a control plane.  Basically that means static provisioning through an NMS – the way typical SONet and OTN networks are provisioned today.   If it does operate with a control plane, it will be GMPLS.

Other areas of discussion include resiliency and protection using Protection Switching Coordination (PSC) protocol; use cases including Business VPN services, Carrier’s carrier, and mobile backhaul; and what’s going on with the standards.

All in all, an excellent presentation, I just wish we had 3 hours to cover it.

Up next was the equally speedy Multicast VPN technologies and Real World Deployments from Azhar Sayeed from cisco, and Maria Napierala from at&t.  They offered some great information on how multicast should work in MPLS to support MVPN, but much of the discussion was about using PIM vs. BGP in the MPLS network.  These guys were definitely the pro-PIM camp and every other slide was justification why PIM is better than BGP.  Of course I knew this would knot Juniper’s panties in a bunch, and sure enough the first person to the microphone after the presentation was Kireeti, and the second was Ina Minei.  Both said they felt the presentation was biased, and Maria challenged them to tell her where her findings were in error. 

The discussion also included the signaling component for P2MP and MP2MP LSP’s.  Basically RSVP-TE can only set up P2MP and if you want to do MP2MP, you must set up a full mesh of P2MP.  All the traffic engineering benefits still apply, so use this if you want hard QoS guarantees and FRR.  MLDP is a much simpler solution for setting up P2MP and MP2MP. 

Maria really hit the nail in the coffin with slides titled:  If PIM already exists and works, why use BGP.  Much of her presentation was regarding real-world architectures from at&t’s network and customers which shows deployments using GRE tunnels.  Her slides had a lot of great animations – too bad they don’t show up in the pdf version distributed by the conference. 

Another job well done, and again I wish the presenters had 3 hours to cover this topic. 

Last but not least was the MPLS in the Access topic by Kireeti from Juniper.  Apparently he had discussed this topic at last year’s conference, but felt that enough had changed and that it was important enough to revisit the topic this year. 

I enjoy Kireeti’s style of presentation and he is always a wealth of information.  His presentation introduced a whole new slew of terms (like we all need more acronyms to understand) and his main point is that the network should not determine which services can be offered, but the network should support any services that are offered.  So if you decouple the network from the services, you can place the service nodes (SN) anywhere you want.  You can centralize them, or you can push them out closer to the customer.  The Access Node (AN) is the first or last node in the provider’s network to handle packets from the customer at layer 2 and up.  The Transport Node (TN) just transports packets between AN and SN and SN and SN.  One other type of node was defined – the Service Helper Node (SH).  This node helps provide the services without ever touching the customer packets.  Examples of this might be a SIP server or Authentication device.

Other points in his presentation went through the challenges of having different network regions using different technologies, hence the argument for having MPLS end-to-end.  Some of the features required to do this are multi-segment pseudo-wires (MS-PW) and LSP stitching using labeled BGP.

Too bad Kireeti’s topic was at the end of a very full day. He too could have used 3 hours, but by this time my brain was full.

Generally speaking it was a great day, lots of rich nourishment for the MPLS-mind.  Stay tuned for my report on the sessions tomorrow which include:

MPLS Scaling

Fast Service Restoration for VPLS

SAN services over MPLS

Future Vision on Seamless Interconnection

Today was the start of the MPLS2009 conference by Isocore.  It could have been a great day, but it wasn’t.  The tutorials were actually quite good.  The technical presentations were well done and the presenters were actually good presenters.  But the management of the conference was sorely lacking.  

When you pay $1100 to attend this conference, there are some basic amenities that one would expect.

1.  Power

When you check in for the conference, they give you a package that includes a CD with all the presentations.  Of course you can have them as a reference after the conference, but some of us like to go through the slides on the laptop as the presenter is going through them on the big screen.  Some of us also like to type in notes of what the presenter is saying.  All of these things require you to have a laptop that has POWER.  In past conferences they did run power to every table, and the conference staff claim it will be there tomorrow, but why wasn’t it there today? 

2.  Internet Access

THIS IS A NETWORKING CONFERENCE!!!  How can you not have internet access in the meeting rooms???  If it weren’t so sad, it would be funny.  The aforementioned CD typically has out-of-date material because the presenters make some changes at the last minute.  So when you boot up the CD, there is an option to download the latest presentations from the internet.  KIND OF HARD TO DO WITHOUT ACCESS TO THE INTERNET!!!  Ya think?  Previous conferences had an attendee user name and password so that they could have access, but not this year.  I was told that no one was available to coordinate it this year.  WHAT?  I’m sorry, Internet access is as needful to this audience as food and water (or caffeine and sugar – see below).  Sure, those staying in the conference hotel have access through their room, but for those of us who still paid $1100 and are not staying at that hotel – what about us?

3.  Decaf coffee

OK, I am sure I’m in the minority here, after all this is a conference for engineering geeks who normally live on caffeine and sugar.  But for many people, a coffee break at 3:30pm is too late for caffeine.  So I waited in line at the coffee stand only to arrive at the pots and see there was no decaf.  A hotel waiter was standing behind the table and I asked him “where’s the decaf?”  I was told that of course the hotel has decaf, but our conference didn’t pay for it.  WHAT?  Too cheap to spring for decaf?  What’s up with that?

I made a list of my concerns and stopped by the desk to ask who I could discuss these items with.  One gentleman behind the table said I could talk to him….I bet he is regretting that decision.  Anyway, I voiced my concerns and was told that there would be power the next day, but the internet problem would not be rectified.  I don’t recall what he said about the decaf – I was too busy fuming over the internet thing.

There were a few good things today:  the presentations as I mentioned, and the bottled water that was available for attendees in addition to the nasty tap water on each table.  I will discuss the technical sessions in a later post.  First, I had to rant and get this off my chest.  Thanks for listening!!

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

“Turned theory into tangible reality”

“The hands-on experience, the relaxed atmosphere, the TRAINER!!! – Robin Armstrong”

“Instructor’s method of teaching – highly effective!”

“I am satisfied with the way the class was presented. The instructor is very knowledgeable in the subject matter.”

“The instructor was very knowledgeable and has actually worked with the technology and applied it in networks. It is very apparent she keeps up with the technology. Very good class.”