From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8577.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc8577.txt (limited to 'doc/rfc/rfc8577.txt') diff --git a/doc/rfc/rfc8577.txt b/doc/rfc/rfc8577.txt new file mode 100644 index 0000000..df790c1 --- /dev/null +++ b/doc/rfc/rfc8577.txt @@ -0,0 +1,1347 @@ + + + + + + +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: