Industry Solutions and Trends
Technology is more than just networking and Juniper experts share their views on all the trends affecting IT
Industry Solutions and Trends
RSVP-TE Pop&Go: Using a shared MPLS forwarding plane
09.13.17

Introduction

 

Many networks incorporate various Traffic Engineering (TE) techniques to efficiently utilize network bandwidth. RSVP-TE is a widely-deployed control plane protocol that is used to setup Label Switched Paths (LSP) and provides a rich feature set for TE - protection, bandwidth admission control, priority and preemption. Network operators continue to drive for operational efficiencies in managing network state and resource consumption as these are important to better serve customers and to maximize profitability. Fine granular control and near real time optimization of traffic paths continue to grow in importance.

 

Currently many network operators use MPLS-TE auto-bandwidth [3] to automatically adjust the bandwidth requirements and possibly the paths of LSPs based on actual traffic demand. Further, TE++ Container LSPs [4], a technology provided by Junos enables automatic creation and deletion of LSPs for better bin packing.

 

Network state scaling can be characterized across the control plane and forwarding plane.

As the scale of RSVP-TE LSPs has grown, recommendations have been proposed to manage control plane state. Junos supports Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments [5] and can accommodate high LSP scaling requirements at a transit Label Switching Router (LSR). However, the forwarding plane state (i.e. the number of labels in the LFIB) required at transit LSRs continues to be directly proportional to the RSVP-TE control plane state. Some forwarding plane hardware implementations have limitations in the number of labels that can be supported which constrains the number of LSPs that can be supported in the control plane.

 

Auto-bandwidth deployments increasingly require aggressive (shorter) periods between bandwidth adjustments for LSPs based on the traffic demand. This can increase the churn in LSP state resulting in the creation and deletion of control and forwarding plane states on transit LSRs. This in turn increases the frequency of the allocation and installation of new labels and deleting old label state across the control plane, forwarding plane and intermediate abstraction layers.

 

In summary, there are two challenges:

  • Scale of LSPs in the forwarding plane hardware
  • Churn in LSP states in both the control plane and forwarding plane hardware

There is considerable interest in technologies such as Segment Routing (SR) to address these challenges. However, Segment Routing introduces a number of additional challenges for operators to address as they migrate or utilize Segment Routing in conjunction with their existing RSVP-TE networks. Some of these challenges are outlined in an earlier blog post.

 

RSVP-TE Pop&Go

 

We introduce concepts from Signaling RSVP-TE tunnels on a shared MPLS forwarding plane [1][2] to manage the forwarding plane state scale and churn challenges and to further decouple RSVP-TE from any limitations of the forwarding plane hardware. This solution is called RSVP-TE Pop&Go. RSVP-TE Pop&Go LSPs couple the rich feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing MPLS forwarding plane. The functionality is also backwards compatible with traditional RSVP-TE LSPs that allocate unique labels per LSP.

 

Pop label and their allocation

 

Pop&Go LSPs introduces the notion of pre-installed per TE link(*pop labels that are shared by RSVP-TE LSPs that traverse these links and significantly reducing the forwarding plane state required. A transit LSR allocates a unique pop label per TE link with a forwarding action to pop the label and forward the packet over that TE link should the label appear at the top of the packet.

 

 

pop-label.png

Multiple labels may be allocated per TE link to accommodate LSPs that require facility bypass protection.

 

Label Stacking

 

RSVP-TE uses a stack of pop labels at the ingress LER to direct traffic through the LSP. In the Figure, both LSP A-F and LSP B-G share links C-D and D-E and hence share the pop labels for those links. The label stacks used at A and B both have labels 200 and 300 to traverse links C-D and D-E respectively.

 

topo.png

 

Multiple LSPs from an ingress LER can have the same label stack but can account for LSP traffic statistics independently for each LSP so that MPLS auto-bandwidth can work as it does today.

 

In essence, the pop labels are shared on transit LSRs across all LSPs sharing a TE link thereby reducing the number of labels required from O(N^2) to O(TE links). This offers a MPLS forwarding plane that appears static in nature and drastically reduces the number of and churn in LSP states in the forwarding plane on transit LSRs. The RSVP-TE control plane can also operate faster during LSP setup and deletion since interaction with the forwarding plane is removed.

 

user@D> show mpls lsp terse         

...

Transit LSP: 64000 sessions

Total 64000 displayed, Up 64000, Down 0

 

user@D> show rsvp pop-and-forward (**)   

RSVP pop-and-forward: 1 shared labels

Label-in     Hop-count  Next-segment- Protection     Session-   

                        label                        count

300          1                        unprotected    64000     

 

user@D> show route table mpls.0

mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

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

 

0                  *[MPLS/0] 00:07:56, metric 1

                      Receive

1                  *[MPLS/0] 00:07:56, metric 1

                      Receive

2                  *[MPLS/0] 00:07:56, metric 1

                      Receive

13                 *[MPLS/0] 00:07:56, metric 1

                      Receive

300                *[RSVP/7/1] 00:03:35, metric 1

                    > to 192.168.2.1 via ge-0/0/1.0, Pop     

300(S=0)           *[RSVP/7/1] 00:03:35, metric 1

                    > to 192.168.2.1 via ge-0/0/1.0, Pop     

 

From the above show outputs, it can be observed that for 64k unprotected LSPs transiting the same TE link, a single label is programmed in the mpls.0 table.

 

Delegation of label stack imposition

 

Depending on topology and LSP constraints, the depth of the entire label stack can be too large for imposition by some ingress forwarding plane hardware. Pop&Go introduces Delegation labels which automatically manage any limitations that ingress nodes may have when imposing a label stack. The discovery and selection of delegation nodes responsible for managing delegation labels is integrated in the Pop&Go solution making it self-containing and easier to deploy.

 

Pop&Go LSPs leverage the assistance of one or more transit delegation hops to delegate label stack imposition. There are two delegation techniques, namely automatic and explicit delegation which an ingress LER can utilize – automatic and explicit delegation.

 

Automatic delegation provides for automatic selection of delegation hops whereas Explicit delegation allows the ingress LER or an external TE controller to explicitly specify the choice of delegation hops.

 

delegation.png

A delegation hop is a transit LSR that uses a delegation label to in turn push a stack of labels to traverse a collection of hops to reach the next delegation hop or egress. A delegation label can be reused by a delegation hop for different LSPs that share the same set of hops and stack of labels.

 

In the above figure, the ingress LER can allow transit LSRs to automatically select themselves as delegation hops. In this model, each node understands its own capabilities of how many labels it can receive and parse(***) the maximum number of labels it can push outbound.

 

Alternately, the ingress LER or TE controller can explicitly select the delegation hops for a LSP. In order to achieve this, the path computation engine should know the capabilities such as maximum label stack push limit and maximum label receive limit for all nodes.

 

Using a Controller

 

A centralized TE controller can also orchestrate RSVP-TE Pop&Go LSPs by computing the path and requesting an ingress LER to request auto or explicit delegation for a LSP. Pop&Go LSPs do not require a TE controller. However, all the typical benefits of global path optimization and placement can be realized using Pop&Go with a controller. This enables operators to realize many of the benefits of a simplified forwarding plane in their existing RSVP networks while incrementally or selectively introducing controller driven operation into their networks.

 

Summary

 

In summary, RSVP-TE Pop&Go LSPs constitute another tool in the Traffic Engineering toolkit. When compared with traditional RSVP-TE LSPs, it offers reduced forwarding plane state and improved system performance. As the trend with incorporating controllers continues to evolve, Pop&Go LSPs offer a pragmatic path to leverage the feature richness of the RSVP-TE control plane coupled with the minimal state of the Segment Routing forwarding plane.

 

Authors

 

Harish Sitaraman, hsitaraman@juniper.net 

Vishnu Pavan Beeram, vbeeram@juniper.net

Chandrasekar Ramachandran, csekar@juniper.net

 

Acknowledgements:

Rafal Jan Szarecki, Steve Ulrich

 

References:

 

[1] Signaling RSVP-TE tunnels on a shared MPLS forwarding plane

[2] Lightning Talks: RSVP Pop'n'Go

[3] Configuring Automatic Bandwidth Allocation for LSPs

[4] Dynamic Bandwidth Management Using Container LSP Overview

[5] Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments

 

(*) TE link is a logical link that has TE attributes representing resources on a physical link and used for the purposes of path computation.

(**) show commands and outputs are for illustration and subject to change

(***) Parse such that it can perform proper hashing to pick an outbound interface if, for example, the interface was an Aggregated Ethernet bundle