Internet Engineering Task Force (IETF) H. Sitaraman Request for Comments: 8577 V. Beeram Category: Standards Track Juniper Networks ISSN: 2070-1721 T. Parikh Verizon T. Saad Cisco Systems April 2019 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane Abstract As the scale of MPLS RSVP-TE networks has grown, 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 the amount of control-plane state information. 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. It introduces the notion of preinstalled 'per-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 (SR) MPLS forwarding plane. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8577. Sitaraman, et al. Standards Track [Page 1] RFC 8577 RSVP-TE Shared Labels April 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Sitaraman, et al. Standards Track [Page 2] RFC 8577 RSVP-TE Shared Labels April 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 6 4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 6 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 8 5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8 5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 9 5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 10 5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 11 5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 11 5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 11 6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 13 7. Construction of Label Stacks . . . . . . . . . . . . . . . . 14 8. Facility Backup Protection . . . . . . . . . . . . . . . . . 14 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 14 9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 15 9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 16 9.3. RRO Label Sub-object Flag: TE Link Label . . . . . . . . 16 9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 16 9.5. RRO Label Sub-object Flag: Delegation Label . . . . . . . 17 9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 17 9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 18 10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 19 11.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 19 11.3. Record Route Label Sub-object Flags: TE Link Label, Delegation Label . . . . . . . . . . . . . . . . . . . . 20 11.4. Error Codes and Error Values . . . . . . . . . . . . . . 20 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Sitaraman, et al. Standards Track [Page 3] RFC 8577 RSVP-TE Shared Labels April 2019 1. Introduction The scaling of RSVP-TE [RFC3209] control-plane implementations can be improved by adopting the guidelines and mechanisms described in [RFC2961] and [RFC8370]. These documents do not affect the forwarding-plane state required to handle the control-plane state. The forwarding-plane state remains unchanged and is directly proportional to the total number of Label Switching Paths (LSPs) supported by the control plane. This document describes a mechanism that prevents the size of the platform-specific label space on a Label Switching Router (LSR) from being a constraint to pushing the limits of control-plane scaling on that node. This work introduces the notion of preinstalled 'per-TE link labels' that are allocated by an LSR. Each such label is installed in the MPLS forwarding plane with a 'pop' operation and instructions to forward the received packet over the TE link. An LSR advertises this label in the Label object of a Resv message as LSPs are set up, and they are recorded hop by hop in the Record Route Object (RRO) of the Resv message as it traverses the network. The ingress Label Edge Router (LER) constructs and pushes a stack of labels [RFC3031] using the labels received in the RRO. These 'TE link labels' can be shared by MPLS RSVP-TE LSPs that traverse the same TE link. This forwarding-plane behavior fits in the MPLS architecture [RFC3031] and is the same as that exhibited by Segment Routing (SR) [RFC8402] when using an MPLS forwarding plane and a series of adjacency segments [SEG-ROUTING]. This work couples the feature benefits of the RSVP-TE control plane with the simplicity of the SR MPLS forwarding plane. RSVP-TE using a shared MPLS forwarding plane offers the following benefits: 1. Shared labels: The transit label on a TE link is shared among RSVP-TE tunnels traversing the link and is used independently of the ingress and egress of the LSPs. 2. Faster LSP setup time: No forwarding-plane state needs to be programmed during LSP setup and teardown, resulting in faster provisioning and deprovisioning of LSPs. 3. Hitless rerouting: New transit labels are not required during make-before-break (MBB) in scenarios where the new LSP instance traverses the exact same path as the old LSP instance. This saves the ingress LER and the services that use the tunnel from Sitaraman, et al. Standards Track [Page 4] RFC 8577 RSVP-TE Shared Labels April 2019 needing to update the forwarding plane with new tunnel labels, thereby making MBB events faster. Periodic MBB events are relatively common in networks that deploy the 'auto-bandwidth' feature on RSVP-TE LSPs to monitor bandwidth utilization and periodically adjust LSP bandwidth. 4. Mix-and-match labels: Both 'TE link labels' and regular labels can be used on transit hops for a single RSVP-TE tunnel (see Section 6). This allows backward compatibility with transit LSRs that provide regular labels in Resv messages. No additional extensions to routing protocols are required in order to support key functionalities such as bandwidth admission control, LSP priorities, preemption, and auto-bandwidth on this shared MPLS forwarding plane. This document also discusses how Fast Reroute [RFC4090] via facility backup link protection using regular bypass tunnels can be supported on this forwarding plane. The signaling procedures and extensions discussed in this document do not apply to Point to Multipoint (P2MP) RSVP-TE tunnels. 2. Terminology The following terms are used in this document: TE link label: An incoming label at an LSR that will be popped by the LSR with the packet being forwarded over a specific outgoing TE link to a neighbor. Shared MPLS forwarding plane: An MPLS forwarding plane where every participating LSR uses TE link labels on every LSP. Segment Routed RSVP-TE tunnel: An MPLS RSVP-TE tunnel that requests the use of a shared MPLS forwarding plane at every hop of the LSP. The corresponding LSPs are referred to as "Segment Routed RSVP-TE LSPs". Delegation hop: A transit hop of a Segment Routed RSVP-TE LSP that is selected to assist in the imposition of the label stack in scenarios where the ingress LER cannot impose the full label stack. There can be multiple delegation hops along the path of a Segment Routed RSVP-TE LSP. Delegation label: A label assigned at the delegation hop to represent a set of labels that will be pushed at this hop. Sitaraman, et al. Standards Track [Page 5] RFC 8577 RSVP-TE Shared Labels April 2019 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Allocation of TE Link Labels An LSR that participates in a shared MPLS forwarding plane MUST allocate a unique TE link label for each TE link. When an LSR encounters a TE link label at the top of the label stack, it MUST pop the label and forward the packet over the TE link to the downstream neighbor on the RSVP-TE tunnel. Multiple TE link labels MAY be allocated for the TE link to accommodate tunnels requesting protection. Implementations that maintain per-label bandwidth accounting at each hop must aggregate the reservations made for all the LSPs using the shared TE link label. 4. Segment Routed RSVP-TE Tunnel Setup This section provides an example of how the RSVP-TE signaling procedure works to set up a tunnel utilizing a shared MPLS forwarding plane. The sample topology below is used to explain the example. Labels shown at each node are TE link labels that, when present at the top of the label stack, indicate that they should be popped and that the packet should be forwarded on the TE link to the neighbor. +---+100 +---+150 +---+200 +---+250 +---+ | A |-----| B |-----| C |-----| D |-----| E | +---+ +---+ +---+ +---+ +---+ |110 |450 |550 |650 |850 | | | | | | |400 |500 |600 |800 | +---+ +---+ +---+ +---+ +-------| F |-----|G |-----|H |-----|I | +---+300 +---+350 +---+700 +---+ Figure 1: Sample Topology -- TE Link Labels Sitaraman, et al. Standards Track [Page 6] RFC 8577 RSVP-TE Shared Labels April 2019 Consider two tunnels: RSVP-TE tunnel T1: From A to E on path A-B-C-D-E RSVP-TE tunnel T2: From F to E on path F-B-C-D-E Both tunnels share the TE links B-C, C-D, and D-E. RSVP-TE is used to signal the setup of tunnel T1 (using the TE link label attributes flag defined in Section 9.2). When LSR D receives the Resv message from the egress LER E, it checks the next-hop TE link (D-E) and provides the TE link label (250) in the Resv message for the tunnel placing the label value in the Label object. It also provides the TE link label (250) in the Label sub-object carried in the RRO and sets the TE link label flag as defined in Section 9.3. Similarly, LSR C provides the TE link label (200) for the TE link C-D, and LSR B provides the TE link label (150) for the TE link B-C. For tunnel T2, the transit LSRs provide the same TE link labels as described for tunnel T1 as the links B-C, C-D, and D-E are common between the two LSPs. The ingress LERs (A and F) will push the same stack of labels (from top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and T2, respectively. It should be noted that a transit LSR does not swap the top TE link label on an incoming packet (the label that it advertised in the Resv message it sent); all it has to do is pop the top label and forward the packet. The values in the Label sub-objects in the RRO are of interest to the ingress LERs when constructing the stack of labels to impose on the packets. If, in this example, there were another RSVP-TE tunnel T3 from F to I on path F-B-C-D-E-I, then this tunnel would also share the TE links B-C, C-D, and D-E and traverse link E-I. The label stack used by F would be {150, 200, 250, 850}. Hence, regardless of where the LSPs start and end, they will share LSR labels at shared hops in the shared MPLS forwarding plane. There MAY be a local operator policy at the ingress LER that influences the maximum depth of the label stack that can be pushed for a Segment Routed RSVP-TE tunnel. Prior to signaling the LSP, the ingress LER may determine that it is unable to push a label stack containing one label for each hop along the path. In some scenarios, Sitaraman, et al. Standards Track [Page 7] RFC 8577 RSVP-TE Shared Labels April 2019 the ingress LER may not have sufficient information to make that determination. In these cases, the LER SHOULD adopt the techniques described in Section 5. 5. Delegating Label Stack Imposition One or more transit LSRs can assist the ingress LER by imposing part of the label stack required for the path. Consider the example in Figure 2 with an RSVP-TE tunnel from A to L on path A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A to impose the full label stack, so it uses the assistance of delegation hops LSR D and LSR I to impose parts of the label stack. Each delegation hop allocates a delegation label to represent a set of labels that will be pushed at this hop. When a packet arrives at a delegation hop LSR with a delegation label, the LSR pops the label and pushes a set of labels before forwarding the packet. 1250d +---+100p +---+150p +---+200p +---+250p +---+300p +---+ | A |------| B |------| C |------| D |------| E |------| F | +---+ +---+ +---+ +---+ +---+ +---+ |350p | 1500d | +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ | L |------| K |------| J |------| I |------| H |------+ G + +---+ +---+ +---+ +---+ +---+ +---+ Notation: