LDP or RSVP-TE? Why not both?
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
Amazing article.. Very well written. Can’t thank enough
Hi Robin,
Thank you very much for this article
clear and easy to read
just enlarge the pics
Danny
Hi,
In LDP over RSVP scenario.There is one requirement that if RSVP tunnels are not up than LDP sessions should be established on IGP HOPS.
Please help me to understand this.
Regards,
Aman
Thanks , really very informative .
However , ldp is used to create lsps between l2 an l3 SRs .
In this case the LDPoRSVP works.
Thank you so much so in conclusion CR-LDP is better than RSVP-TE
great info. my problem, we using rsvp te, LSR = huawei NE40E n NE80E. when the link more then 3, we will facing problem if common issue such as fiber cut and bring down more then 3 link. then after it up again. the link will stand at the secondary and need to reset manually per tunnel.
thanks to whoever wrote this