MPLS Based SPF & TE Solutions: LDP, RSVP-TE & Segment Routing(SR)

By cbarth posted 01-24-2019 05:10

Recommend

Introduction

There is often a desire to provide shortest-path MPLS tunnels and Traffic-Engineered or explicit-path MPLS tunnels in a network for differentiated services. Traditionally, this has been accomplished by deploying both Label Distribution Protocol (LDP) and Resource Reservation Protocol with Traffic Engineering Extensions (RSVP-TE) side-by-side and mapping “services” to protocol specific paths explicitly.

Deploying two protocols for MPLS path signalling can be quite complex for a number of reasons.

Each protocol has different operational behaviors leading to increased operational knowledge and potentially increased network requirements, behaviors, and software requirements.
Mapping services, implicitly or explicitly, to two different protocol next-hops can lead to increased protocol and configuration complexity and thus a higher probability of human errors.

The perceived complexity of the classical deployment of both LDP and RSVP-TE for shortest and explicit path LSPs has lead to an assumption that a common protocol, such as Segment Routing(SR) extensions to network IGPs, leads to a “simpler” solution.

In the following sections we will look at how LDP shortest path and RSVP-TE explicit path LSPs compare with the new Segment Routing based solutions. The topology in Figure 1 will be used to look at each solution by considering a simple LSP between R1 and R6. Furthermore, since SR is quite label intensive, a detailed look at the MPLS data-plane will be provided for each example. We will end with a quick look at how to load-balance across shortest path and explicit path LSPs using a common multi-path policy.

Figure 1: Example SPF & Explicit Tunnels from R1 to R6

Shortest Path Forwarding

When explicit service constraints are not needed for a given service, the shortest path, as computed by the network IGP, is more than sufficient to deliver services.

LDP for Shortest Path Forwarding

LDP doesn’t require any upfront label allocation planning to deploy shortest-path LSPs since LDP dynamically allocates labels during FEC advertisement from a per node label space. After enabling LDP, LDP LSPs are dynamically created between all PE routers, eliminating the need to configure each LSP manually on each router. Figure 2, below, shows the LDP LSP path set-up and label allocations.

Figure 2: LDP signaling & labels allocation for a SPF tunnel

The following configuration example illustrates the required configuration for the example.

Example R1 configuration

protocols {

ldp {

interface all;

...

isis {

interface all;

...

Verification of a shortest path route to R6

regress@R1> show route 1.1.1.6 table inet.3

inet.3: 6 destinations, 12 routes (6 active, 0 holddown, 0 hidden)

@ = Routing Use Only, # = Forwarding Use Only

+ = Active Route, - = Last Active, * = Both

1.1.1.6/32 *[LDP/9] 00:13:14, metric 1

> to 10.1.12.2 via ge-0/0/1.0, Push 87

The figure above illustrates a single LDP path but if there are multiple Equal Cost Paths (ECMPs) between the ingress and egress, LDP will load-balance using all the ECMPs, akin to native IP. This is depicted in figure 3, below, with the pair of links between R2 and R5.

Figure 3: ECMP with LDP

SR for Shortest Path Forwarding

Segment Routing requires a bit of upfront planning because it requires a globally unique label space for SID allocation. Therefore it’s a good idea to create a detailed SID allocation plan in advance that includes sufficient spare labels/SIDs to accommodate growth. As such, in JUNOS, SR IGP extensions are not enabled by default.

SR-capable routers advertises the SIDs throughout the IGP domain using normal IGP flooding and synchronization procedures. If explicit routing is not needed for a given service, forwarding within a SR domain may leverage the globally unique Prefix or Node Segment ID for the protocol next-hop within the domain. The Node SID is a special case of a prefix SID in that it represents the SR Node uniquely and not one of it’s interfaces. The path of the LSP will be the shortest path, as computed by the IGP, to reach each SR node in the domain. The label stack will be encoded as a single label derived from the protocol next-hop Node SID and downstream neighbour SRGB. This is depicted in the figure below. Note that SRGB and SIDs are shown for all the nodes in the diagram but only the Node SID for R6 is considered.

Figure 4: SR SPF tunnels using Node SIDs

In JUNOS, simply enabling Segment Routing extensions and creating a SRGB and node-index results in L-ISIS/OSPF routes to all protocol next-hops thus making the deployment of SR quite easy once the up front planning is done. The figure above illustrates a single SR path but if there are multiple Equal Cost Paths (ECMPs) between the ingress and egress, SR will load-balance using all the ECMPs, akin to a native IP or LDP based network. This is depicted in figure 4, below, with the pair of links between R2 and R5.

Figure 5: SR based SPF ECMP

Example R1 configuration

Defining the SRGB and node SID index

protocols {

isis {

source-packet-routing {

srgb start-label 100 index-range 100;

node-segment {

ipv4-index 1;

}

interface all;

...

Verification of a shortest-path route to R6

regress@R1# run show route 1.1.1.6 table inet.3

inet.3: 7 destinations, 13 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

1.1.1.6/32 *[L-ISIS/14] 13:46:35, metric 30

> to 10.1.12.2 via ge-0/0/1.0, Push 106

Notable Differences

Before moving onto the explicit-routing/Traffic-Engineering section let’s compare and contrast LDP and SR for creating shortest-path LSPs using a few notable considerations as depicted in Table 1.

Solution

Planning

Configuration

Protocols

Labels

ECMP

LDP

ISIS & LDP

Yes

Segment Routing

Label space allocations

(SRGB range, PrefixSID values, ...)

ISIS SRGB & Node-SID index

ISIS with SR extensions

Yes

Table 1: RSVP and SR SPF Comparison

Another notable difference, though not included in the example above, is a lack of “Ordered Control” of label distribution for SR. LDP allocates label for given prefix in order from egress to ingress, hop-by-hop. This allows the ingress node to ensure the LSP is continuous from ingress to egress. In the case of SR, label distribution is independently controlled by each node due to the flooding procedures of the IGPs. As an example, if the ingress node, R1, learns the SID for R6 and SRGB from R2, it will assume it can instantiate a LSP for R6. However, if a router on the shortest path, e.g. R3, is not SR enabled, or has a SRGB range too small, the LSP it will terminate on R2, and R3 will be presented with the LSPs payload prematurely. To mitigate such a scenario, each ingress SR node needs to continuously check the SR data-plane via OAM protocols. Although possible, this introduces its own challenges.

Explicit Routing/Traffic-Engineering

Explicit routing may be desired to optimize network resources or provide very strict service guarantees. It is therefore desired to be able to define a strict path across a network for one or more LSPs. Both RSVP-TE and SR provide a means to explicitly define strict paths (strict hops, loose hops and/or abstract/anycast hops) across a network.

RSVP for Traffic Engineering

Network operators request, typically through configuration, LSPs that meet specific constraints. For example, a network operator could request an LSP that originates at Node R1, terminates at Node R6, reserves 100 megabits per second, and traverses blue interfaces only. A path computation module, located on a central controller - such as the Path Computation Element (PCE) - or on the ingress router, computes a path that satisfies all of the constraints. Figure 5, below, illustrates the resulting RSVP path set-up and reserve messaging to set-up the LSP and the resulting MPLS forwarding-table label operations. It’s worth noting that RSVP-TE could be used to establish SPF LSP as well. In such case an a SPF LSP and a TE-LSP use the exact same procedures to set-up a LSP and have the same data-plane operations.

Figure 6: RSVP signaling & labels allocation for an explicit tunnel

The following configuration example illustrates the required configuration. It's worth noting that there are no routing constraints defined for the LSP. In other words, the the only configuration shown is the definition of the explicit path. In many(or most) RSVP-TE deployments the paths are not explicitly defined but instead a routing constraint is defined, such as bandwidth or link affinity, such that the ingress node or external CSPF computes the explicit path dynamically to meet the routing constraint.

Example R1 configuration

protocols {

rsvp {

interface all;

...

isis {

interface all;

...

mpls {

label-switched-path te-lsp-to-r6 {

to 1.1.1.6;

primary {

explicit-path-to-r6;

...

path explicit-path-to-r6 {

10.1.13.2 strict;

10.1.34.2 strict;

10.1.45.2 strict;

10.1.56.2 strict;

Verification of an explicit path to R6

regress@R1# run show mpls lsp name to-r6 detail

Ingress LSP: 4 sessions

1.1.1.6

From: 1.1.1.1, State: Up, ActiveRoute: 0, LSPname: to-r6

ActivePath: to-r6 (primary)

LSPtype: Static Configured, Penultimate hop popping

LoadBalance: Random

Follow destination IGP metric

Encoding type: Packet, Switching type: Packet, GPID: IPv4

LSP Self-ping Status : Enabled

*Primary to-r6 State: Up

Priorities: 7 0

SmartOptimizeTimer: 180

Flap Count: 3

MBB Count: 0

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)

10.1.13.2 S 10.1.34.2 S 10.1.45.2 S 10.1.56.2 S

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):

10.1.13.2(Label=18) 10.1.34.2(Label=18) 10.1.45.2(Label=23) 10.1.56.2(Label=3)

regress@R1# run show route 1.1.1.6 table inet.3

inet.3: 6 destinations, 13 routes (6 active, 0 holddown, 0 hidden)

@ = Routing Use Only, # = Forwarding Use Only

+ = Active Route, - = Last Active, * = Both

1.1.1.6/32 *[RSVP/7/1] 00:00:23, metric 30

> to 10.1.13.2 via ge-0/0/2.0, label-switched-path to-r6

[LDP/9] 01:07:18, metric 1

> to 10.1.12.2 via ge-0/0/1.0, Push 87

SR for Traffic Engineering

Much like RSVP-TE explicit LSPs, a Network operator will request, typically through configuration, LSPs that meet specific constraints. The main difference being not only the specific configuration syntax, though they are quite similar, but the concept of describing the ‘routing constraint’ using the same CLI constructs. To provide complex TE constraints, an ingress SR node may need to rely on a external Controller or PCE.

Using the same example as in the RSVP-TE example, a network operator could request an LSP that originates at Node R1, terminates at Node R6, reserves 100 megabits per second, and traverses blue interfaces only but would require an external Controller/PCE to compute the path. An external PCE is required only because of the specified BW constraint. If BW is not required, a distributed path computation completed by R1 would suffice for the SR path computation. Figure 5, below, illustrates the resulting SR path and MPLS forwarding-table label operations. Note that there is a fairly significant difference in the label forwarding operations for a SR-TE LSP compared to the SPF SR LSP and the previous RSVP-TE LSPs..

Figure 7: SR signaling & labels allocation for an explicit tunnel

SR adj-SIDs are dynamically allocated by default. Because the example below, illustrates using traditional CLI techniques for describing the explicit path and each hop in the path is specified by it’s label/SID, it is recommended that labels are pre-planned and statically assigned so that each link has a unique label/SID, much like how IP addressing is handled. It’s worth noting that a SR-TE path can also be described, via CLI, using traditional IP addresses as the specified hops in the path and allowing the ingress router to resolve the SID and label stack.

Example R1 configuration

Defining static adjacency SIDs:

protocols {

isis {

interface ge-0/0/1.0 {

level 2 {

ipv4-adjacency-segment {

unprotected label 19;

Defining the explicit SR Tunnels:

protocols {

source-packet-routing {

source-routing-path sr-te-lsp-to-r6 {

to 1.1.1.6;

primary {

explicit-path-to-r6;

segment-list explicit-path-to-r6 {

segment1 label 19;

segment2 label 16;

segment3 label 17;

segment4 label 19;

Alternatively, you may use the auto-translate option and describe the path as a serious of IP hops, like an RSVP-TE path, and JUNOS will translate the SIDs. This has a nice advantage of removing the need to statically configure adjacency-SIDs as well ensuring a Controller, who may have calculated the path is not required to change the path in the event of a link down event.

protocols {

source-packet-routing {

segment-list explicit-path-to-r6 {

hop1 ip-address 10.1.13.2;

hop2 ip-address 10.1.34.2;

hop3 ip-address 10.1.45.2;

hop4 ip-address 10.1.56.2;

auto-translate;

Verification of an explicit path to R6

regress@R1# run show route 1.1.1.7 table inet.3

inet.3: 7 destinations, 13 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

1.1.1.7/32 *[SPRING-TE/8] 13:42:41, metric 1

> to 10.1.13.2 via ge-0/0/2.0, Push 18, Push 17, Push 16(top)

[L-ISIS/14] 14:00:16, metric 30

> to 10.1.12.2 via ge-0/0/1.0, Push 107

regress@R1# run show spring-traffic-engineering lsp detail

Name: sr-te-lsp-to-r6

Tunnel-source: Static configuration

To: 1.1.1.6

State: Up

Path: explicit-path-to-r6

Outgoing interface: ge-0/0/2.0

Auto-translate status: Enabled Auto-translate result: Success

BFD status: N/A BFD name: N/A

SR-ERO hop count: 4

Hop 1 (Strict):

NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.1.13.2

SID type: 20-bit label, Value: 19

Hop 2 (Strict):

NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.1.34.2

SID type: 20-bit label, Value: 16

Hop 3 (Strict):

NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.1.45.2

SID type: 20-bit label, Value: 17

Hop 4 (Strict):

NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.1.56.2

SID type: 20-bit label, Value: 19

Notable Differences

As with the shortest-path forwarding example, let’s look at a few notable attributes, in table 2, for the TE comparison.

Protocol	Planning	Configuration	Protocols	Labels	ECMP
RSVP-TE	-	RSVP-TE LSPs	ISIS & RSVP	1	Yes*
Segment Routing	Static Adj-SID***	SR-TE LSPs & static adj-SIDs***	ISIS with SR extensions	Many	Yes**

Table 2: RSVP and SR TE Comparison

* RSVP multi-path may be employed by utilizing container LSPs, resulting in ingress ECMP

** SR based ECMP may be employed if the explicit path contains ‘loose hops’, aka node-SIDs. ECMPs are a property of the IGP SPF between hops defined in the path.

*** Only recommended if auto-translate is not used. Static SID allocation requires provisioning on all nodes in the network, not just on the ingress node as the example shows

But there is something else worth considering here … notice the presence of both SPF routes and Explicit routes to the same protocol next-hop in the inet.3 routing table for both LDP & RSVP-TE and SR! How does an ingress router make service specific forwarding decisions? In the case of the LDP and RSVP-TE LSPs, since the RSVP-TE preference(7) is lower than the LDP route(9), it will be preferred over the LDP route. The same is true for the SR routes, since the protocol preference for the SR-TE path(8) is preferred over the L-ISIS(14) path, all traffic will be forwarded using the SR-TE route.

JUNOS Multipath Routes

As we’ve seen, the default behavior for route selection is to use the protocol preference of the contributing route for next-hop resolution. Protocol preference is respectively RSVP-TE (7), SPRING-TE (8), LDP(9), and L-ISIS (14). Thus if there is a SPF LSP and a TE LSP to the same protocol next-hop in the inet.3 RIB then the TE LSP will always be preferred and all traffic will be forwarded using the TE-LSP.

A Multi-path policy can be created to combine different protocol routes to the same destination for service route resolution and thus load-balancing between the SPF and TE routes. The combined “multi-path route” needs to be from the same RIB and must include the active route. An example is shown below for both the SR and LDP plus RSVP-TE use-cases. The resulting forwarding behavior is illustrated in figure 7 below.

Figure 8: ingress LB’ing between two different protocols

Example R1 configuration

routing-options {

rib inet.3 {

policy-multipath policy spf-te-lb;

policy-options {

policy-statement spf-te-lb {

term 1 {

from protocol [ rsvp ldp ];

then accept;

}

term 2 {

from protocol [ l-isis spring-te ];

then accept;

Verification of the LDP & RSVP-TE routes

regress@R1# run show route 1.1.1.6 protocol multipath

inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)

inet.3: 6 destinations, 20 routes (6 active, 0 holddown, 0 hidden)

@ = Routing Use Only, # = Forwarding Use Only

+ = Active Route, - = Last Active, * = Both

1.1.1.6/32 [Multipath/7/1] 00:03:37, metric 30

> to 10.1.12.2 via ge-0/0/1.0, Push 87

to 10.1.13.2 via ge-0/0/2.0, label-switched-path to-r6

Verification of the L-ISIS & SR-TE routes

regress@R1# run show route 1.1.1.6 protocol multipath

inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)

inet.3: 6 destinations, 20 routes (6 active, 0 holddown, 0 hidden)

@ = Routing Use Only, # = Forwarding Use Only

+ = Active Route, - = Last Active, * = Both

1.1.1.6/32 [Multipath/7/1] 00:05:04, metric 30

> to 10.1.12.2 via ge-0/0/1.0, Push 106

to 10.1.13.2 via ge-0/0/2.0, Push 19, Push 17, Push 16(top)

Closing Thoughts

LDP, SR and RSVP-TE provide solutions for shortest-path and traffic-engineering, each with their own subtle differences in planning requirements, configuration complexity, label signalling, and forwarding behaviors. Much like the classical deployment of multiple protocols, LDP plus RSVP-TE, a single protocol solution like SR-TE still requires implicit or explicit service mapping policies, due to the nature of protocol preferences in JUNOS RIBs, to provide differentiated services. Techniques for implementing such policies will be described in a future blog.

Acknowledgements

A special thanks to Harish Sitaraman <hsitaraman@juniper.net> and Rafal Jan Szarecki <rjszarecki@juniper.net> for their contributions and thorough reviews.