diff options
Diffstat (limited to 'doc/rfc/rfc8577.txt')
| -rw-r--r-- | doc/rfc/rfc8577.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
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: <Label>p - TE link label + <Label>d - Delegation label + + Figure 2: Delegating Label Stack Imposition + +5.1. Stacking at the Ingress + + When delegation labels come into play, there are two stacking + approaches from which the ingress can choose. Section 7 explains how + the label stack can be constructed. + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 8] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +5.1.1. Stack to Reach Delegation Hop + + In this approach, the stack pushed by the ingress carries a set of + labels that will take the packet to the first delegation hop. When + this approach is employed, the set of labels represented by a + delegation label at a given delegation hop will include the + corresponding delegation label from the next delegation hop. As a + result, this delegation label can only be shared among LSPs that are + destined to the same egress and traverse the same downstream path. + + This approach is shown in Figure 3. The delegation label 1250 + represents the stack {300, 350, 400, 450, 1500}, and the delegation + label 1500 represents the label stack {550, 600}. + + + +---+ +---+ +---+ + | A |-----.....-----| D |-----.....-----| I |-----..... + +---+ +---+ +---+ + + Pop 1250 & Pop 1500 & + Push Push Push + ...... ...... ...... + : 150: 1250->: 300: 1500->: 550: + : 200: : 350: : 600: + :1250: : 400: ...... + ...... : 450: + :1500: + ...... + + Figure 3: Stack to Reach Delegation Hop + + With this approach, the ingress LER A will push {150, 200, 1250} for + the tunnel in Figure 2. At LSR D, the delegation label 1250 will get + popped, and {300, 350, 400, 450, 1500} will get pushed. At LSR I, + the delegation label 1500 will get popped, and the remaining set of + labels {550, 600} will get pushed. + + + + + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 9] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +5.1.2. Stack to Reach Egress + + In this approach, the stack pushed by the ingress carries a set of + labels that will take the packet all the way to the egress so that + all the delegation labels are part of the stack. When this approach + is employed, the set of labels represented by a delegation label at a + given delegation hop will not include the corresponding delegation + label from the next delegation hop. As a result, this delegation + label can be shared among all LSPs traversing the segment between the + two delegation hops. + + The downside of this approach is that the number of hops that the LSP + can traverse is dictated by the label stack push limit of the + ingress. + + This approach is shown in Figure 4. The delegation label 1250 + represents the stack {300, 350, 400, 450}, and the delegation label + 1500 represents the label stack {550, 600}. + + +---+ +---+ +---+ + | A |-----.....-----| D |-----.....-----| I |-----..... + +---+ +---+ +---+ + + Pop 1250 & Pop 1500 & + Push Push Push + ...... ...... ...... + : 150: 1250->: 300: 1500->: 550: + : 200: : 350: : 600: + :1250: : 400: ...... + :1500: : 450: + ...... ...... + |1500| + ...... + + Figure 4: Stack to Reach Egress + + With this approach, the ingress LER A will push {150, 200, 1250, + 1500} for the tunnel in Figure 2. At LSR D, the delegation label + 1250 will get popped, and {300, 350, 400, 450} will get pushed. At + LSR I, the delegation label 1500 will get popped, and the remaining + set of labels {550, 600} will get pushed. The signaling extension + required for the ingress to indicate the chosen stacking approach is + defined in Section 9.6. + + + + + + + + +Sitaraman, et al. Standards Track [Page 10] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +5.2. Explicit Delegation + + In this delegation option, the ingress LER can explicitly delegate + one or more specific transit LSRs to handle pushing labels for a + certain number of their downstream hops. In order to accurately pick + the delegation hops, the ingress needs to be aware of the label stack + depth push limit (total number of MPLS labels that can be imposed, + including all service/transport/special labels) of each of the + transit LSRs prior to initiating the signaling sequence. The + mechanism by which the ingress or controller (hosting the path + computation element) learns this information is outside the scope of + this document. Base MPLS Imposition MSD (BMI-MSD) advertisement, + specified in [RFC8491], is an example of such a mechanism. + + The signaling extension required for the ingress LER to explicitly + delegate one or more specific transit hops is defined in Section 9.4. + The extension required for the delegation hop to indicate that the + recorded label is a delegation label is defined in Section 9.5. + +5.3. Automatic Delegation + + In this approach, the ingress LER lets the downstream LSRs + automatically pick suitable delegation hops during the initial + signaling sequence. The ingress does not need to be aware up front + of the label stack depth push limit of each of the transit LSRs. + This approach SHOULD be used if there are loose hops [RFC3209] in the + explicit route. The delegation hops are picked based on a per-hop + signaled attribute called the Effective Transport Label-Stack Depth + (ETLD), as described in the next section. + +5.3.1. Effective Transport Label-Stack Depth (ETLD) + + The ETLD is signaled as a per-hop recorded attribute in the Path + message [RFC7570]. When automatic delegation is requested, the + ingress MUST populate the ETLD with the maximum number of transport + labels that it can potentially send to its downstream hop. This + value is then decremented at each successive hop. If a node is + reached and it is determined that this hop cannot support automatic + delegation, then it MUST NOT use TE link labels and use regular + labels instead. If a node is reached where the ETLD set from the + previous hop is 1, then that node MUST select itself as the + delegation hop. If a node is reached and it is determined that this + hop cannot receive more than one transport label, then that node MUST + select itself as the delegation hop. If there is a node or a + sequence of nodes along the path of the LSP that do not support ETLD, + then the immediate hop that supports ETLD MUST select itself as the + delegation hop. The ETLD MUST be decremented at each non-delegation + transit hop by either 1 or some appropriate number based on the local + + + +Sitaraman, et al. Standards Track [Page 11] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + + policy. For example, consider a transit node with a local policy + that mandates it to take the label stack read limit into account when + decrementing the ETLD. With this policy, the ETLD is decremented in + such a way that the transit hop does not receive more labels in the + stack than it can read. At each delegation hop, the ETLD MUST be + reset to the maximum number of transport labels that the hop can + send, and the ETLD decrements start again at each successive hop + until either a new delegation hop is selected or the egress is + reached. As a result, by the time the Path message reaches the + egress, all delegation hops are selected. During the Resv + processing, at each delegation hop, a suitable delegation label is + selected (either an existing label is reused or a new label is + allocated) and recorded in the Resv message. + + Consider the example shown in Figure 5. Let's assume ingress LER A + can push up to three transport labels while the remaining nodes can + push up to five transport labels. The ingress LER A signals the + initial Path message with ETLD set to 3. The ETLD value is adjusted + at each successive hop and signaled downstream as shown. By the time + the Path message reaches the egress LER L, LSRs D and I are + automatically selected as delegation hops. + + ETLD:3 ETLD:2 ETLD:1 ETLD:5 ETLD:4 + -----> -----> -----> -----> -----> + 1250d + +---+100p +---+150p +---+200p +---+250p +---+300p +---+ + | A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:3 + +---+ +---+ +---+ +---+ +---+ +---+ | + |350p | + | | + 1500d | | + +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ v + | L |-----| K |-----| J |-----| I |-----| H |-----+ G + + +---+ +---+ +---+ +---+ +---+ +---+ + + ETLD:3 ETLD:4 ETLD:5 ETLD:1 ETLD:2 + <----- <----- <----- <----- <----- + + Figure 5: ETLD + + When an LSP that requests automatic delegation also requests facility + backup protection [RFC4090], the ingress or the delegation hop MUST + account for the bypass tunnel's label(s) when populating the ETLD. + Hence, when a regular bypass tunnel is used to protect the facility, + the ETLD that gets populated on these nodes is one less than what + gets populated for a corresponding unprotected LSP. + + + + + +Sitaraman, et al. Standards Track [Page 12] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + + Signaling extension for the ingress LER to request automatic + delegation is defined in Section 9.4. The extension for signaling + the ETLD is defined in Section 9.7. The extension required for the + delegation hop to indicate that the recorded label is a delegation + label is defined in Section 9.5. + +6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel + + Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP. + Certain LSRs can use TE link labels and others can use regular + labels. The ingress can construct a label stack appropriately based + on what type of label is recorded from every transit LSR. + + (#) (#) + +---+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 +---+ + + Notation: (#) denotes regular labels + Other labels are TE link labels + + Figure 6: Sample Topology -- TE Link Labels and Regular Labels + + If the transit LSR allocates a regular label to be sent upstream in + the Resv, then the label operation at the LSR is a swap to the label + received from the downstream LSR. If the transit LSR is using a TE + link label to be sent upstream in the Resv, then the label operation + at the LSR is a pop and forward regardless of any label received from + the downstream LSR. There is no change in the behavior of a + penultimate hop popping (PHP) LSR [RFC3031]. + + Section 7 explains how the label stack can be constructed. For + example, the LSP from A to I using path A-B-C-D-E-I will use a label + stack of {150, 200}. + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 13] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +7. Construction of Label Stacks + + The ingress LER or delegation hop MUST check the type of label + received from each transit hop as recorded in the RRO in the Resv + message and generate the appropriate label stack to reach the next + delegation hop or the egress. + + The following logic is used by the node constructing the label stack: + + Each RRO label sub-object MUST be processed starting with the + label sub-object from the first downstream hop. Any label + provided by the first downstream hop MUST always be pushed on the + label stack regardless of the label type. If the label type is a + TE link label, then any label from the next downstream hop MUST + also be pushed on the constructed label stack. If the label type + is a regular label, then any label from the next downstream hop + MUST NOT be pushed on the constructed label stack. If the label + type is a delegation label, then the type of stacking approach + chosen by the ingress for this LSP (Section 5.1) MUST be used to + determine how the delegation labels are pushed in the label stack. + +8. Facility Backup Protection + + The following section describes how link protection works with + facility backup protection [RFC4090] using regular bypass tunnels for + the Segment Routed RSVP-TE tunnels. The procedures for supporting + node protection are not discussed in this document. The use of + Segment Routed bypass tunnels for providing facility protection is + left for further study. + +8.1. Link Protection + + To provide link protection at a Point of Local Repair (PLR) with a + shared MPLS forwarding plane, the LSR MUST allocate a separate TE + link label for the TE link that will be used for RSVP-TE tunnels that + request link protection from the ingress. No signaling extensions + are required to support link protection for RSVP-TE tunnels over the + shared MPLS forwarding plane. + + At each LSR, link-protected TE link labels can be allocated for each + TE link, and a link-protecting facility backup LSP can be created to + protect the TE link. The link-protected TE link label can be sent by + the LSR for LSPs requesting link protection over the specific TE + link. Since the facility backup terminates at the next hop (merge + point), the incoming label on the packet will be what the merge point + expects. + + + + + +Sitaraman, et al. Standards Track [Page 14] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + + Consider the network shown in Figure 7. LSR B can install a facility + backup LSP for the link-protected TE link label 151. When the TE + link B-C is up, LSR B will pop 151 and send the packet to C. If the + TE link B-C is down, the LSR can pop 151 and send the packet via the + facility backup to C. + + 101(*) 151(*) 201(*) 251(*) + +---+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 +---+ + + Notation: (*) denotes link-protected TE link labels + + Figure 7: Link Protection Topology + +9. Protocol Extensions + +9.1. Requirements + + The functionality discussed in this document imposes the following + requirements on the signaling protocol. + + o The ingress of the LSP needs to have the ability to mandate/ + request the use and recording of TE link labels at all hops along + the path of the LSP. + + o When the use of TE link labels is mandated/requested for the path: + + * the node recording the TE link label needs to have the ability + to indicate whether the recorded label is a TE link label. + + * the ingress needs to have the ability to delegate label stack + imposition by: + + + explicitly mandating specific hops to be delegation hops, or + + + requesting automatic delegation. + + + + + + + + +Sitaraman, et al. Standards Track [Page 15] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + + * When explicit delegation is mandated or automatic delegation is + requested: + + + the ingress needs to have the ability to indicate the chosen + stacking approach, and + + + the delegation hop needs to have the ability to indicate + that the recorded label is a delegation label. + +9.2. Attribute Flags TLV: TE Link Label + + Bit Number 16: TE Link Label + + The presence of this flag in the LSP_ATTRIBUTES/ + LSP_REQUIRED_ATTRIBUTES object [RFC5420] of a Path message indicates + that the ingress has requested/mandated the use and recording of TE + link labels at all hops along the path of this LSP. When a node that + recognizes this flag but does not cater to the mandate because of + local policy receives a Path message carrying the + LSP_REQUIRED_ATTRIBUTES object with this flag set, it MUST send a + PathErr message with an error code of 'Routing Problem (24)' and an + error value of 'TE link label usage failure (70)'. A transit hop + that caters to this request/mandate MUST also check for the presence + of other Attribute Flags introduced in this document (Sections 9.4 + and 9.6) and process them as specified. An ingress LER that sets + this bit MUST also set the "label recording desired" flag [RFC3209] + in the SESSION_ATTRIBUTE object. + +9.3. RRO Label Sub-object Flag: TE Link Label + + Flag (0x02): TE Link Label + + The presence of this flag indicates that the recorded label is a TE + link label. This flag MUST be used by a node only if the use and + recording of TE link labels are requested/mandated for the LSP. + +9.4. Attribute Flags TLV: LSI-D + + Bit Number 17: Label Stack Imposition - Delegation (LSI-D) + + Automatic Delegation: The presence of this flag in the LSP_ATTRIBUTES + object of a Path message indicates that the ingress has requested + automatic delegation of label stack imposition. This flag MUST be + set in the LSP_ATTRIBUTES object of a Path message only if the use + and recording of TE link labels are requested/mandated for this LSP. + If the transit hop does not support this flag, it MUST NOT use TE + link labels and use regular labels instead. If the use of TE link + + + + +Sitaraman, et al. Standards Track [Page 16] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + + labels was mandated in the LSP_REQUIRED_ATTRIBUTES object, it MUST + send a PathErr message with an error code of 'Routing Problem (24)' + and an error value of 'TE link label usage failure (70)'. + + Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES + sub-object [RFC7570] of an Explicit Route Object (ERO) in the Path + message indicates that the hop identified by the preceding IPv4 or + IPv6 or Unnumbered Interface ID sub-object has been picked as an + explicit delegation hop. The HOP_ATTRIBUTES sub-object carrying this + flag MUST have the R (Required) bit set. This flag MUST be set in + the HOP_ATTRIBUTES sub-object of an ERO object in the Path message + only if the use and recording of TE link labels are requested/ + mandated for this LSP. If the hop recognizes this flag but is not + able to comply with this mandate because of local policy, it MUST + send a PathErr message with an error code of 'Routing Problem (24)' + and an error value of 'Label stack imposition failure (71)'. + +9.5. RRO Label Sub-object Flag: Delegation Label + + Flag (0x04): Delegation Label + + The presence of this flag indicates that the recorded label is a + delegation label. This flag MUST be used by a node only if the use + and recording of TE link labels and delegation are requested/mandated + for the LSP. + +9.6. Attributes Flags TLV: LSI-D-S2E + + Bit Number 18: Label Stack Imposition - Delegation - Stack to Reach + Egress (LSI-D-S2E) + + The presence of this flag in the LSP_ATTRIBUTES object of a Path + message indicates that the ingress has chosen to use the "Stack to + reach egress" approach for stacking. The absence of this flag in the + LSP_ATTRIBUTES object of a Path message indicates that the ingress + has chosen to use the "Stack to reach delegation hop" approach for + stacking. This flag MUST be set in the LSP_ATTRIBUTES object of a + Path message only if the use and recording of TE link labels and + delegation are requested/mandated for this LSP. If the transit hop + is not able to support the "Stack to reach egress" approach, it MUST + send a PathErr message with an error code of 'Routing Problem (24)' + and an error value of 'Label stack imposition failure (71)'. + + + + + + + + + +Sitaraman, et al. Standards Track [Page 17] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +9.7. Attributes TLV: ETLD + + The format of the ETLD Attributes TLV is shown in Figure 8. The + Attribute TLV Type is 6. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | ETLD | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: The ETLD Attributes TLV + + The presence of this TLV in the HOP_ATTRIBUTES sub-object of an RRO + object in the Path message indicates that the hop identified by the + preceding IPv4 or IPv6 or Unnumbered Interface ID sub-object supports + automatic delegation. This attribute MUST be used only if the use + and recording of TE link labels are requested/mandated and automatic + delegation is requested for the LSP. + + The ETLD field specifies the effective number of transport labels + that this hop (in relation to its position in the path) can + potentially send to its downstream hop. It MUST be set to a non-zero + value. + + The Reserved field is for future specification. It SHOULD be set to + zero on transmission and MUST be ignored on receipt to ensure future + compatibility. + +10. OAM Considerations + + MPLS LSP ping and traceroute [RFC8029] are applicable for Segment + Routed RSVP-TE tunnels. The existing procedures allow for the label + stack imposed at a delegation hop to be reported back in the Label + Stack Sub-TLV in the MPLS echo reply for traceroute. + + + + + + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 18] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +11. IANA Considerations + +11.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E + + IANA manages the 'Attribute Flags' subregistry as part of the + 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) + Parameters' registry located at <http://www.iana.org/assignments/ + rsvp-te-parameters>. This document introduces three new Attribute + Flags: + + Bit Name Attribute Attribute RRO ERO Reference + No Flags Path Flags Resv + + 16 TE Link Label Yes No No No [RFC8577], + Section 9.2 + + 17 LSI-D Yes No No Yes [RFC8577], + Section 9.4 + + 18 LSI-D-S2E Yes No No No [RFC8577], + Section 9.6 + +11.2. Attribute TLV: ETLD + + IANA manages the "Attribute TLV Space" registry as part of the + 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) + Parameters' registry located at <http://www.iana.org/assignments/ + rsvp-te-parameters>. This document introduces a new Attribute TLV. + + Type Name Allowed on Allowed on Allowed on Reference + LSP_ATTRIBUTES LSP_REQUIRED LSP Hop + _ATTRIBUTES Attributes + + 6 ETLD No No Yes [RFC8577], + Section 9.7 + + + + + + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 19] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +11.3. Record Route Label Sub-object Flags: TE Link Label, Delegation + Label + + IANA manages the "Record Route Object Sub-object Flags" registry as + part of the "Resource Reservation Protocol-Traffic Engineering (RSVP- + TE) Parameters" registry located at <http://www.iana.org/assignments/ + rsvp-te-parameters>. Prior to this document, this registry did not + include Label Sub-object Flags. This document creates the addition + of a new subregistry for Label Sub-object Flags as shown below. + + Flag Name Reference + + 0x1 Global Label [RFC3209] + 0x02 TE Link Label [RFC8577], Section 9.3 + 0x04 Delegation Label [RFC8577], Section 9.5 + + +11.4. Error Codes and Error Values + + IANA maintains a registry called "Resource Reservation Protocol + (RSVP) Parameters" with a subregistry called "Error Codes and + Globally-Defined Error Value Sub-Codes". Within this subregistry is + a definition of the "Routing Problem" Error Code (24). The + definition lists a number of error values that may be used with this + error code. IANA has allocated further error values for use with + this Error Code as described in this document. The resulting entry + in the registry is as follows. + + 24 Routing Problem [RFC3209] + + This Error Code has the following globally defined Error + Value sub-codes: + + 70 = TE link label usage failure [RFC8577] + 71 = Label stack imposition failure [RFC8577] + +12. Security Considerations + + This document does not introduce new security issues. The security + considerations pertaining to the original RSVP protocol [RFC2205] and + RSVP-TE [RFC3209] and those that are described in [RFC5920] remain + relevant. + + + + + + + + + +Sitaraman, et al. Standards Track [Page 20] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and + S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version + 1 Functional Specification", RFC 2205, + DOI 10.17487/RFC2205, September 1997, + <https://www.rfc-editor.org/info/rfc2205>. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, + DOI 10.17487/RFC3031, January 2001, + <https://www.rfc-editor.org/info/rfc3031>. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + <https://www.rfc-editor.org/info/rfc3209>. + + [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast + Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + DOI 10.17487/RFC4090, May 2005, + <https://www.rfc-editor.org/info/rfc4090>. + + [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and + A. Ayyangarps, "Encoding of Attributes for MPLS LSP + Establishment Using Resource Reservation Protocol Traffic + Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, + February 2009, <https://www.rfc-editor.org/info/rfc5420>. + + [RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and + B. Wright, "Label Switched Path (LSP) Attribute in the + Explicit Route Object (ERO)", RFC 7570, + DOI 10.17487/RFC7570, July 2015, + <https://www.rfc-editor.org/info/rfc7570>. + + [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., + Aldrin, S., and M. Chen, "Detecting Multiprotocol Label + Switched (MPLS) Data-Plane Failures", RFC 8029, + DOI 10.17487/RFC8029, March 2017, + <https://www.rfc-editor.org/info/rfc8029>. + + + + +Sitaraman, et al. Standards Track [Page 21] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +13.2. Informative References + + [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., + and S. Molendini, "RSVP Refresh Overhead Reduction + Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, + <https://www.rfc-editor.org/info/rfc2961>. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + <https://www.rfc-editor.org/info/rfc5920>. + + [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and + T. Saad, "Techniques to Improve the Scalability of RSVP-TE + Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, + <https://www.rfc-editor.org/info/rfc8370>. + + [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, + July 2018, <https://www.rfc-editor.org/info/rfc8402>. + + [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, + "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, + DOI 10.17487/RFC8491, November 2018, + <https://www.rfc-editor.org/info/rfc8491>. + + [SEG-ROUTING] + Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing with MPLS data plane", Work in Progress, + draft-ietf-spring-segment-routing-mpls-18, December 2018. + + + + + + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 22] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +Acknowledgements + + The authors would like to thank Adrian Farrel, Kireeti Kompella, + Markus Jork, and Ross Callon for their input from discussions. + Adrian Farrel provided a review and a text suggestion for clarity and + readability. + +Contributors + + The following individuals contributed to this document: + + Raveendra Torvi + Juniper Networks + Email: rtorvi@juniper.net + + Chandra Ramachandran + Juniper Networks + Email: csekar@juniper.net + + George Swallow + Email: swallow.ietf@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 23] + +RFC 8577 RSVP-TE Shared Labels April 2019 + + +Authors' Addresses + + Harish Sitaraman + Juniper Networks + 1133 Innovation Way + Sunnyvale, CA 94089 + United States of America + + Email: harish.ietf@gmail.com + + + Vishnu Pavan Beeram + Juniper Networks + 10 Technology Park Drive + Westford, MA 01886 + United States of America + + Email: vbeeram@juniper.net + + + Tejal Parikh + Verizon + 400 International Parkway + Richardson, TX 75081 + United States of America + + Email: tejal.parikh@verizon.com + + + Tarek Saad + Cisco Systems + 2000 Innovation Drive + Kanata, Ontario K2K 3E8 + Canada + + Email: tsaad.net@gmail.com + + + + + + + + + + + + + + + +Sitaraman, et al. Standards Track [Page 24] + |