idnits 2.17.1 draft-ietf-mpls-rsvp-shared-labels-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group H. Sitaraman 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: December 30, 2018 T. Parikh 6 Verizon 7 T. Saad 8 Cisco Systems 9 June 28, 2018 11 Signaling RSVP-TE tunnels on a shared MPLS forwarding plane 12 draft-ietf-mpls-rsvp-shared-labels-02.txt 14 Abstract 16 As the scale of MPLS RSVP-TE networks has grown, so the number of 17 Label Switched Paths (LSPs) supported by individual network elements 18 has increased. Various implementation recommendations have been 19 proposed to manage the resulting increase in control plane state. 21 However, those changes have had no effect on the number of labels 22 that a transit Label Switching Router (LSR) has to support in the 23 forwarding plane. That number is governed by the number of LSPs 24 transiting or terminated at the LSR and is directly related to the 25 total LSP state in the control plane. 27 This document defines a mechanism to prevent the maximum size of the 28 label space limit on an LSR from being a constraint to control plane 29 scaling on that node. That is, it allows many more LSPs to be 30 supported than there are forwarding plane labels available. 32 This work introduces the notion of pre-installed 'per Traffic 33 Engineering (TE) link labels' that can be shared by MPLS RSVP-TE LSPs 34 that traverse these TE links. This approach significantly reduces 35 the forwarding plane state required to support a large number of 36 LSPs. This couples the feature benefits of the RSVP-TE control plane 37 with the simplicity of the Segment Routing MPLS forwarding plane. 39 This document also introduces the ability to mix different types of 40 label operations along the path of an LSP, thereby allowing the 41 ingress router or an external controller to influence how to 42 optimally place a LSP in the network. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 48 "OPTIONAL" in this document are to be interpreted as described in BCP 49 14 [RFC2119] [RFC8174] when, and only when, they appear in all 50 capitals, as shown here. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on December 30, 2018. 69 Copyright Notice 71 Copyright (c) 2018 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 5 89 4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 5 90 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 7 91 5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8 92 5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 8 93 5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 9 94 5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 10 95 5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 10 96 5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 11 98 6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 12 99 7. Construction of Label Stacks . . . . . . . . . . . . . . . . 13 100 8. Facility Backup Protection . . . . . . . . . . . . . . . . . 14 101 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 14 102 9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 15 103 9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 15 104 9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 16 105 9.3. RRO Label Subobject Flag: TE Link Label . . . . . . . . . 16 106 9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 16 107 9.5. RRO Label Subobject Flag: Delegation Label . . . . . . . 17 108 9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 17 109 9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 17 110 10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 18 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 112 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 113 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 114 13.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 18 115 13.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 19 116 13.3. Record Route Label Sub-object Flags: TE Link Label, 117 Delegation Label . . . . . . . . . . . . . . . . . . . . 19 118 13.4. Error Codes and Error Values . . . . . . . . . . . . . . 20 119 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 120 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 121 15.1. Normative References . . . . . . . . . . . . . . . . . . 20 122 15.2. Informative References . . . . . . . . . . . . . . . . . 21 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 125 1. Introduction 127 The scaling of RSVP-TE [RFC3209] control plane implementations can be 128 improved by adopting the guidelines and mechanisms described in 129 [RFC2961] and [I-D.ietf-teas-rsvp-te-scaling-rec]. These documents 130 do not make any difference to the forwarding plane state required to 131 handle the control plane state. The forwarding plane state remains 132 unchanged and is directly proportional to the total number of Label 133 Switching Paths (LSPs) supported by the control plane. 135 This document describes a mechanism that prevents the size of the 136 platform specific label space on a Label Switching Router (LSR) from 137 being a constraint to pushing the limits of control plane scaling on 138 that node. 140 This work introduces the notion of pre-installed 'per Traffic 141 Engineering (TE) link labels' that are allocated by an LSR. Each 142 such label is installed in the MPLS forwarding plane with a 'pop' 143 operation and the instruction to forward the received packet over the 144 TE link. An LSR advertises this label in the Label object of a Resv 145 message as LSPs are set up and they are recorded hop by hop in the 146 Record Route object (RRO) of the Resv message as it traverses the 147 network. To make use of this feature, the ingress Label Edge Router 148 (LER) pushes a stack of labels [RFC3031] as received in the RRO. 149 These 'TE link labels' can be shared by MPLS RSVP-TE LSPs that 150 traverse the same TE link. 152 This forwarding plane behavior fits in the MPLS architecture 153 [RFC3031] and is same as that exhibited by Segment Routing (SR) 154 [I-D.ietf-spring-segment-routing] when using an MPLS forwarding plane 155 and a series of adjacency segments. This work couples the feature 156 benefits of the RSVP-TE control plane with the simplicity of the 157 Segment Routing MPLS forwarding plane. The RSVP-TE tunnels that use 158 this shared forwarding plane can co-exist with MPLS-SR LSPs 159 [I-D.ietf-spring-segment-routing-mpls] as described in 160 [I-D.ietf-teas-sr-rsvp-coexistence-rec]. 162 RSVP-TE using a shared MPLS forwarding plane offers the following 163 benefits: 165 1. Shared Labels: The transit label on a TE link is shared among 166 RSVP-TE tunnels traversing the link and is used independent of 167 the ingress and egress of the LSPs. 169 2. Faster LSP setup time: No forwarding plane state needs to be 170 programmed during LSP setup and teardown resulting in faster time 171 for provisioning and deprovisioning LSPs. 173 3. Hitless re-routing: New transit labels are not required during 174 make-before-break (MBB) in scenarios where the new LSP instance 175 traverses the exact same path as the old LSP instance. This 176 saves the ingress LER and the services that use the tunnel from 177 needing to update the forwarding plane with new tunnel labels and 178 so makes MBB events faster. Periodic MBB events are relatively 179 common in networks that deploy the 'auto-bandwidth' feature on 180 RSVP-TE LSPs to monitor bandwidth utilization and periodically 181 adjust LSP bandwidth. 183 4. Mix and match labels: Both 'TE link labels' and regular labels 184 can be used on transit hops for a single RSVP-TE tunnel (see 185 Section 6). This allows backward compatibility with transit LSRs 186 that provide regular labels in Resv messages. 188 No additional extensions are required to routing protocols (IGP-TE) 189 in order to support this shared MPLS forwarding plane. 190 Functionalities such as bandwidth admission control, LSP priorities, 191 preemption, auto-bandwidth and Fast Reroute continue to work with 192 this forwarding plane. 194 The signaling procedures and extensions discussed in this document do 195 not apply to Point to Multipoint (P2MP) RSVP-TE Tunnels. 197 2. Terminology 199 The following terms are used in this document: 201 TE link label: An incoming label at an LSR that will be popped by 202 the LSR with the packet being forwarded over a specific outgoing 203 TE link to a neighbor. 205 Shared MPLS forwarding plane: An MPLS forwarding plane where every 206 participating LSR uses TE link labels on every LSP. 208 Segment Routed RSVP-TE tunnel: An MPLS RSVP-TE tunnel that requests 209 the use of a shared MPLS forwarding plane at every hop of the LSP. 210 The corresponding LSPs are referred to as Segment Routed RSVP-TE 211 LSPs. 213 Delegation hop: A transit hop of a Segment Routed RSVP-TE LSP that 214 is selected to assist in the imposition of the label stack in 215 scenarios where the ingress LER cannot impose the full label 216 stack. There could be multiple delegation hops along the path of 217 a Segment Routed RSVP-TE LSP. 219 Delegation label: A label assigned at the delegation hop to 220 represent a set of labels that will be pushed at this hop. 222 3. Allocation of TE Link Labels 224 An LSR that participates in a shared MPLS forwarding plane MUST 225 allocate a unique TE link label for each TE link. When an LSR 226 encounters a TE link label at the top of the label stack it MUST pop 227 the label and forward the packet over the TE link to the downstream 228 neighbor on the RSVP-TE tunnel. 230 Multiple TE link labels MAY be allocated for the TE link to 231 accommodate tunnels requesting protection. 233 Implementations that maintain per label bandwidth accounting at each 234 hop must aggregate the reservations made for all the LSPs using the 235 shared TE link label. 237 4. Segment Routed RSVP-TE Tunnel Setup 239 This section provides an example of how the RSVP-TE signaling 240 procedure works to set up a tunnel utilizing a shared MPLS forwarding 241 plane. The sample topology below is used to explain the example. 243 Labels shown at each node are TE link labels that, when present at 244 the top of the label stack, indicate that they should be popped and 245 that the packet should be forwarded on the TE link to the neighbor. 247 +---+100 +---+150 +---+200 +---+250 +---+ 248 | A |-----| B |-----| C |-----| D |-----| E | 249 +---+ +---+ +---+ +---+ +---+ 250 |110 |450 |550 |650 |850 251 | | | | | 252 | |400 |500 |600 |800 253 | +---+ +---+ +---+ +---+ 254 +-------| F |-----|G |-----|H |-----|I | 255 +---+300 +---+350 +---+700 +---+ 257 Figure 1: Sample Topology - TE Link Labels 259 Consider two tunnels: 261 RSVP-TE tunnel T1: From A to E on path A-B-C-D-E 263 RSVP-TE tunnel T2: From F to E on path F-B-C-D-E 265 Both tunnels share the TE links B-C, C-D, and D-E. 267 RSVP-TE is used to signal the setup of tunnel T1 (using the TE link 268 label attributes flag defined in Section 9.2). When LSR D receives 269 the Resv message from the egress LER E, it checks the next-hop TE 270 link (D-E) and provides the TE link label (250) in the Resv message 271 for the tunnel placing the label value in the Label object and also 272 in the Label subobject carried in the RRO and setting the TE link 273 label flag as defined in Section 9.3. 275 Similarly, LSR C provides the TE link label (200) for the TE link 276 C-D, and LSR B provides the TE link label (150) for the TE link B-C. 278 For tunnel T2, the transit LSRs provide the same TE link labels as 279 described for tunnel T1 as the links B-C, C-D, and D-E are common 280 between the two LSPs. 282 The ingress LERs (A and F) will push the same stack of labels (from 283 top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and 284 T2 respectively. 286 It should be noted that a transit LSR does not swap the top TE link 287 label on an incoming packet (the label that it advertised in the Resv 288 message it sent). All it has to do is pop the top label and forward 289 the packet. 291 The values in the Label subobjects in the RRO are of interest to the 292 ingress LERs in order to construct the stack of labels to impose on 293 the packets. 295 If, in this example, there was another RSVP-TE tunnel T3 from F to I 296 on path F-B-C-D-E-I, then this would also share the TE links B-C, 297 C-D, and D-E and additionally traverse link E-I. The label stack 298 used by F would be {150, 200, 250, 850}. Hence, regardless of the 299 ingress and egress LERs from where the LSPs start and end, they will 300 share LSR labels at shared hops in the shared MPLS forwarding plane. 302 There MAY be local operator policy at the ingress LER that influences 303 the maximum depth of the label stack that can be pushed for a Segment 304 Routed RSVP-TE tunnel. Prior to signaling the LSP, the ingress LER 305 may decide that it would be unable to push a label stack containing 306 one label for each hop along the path. In this case the LER can 307 choose either to not signal a Segment Routed RSVP-TE tunnel (using 308 normal LSP signaling instead), or can adopt the techniques described 309 in Section 5 or Section 6. 311 5. Delegating Label Stack Imposition 313 One or more transit LSRs can assist the ingress LER by imposing part 314 of the label stack required for the path. Consider the example in 315 Figure 2 with an RSVP-TE tunnel from A to L on path 316 A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A 317 to impose the full label stack, so it uses the assistance of 318 delegation hops LSR D and LSR I to impose parts of the label stack. 320 Each delegation hop allocates a delegation label to represent a set 321 of labels that will be pushed at this hop. When a packet arrives at 322 a delegation hop LSR with a delegation label, the LSR pops the label 323 and pushes a set of labels before forwarding the packet. 325 1250d 326 +---+100p +---+150p +---+200p +---+250p +---+300p +---+ 327 | A |------| B |------| C |------| D |------| E |------| F | 328 +---+ +---+ +---+ +---+ +---+ +---+ 329 |350p 330 | 331 1500d | 332 +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ 333 | L |------| K |------| J |------| I |------| H |------+ G + 334 +---+ +---+ +---+ +---+ +---+ +---+ 336 Notation :