idnits 2.17.1 draft-sitaraman-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 (September 6, 2017) is 2395 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 (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-09) exists of draft-ietf-teas-rsvp-te-scaling-rec-06 == Outdated reference: A later version (-04) exists of draft-ietf-teas-sr-rsvp-coexistence-rec-01 Summary: 0 errors (**), 0 flaws (~~), 5 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: March 10, 2018 T. Parikh 6 Verizon 7 T. Saad 8 Cisco Systems 9 September 6, 2017 11 Signaling RSVP-TE tunnels on a shared MPLS forwarding plane 12 draft-sitaraman-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 'pop labels' that 33 are applied per Traffic Engineering link and that can be shared by 34 MPLS RSVP-TE LSPs that traverse these links. This approach 35 significantly reduces the forwarding plane state required to support 36 a large number of LSPs. This couples the feature benefits of the 37 RSVP-TE control plane with the simplicity of the Segment Routing MPLS 38 forwarding plane. 40 This document also introduces the ability to mix different types of 41 label operations along the path of an LSP, thereby allowing the 42 ingress router or an external controller to influence how to 43 optimally place a LSP in the network. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC2119]. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on March 10, 2018. 68 Copyright Notice 70 Copyright (c) 2017 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 3. Allocation of Pop Labels . . . . . . . . . . . . . . . . . . 5 88 4. RSVP-TE Pop and Forward Tunnel Setup . . . . . . . . . . . . 5 89 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 7 90 5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8 91 5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 8 92 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) . . . . 10 97 6. Mixing Pop and Swap Labels in an RSVP-TE Tunnel . . . . . . . 11 98 7. Construction of Label Stacks . . . . . . . . . . . . . . . . 12 99 8. Facility Backup Protection . . . . . . . . . . . . . . . . . 13 100 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13 101 8.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 14 102 9. Quantifying Pop Labels . . . . . . . . . . . . . . . . . . . 14 103 10. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 14 104 10.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 14 105 10.2. Attribute Flags TLV: Pop Label . . . . . . . . . . . . . 15 106 10.3. RRO Label Subobject Flag: Pop Label . . . . . . . . . . 15 107 10.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 15 108 10.5. RRO Label Subobject Flag: Delegation Label . . . . . . . 16 109 10.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . 16 110 10.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 16 111 11. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 17 112 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 113 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 114 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 115 14.1. Attribute Flags: Pop Label, LSI-D, LSI-D-S2E . . . . . . 18 116 14.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 18 117 14.3. Record Route Label Sub-object Flags: Pop Label, 118 Delegation Label . . . . . . . . . . . . . . . . . . . . 18 119 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 120 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 121 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 122 16.2. Informative References . . . . . . . . . . . . . . . . . 20 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 'pop labels' that 141 are allocated by an LSR for each of its Traffic Engineering (TE) 142 links. Each such label is installed in the MPLS forwarding plane 143 with a 'pop' operation and the instruction to forward the received 144 packet over the TE link. An LSR advertises this label in the Label 145 object of a Resv message as LSPs are set up and they are recorded hop 146 by hop in the Record Route object (RRO) of the Resv message as it 147 traverses the network. To make use of this feature, the ingress 148 Label Edge Router (LER) pushes a stack of labels [RFC3031] as 149 received in the RRO. These 'pop labels' can be shared by MPLS RSVP- 150 TE LSPs that traverse the same TE link. 152 This pop and forward data plane behavior is similar to that used by 153 Segment Routing (SR) [I-D.ietf-spring-segment-routing] using a MPLS 154 forwarding plane and a series of adjacency segments. This couples 155 the feature benefits of the RSVP-TE control plane with the simplicity 156 of the Segment Routing MPLS forwarding plane. The RSVP-TE pop and 157 forward tunnels can co-exist with MPLS-SR LSPs 158 [I-D.ietf-spring-segment-routing-mpls] as described in 159 [I-D.ietf-teas-sr-rsvp-coexistence-rec]. 161 RSVP-TE using a pop and forward data plane offers the following 162 benefits: 164 1. Shared forwarding plane: The transit label on a TE link is shared 165 among RSVP-TE tunnels traversing the link and is used independent 166 of the ingress and egress of the LSPs. 168 2. Faster LSP setup time: No forwarding plane state needs to be 169 programmed during LSP setup and teardown resulting in faster time 170 for provisioning and deprovisioning LSPs. 172 3. Hitless re-routing: New transit labels are not required during 173 make-before-break (MBB) in scenarios where the new LSP instance 174 traverses the exact same path as the old LSP instance. This 175 saves the ingress LER and the services that use the tunnel from 176 needing to update the forwarding plane with new tunnel labels and 177 so makes MBB events faster. Periodic MBB events are relatively 178 common in networks that deploy the 'auto-bandwidth' feature on 179 RSVP-TE LSPs to monitor bandwidth utilization and periodically 180 adjust LSP bandwidth. 182 4. Mix and match labels: Both 'pop' and 'swap' labels can be used on 183 transit hops for a single RSVP-TE tunnel (see Section 6). This 184 allows backward compatibility with transit LSRs that provide 185 'swap' labels in Resv messages. 187 No additional extensions are required to routing protocols (IGP-TE) 188 in order to support this pop and forward data plane. Functionalities 189 such as bandwidth admission control, LSP priorities, preemption, 190 auto-bandwidth and Fast Reroute continue to work with this forwarding 191 plane. 193 2. Terminology 195 The following terms are defined for use in this document: 197 Pop label: An incoming label at an LSR that will be popped by the 198 LSR with the packet being forwarded over a specific outgoing TE 199 link to a neighbor. 201 Swap label: An incoming label at a LSR that will be swapped to an 202 outgoing label with the packet being forwarded over a specific 203 outgoing TE link to a neighbor. 205 RSVP-TE pop and forward tunnel: An MPLS RSVP-TE tunnel that uses a 206 pop and forward labels on every hop of the LSP. 208 Pop and forward data plane: A forwarding plane where every LSR uses 209 pop labels on every LSP. 211 3. Allocation of Pop Labels 213 An LSR SHOULD allocate a unique pop label for each TE link. When an 214 LSR encounters a pop label at the top of the label stack it MUST pop 215 the label and forward the packet over the TE link to the downstream 216 neighbor on the RSVP-TE tunnel. 218 Multiple labels MAY be allocated for the TE link to accommodate 219 tunnels requesting no protection, link-protection and node-protection 220 over the specific TE link. 222 4. RSVP-TE Pop and Forward Tunnel Setup 224 This section provides an example of how the RSVP-TE signaling 225 procedure works to set up a tunnel utilizing a pop and forward data 226 plane. The sample topology below is used to explain the example. 227 Labels shown at each node are pop labels that, when present at the 228 top of the label stack, indicate that they should be popped and that 229 the packet should be forwarded on the TE link to the neighbor. 231 +---+100 +---+150 +---+200 +---+250 +---+ 232 | A |-----| B |-----| C |-----| D |-----| E | 233 +---+ +---+ +---+ +---+ +---+ 234 |110 |450 |550 |650 |850 235 | | | | | 236 | |400 |500 |600 |800 237 | +---+ +---+ +---+ +---+ 238 +-------| F |-----|G |-----|H |-----|I | 239 +---+300 +---+350 +---+700 +---+ 241 Figure 1: Pop and Forward Label Topology 243 Consider two tunnels: 245 RSVP-TE tunnel T1: From A to E on path A-B-C-D-E 247 RSVP-TE tunnel T2: From F to E on path F-B-C-D-E 249 Both tunnels share the TE links B-C, C-D, and D-E. 251 RSVP-TE is used to signal the setup of tunnel T1 (using the pop label 252 attributes flag defined in Section 10.2). When LSR D receives the 253 Resv message from the egress LER E, it checks the next-hop TE link 254 (D-E) and provides the pop label (250) in the Resv message for the 255 tunnel placing the label value in the Label object and also in the 256 Label subobject carried in the RRO and setting the pop label flag as 257 defined in Section 10.3. 259 Similarly, LSR C provides the pop label (200) for the TE link C-D, 260 and LSR B provides the pop label (150) for the TE link B-C. 262 For tunnel T2, the transit LSRs provide the same pop labels as 263 described for tunnel T1 as the links B-C, C-D, and D-E are common 264 between the two LSPs. 266 The ingress LERs (A and F) will push the same stack of labels (from 267 top of stack to bottom of stack) {150, 200, 250} for tunnels T1 and 268 T2 respectively. 270 It should be noted that a transit LSR does not swap the top pop label 271 on an incoming packet (the label that it advertised in the Resv 272 message it sent). All it has to do is pop the top label and forward 273 the packet. 275 The values in the Label subobjects in the RRO are of interest to the 276 ingress LERs in order to construct the stack of labels to impose on 277 the packets. 279 If, in this example, there was another RSVP-TE tunnel T3 from F to I 280 on path F-B-C-D-E-I, then this would also share the TE links B-C, 281 C-D, and D-E and additionally traverse link E-I. The label stack 282 used by F would be {150, 200, 250, 850}. Hence, regardless of the 283 ingress and egress LERs from where the LSPs start and end, they will 284 share LSR labels at shared hops in the pop and forward data plane. 286 There MAY be local operator policy at the ingress LER that influences 287 the maximum depth of the label stack that can be pushed for an RSVP- 288 TE pop and forward tunnel. Prior to signaling the LSP, the ingress 289 LER may decide that it would be unable to push a label stack 290 containing one label for each hop along the path. In this case the 291 LER can choose either to not signal an RSVP-TE pop and forward tunnel 292 (using normal LSP signaling instead), or can adopt the techniques 293 described in Section 5 or Section 6. 295 5. Delegating Label Stack Imposition 297 One or more transit LSRs can assist the ingress LER by imposing part 298 of the label stack required for the path. Consider the example in 299 Figure 2 with an RSVP-TE tunnel from A to L on path 300 A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A 301 to impose the full label stack, so it uses the assistance of 302 delegation hops LSR D and LSR I to impose parts of the label stack. 304 Each delegation hop allocates a delegation label to represent a set 305 of labels that will be pushed at this hop. When a packet arrives at 306 a delegation hop LSR with a delegation label, the LSR pops the label 307 and pushes a set of labels before forwarding the packet. 309 1250d 310 +---+100p +---+150p +---+200p +---+250p +---+300p +---+ 311 | A |------| B |------| C |------| D |------| E |------| F | 312 +---+ +---+ +---+ +---+ +---+ +---+ 313 |350p 314 | 315 1500d | 316 +---+ 600p+---+ 550p+---+ 500p+---+ 450p+---+ 400p+---+ 317 | L |------| K |------| J |------| I |------| H |------+ G + 318 +---+ +---+ +---+ +---+ +---+ +---+ 320 Notation :