Signaling RSVP-TE tunnels on a shared MPLS forwarding plane
draft-sitaraman-mpls-rsvp-shared-labels-03

Document Type Replaced Internet-Draft (mpls WG)
Last updated 2017-12-18 (latest revision 2017-12-08)
Replaced by draft-ietf-mpls-rsvp-shared-labels
Stream IETF
Intended RFC status Proposed Standard
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Adopted by a WG
Document shepherd Loa Andersson
IESG IESG state Replaced by draft-ietf-mpls-rsvp-shared-labels
Consensus Boilerplate Yes
Telechat date
Responsible AD (None)
Send notices to Loa Andersson <loa@pi.nu>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-sitaraman-mpls-rsvp-shared-labels-03.txt

Abstract

As the scale of MPLS RSVP-TE networks has grown, so the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in control plane state. However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane. This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control plane scaling on that node. That is, it allows many more LSPs to be supported than there are forwarding plane labels available. This work introduces the notion of pre-installed 'per Traffic Engineering (TE) link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing MPLS forwarding plane. This document also introduces the ability to mix different types of label operations along the path of an LSP, thereby allowing the ingress router or an external controller to influence how to optimally place a LSP in the network.

Authors

Harish Sitaraman (hsitaraman@juniper.net)
Vishnu Beeram (vbeeram@juniper.net)
Tejal Parikh (tejal.parikh@verizon.com)
Tarek Saad (tsaad@cisco.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)