idnits 2.17.1 draft-ietf-teas-rsvp-rmr-extension-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2018) is 2131 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) == Missing Reference: 'RFC 3209' is mentioned on line 360, but not defined == Unused Reference: 'I-D.ietf-mpls-rmr' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'I-D.dai-mpls-rsvp-te-mbb-label-reuse' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 610, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-07 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS WG A. Deshmukh 3 Internet-Draft K. Kompella 4 Intended status: Standards Track Juniper Networks, Inc. 5 Expires: December 21, 2018 June 19, 2018 7 RSVP Extensions for RMR 8 draft-ietf-teas-rsvp-rmr-extension-00 10 Abstract 12 Rings are the most common topology in access and aggregation 13 networks. However, the use of MPLS as the transport protocol for 14 rings is very limited today. draft-ietf-mpls-rmr-02 describes a 15 mechanism to handle rings efficiently using MPLS. This document 16 describes the extensions to the RSVP protocol for signaling MPLS 17 label switched paths in rings. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 21, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Session Object . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects . . . . . . . . . . . 5 64 4. Ring Signaling Procedures . . . . . . . . . . . . . . . . . . 5 65 4.1. Differences from regular RSVP-TE LSPs . . . . . . . . . . 5 66 4.2. LSP signaling . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2.1. Path Propagation for RMR . . . . . . . . . . . . . . 7 68 4.2.2. Resv Processing for RMR . . . . . . . . . . . . . . . 8 69 4.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Ring changes . . . . . . . . . . . . . . . . . . . . . . 10 71 4.5. Bandwidth management . . . . . . . . . . . . . . . . . . 11 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 This document extends RSVP-TE [RFC3209] to establish label-switched 83 path (LSP) tunnels in the ring topology. Rings are auto-discovered 84 using the mechanisms mentioned in the [draft-ietf-mpls-rmr-02]. 85 Either IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for 86 auto-discovering the rings. 88 After the rings are auto-discovered, each ring node knows its 89 clockwise (CW) and anti-clockwise (AC) ring neighbors and its ring 90 links. All of the express links in the ring also get identified as 91 part of the auto-discovery process. At this point, every node in the 92 ring informs the RSVP protocol to begin the signaling of the ring 93 LSPs. 95 Section 2 covers the terminology used in this document. Section 3 96 presents the RSVP protocol extensions needed to support MPLS rings. 97 Section 4 describes the procedures of RSVP LSP signaling in detail. 99 2. Terminology 101 A ring consists of a subset of n nodes {R_i, 0 <= i < n}. We define 102 the direction from node R_i to R_i+1 as "clockwise" (CW) and the 103 reverse direction as "anti-clockwise" (AC). As there may be several 104 rings in a graph, we number each ring with a distinct ring ID RID. 106 R0 . . . R1 107 . . 108 R7 R2 109 Anti- | . Ring . | 110 Clockwise | . . | Clockwise 111 v . RID = 17 . v 112 R6 R3 113 . . 114 R5 . . . R4 116 Figure 1: Ring with 8 nodes 118 The following terminology is used for ring LSPs: 120 Ring ID (RID): A non-zero number that identifies a ring; this is 121 unique in some scope of a Service Provider's network. A node may 122 belong to multiple rings. 124 Ring node: A member of a ring. Note that a device may belong to 125 several rings. 127 Node index: A logical numbering of nodes in a ring, from zero upto 128 one less than the ring size. Used purely for exposition in this 129 document. 131 Ring neighbors: Nodes whose indices differ by one (modulo ring 132 size). 134 Ring links: Links that connect ring neighbors. 136 Express links: Links that connect non-neighboring ring nodes. 138 MP2P LSP: Each LSP in the ring is a multipoint to point LSP such 139 that LSP can have multiple ingress nodes and one egress node. 141 3. RSVP Extensions 143 Due to the new ring LSP semantics, the signaling-message 144 identification of ring LSPs will be different than the regular RSVP 145 LSPs. So, a new C-Type is defined here for the SESSION object. This 146 new C-Type will help to clearly differentiate ring LSPs from regular 147 LSPs. In addition, new flags are introduced in the SESSION object to 148 represent the ring direction of the corresponding Path message. 150 3.1. Session Object 152 Class = SESSION, LSP_TUNNEL_IPv4 C-Type = TBD 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Ring anchor node address | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Ring Flags | Ring Instance ID | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Ring ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 SESSION Object 166 Ring anchor node address: IPv4 address of the anchor node. Each 167 anchor node creates a LSP addressed to itself. 169 Ring Instance ID: A 16-bit identifier used in the SESSION. This 170 Ring Instance ID is useful for graceful ring changes. If a new 171 node is being added to the ring or some existing node goes down 172 and we have to signal a smaller ring, in those cases, anchor node 173 creates a new tunnel with a different Ring Instance ID. 175 Ring ID: A 32-bit number that identifies a ring; this is unique in 176 some scope of a Service Provider's network. This number remains 177 constant throughout the existence of ring. 179 Ring Flags: For each ring, the anchor node starts signaling of a 180 ring LSP. Ring LSP RL_i, anchored on node R_i, consists of two 181 counter-rotating unicast LSPs that start and end at R_i. One LSP 182 will be in the clockwise direction and other LSP will be in the 183 anti-clockwise direction. A ring LSP is "multipoint": any node 184 R_j can use RL_i to send traffic to R_i; this can be in either the 185 CW or AC directions, or both (i.e., load balanced). Two new flags 186 are defined in the SESSION object which define the ring direction 187 of the corresponding Path message. 189 ClockWise(CW) Direction 0x01: This flag indicates that the 190 corresponding Path message is traveling in the ClockWise(CW) 191 direction along the ring. 193 Anti-ClockWise(AC) Direction 0x02: This flag indicates that the 194 corresponding Path message is traveling in the Anti-ClockWise(AC) 195 direction along the ring. 197 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects 199 There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC 200 objects. The format of the above 2 objects will be similar to the 201 definitions in RFC 3209. [RFC3209] Only the semantics of these 202 objects will slightly change. This will be explained in section 203 Section 4.5 below. 205 4. Ring Signaling Procedures 207 A ring node indicates in its IGP updates the ring LSP signaling 208 protocols that it supports. This can be LDP and/or RSVP-TE. 209 Ideally, each node should support both. If the ring is configured 210 with RSVP as the signaling protocol, then once a ring node R_i knows 211 the RID, its ring links and directions, it kicks off ring RSVP LSP 212 signaling automatically. 214 4.1. Differences from regular RSVP-TE LSPs 216 Ring LSPs differ from regular RSVP-TE LSPs in several ways: 218 1. Ring LSPs (by construction) form a loop. 220 2. Ring LSPs are multipoint-to-point. Any ring node can inject 221 traffic into a ring LSP. 223 3. The bandwidth of a ring LSP can change hop-to-hop. 225 4. Ring LSPs are protected without the use of bypass or detour LSPs. 226 Ring LSP protection is akin to SONET/SDH ring protection. 228 4.2. LSP signaling 230 After the ring auto-discovery process, each anchor node creates a LSP 231 addressed to itself. This ring LSP contains of a pair of counter- 232 rotating unicast LSPs. So, for a ring containing N nodes, there will 233 be 2N total LSPs signaled. 235 There is no need for ERO object in the Path message. The Path 236 message for ring LSPs has the following format: 238 ::= [ ] 239 240 241 242 [ ] 243 245 ::= | 246 247 ::= 249 The anchor node creates 2 Path messages traveling in opposite 250 directions. The SESSION format MUST be as per the description in 251 Section 3.1. The anchor node which creates the LSP will insert it's 252 own address in the "Ring node anchor address" field of the SESSION 253 object. So effectively, the Path messages are addressed to the 254 originating node itself. 256 The SESSION flags of these 2 Path messages are different. The Path 257 message sent to the CW neighbor MUST have the CW flag set in the 258 SESSION object to signal the LSP going in the clockwise direction. 259 The Path message sent to the AC neighbor MUST have the AC flag set to 260 signal the LSP in the anti-clockwise direction. The details for 261 signaling over express links will be given in a future version. 263 When an incoming Path message is received at the ring node R_i, it 264 consults the results of auto-discovery to find the appropriate ring 265 neighbor. If the incoming Path message has CW direction flag set, 266 then R_i sends a Path message to its CW ring neighbor (and vice 267 versa) after including its own SENDER_DESCRIPTOR in the path message. 268 Thus, there is no need of ERO in the Path message. The Path message 269 is routed locally at each ring based on the ring auto-discovery 270 calculations. 272 The RESV message for ring LSPs also uses the new RING_IPv4 SESSION 273 object. When the Path message originated from the anchor node R_i 274 reaches back to R_i, R_i generates a Resv message. Note that this 275 means that anchor node is both Ingress and Egress for the Path 276 message. The Resv message copies the same ring flags as received in 277 the corresponding Path message. So, a Resv message for a CW LSP goes 278 in the AC direction (unlike the Path message, which goes CW). This 279 is done to correctly match Path and corresponding Resv messages at 280 transit ring nodes. Upon receiving Resv message with CW flag set, 281 the ring node will forward the Resv message to its AC neighbor. 283 Each ring node R_i allocates CW and AC labels for each ring LSP RL_k. 284 As the signaling propagates around the ring, CW and AC labels are 285 exchanged. When R_i receives CW and AC labels for RL_k from its ring 286 neighbors, primary and fast reroute (FRR) paths for RL_k are 287 installed at R_i. 289 Consider the following three nodes of the ring, and their signaling 290 interactions for LSP RL_5 originating from anchor node R5: 292 P5_CW -> P5_CW -> 293 Q5_CW <- Q5_CW <- 294 ... ------ R7 --------- R8 --------- R9 ------ ... 295 P5_AC <- P5_AC <- 296 Q5_AC -> Q5_AC -> 298 P corresponds to the Path message and Q corresponds to the Resv 299 message. 301 As explained above, an RMR LSP consists of two counter-rotating ring 302 LSPs that start and end at the same node, say R1. As such, this 303 appears to cause a loop, something that is normally avoided by RSVP- 304 TE. There are some benefits to this: 306 Having a ring LSP form a loop allows the anchor node R1 to ping 307 itself and thus verify the end-to-end operation of the LSP. This, in 308 conjunction with link-level OAM, offers a good indication of the 309 operational state of the LSP. Also, having R1 to be the ingress 310 means that R1 can initiate the Path messages for the two ring LSPs. 311 This avoids R1 having to coordinate with its neighbors to signal the 312 LSPs, and simplifies the case where a ring update changes R1's ring 313 neighbors. The cost of this is a little more signaling and a couple 314 more label entries in the LFIB. However, we will let implementation 315 guide us to the wisdom of this approach. 317 4.2.1. Path Propagation for RMR 319 Ring LSPs are MP2P in nature. It means that every non-egress node is 320 also an ingress and a merge-point for the LSP. Focussing on ring- 321 LSP-0 (i.e ring-LSPs starting at R0): 323 R0---->R1---->R2---->R3---->R4---->R5---->R6--->R7--->R0(CW LSP) 324 R0---->R7---->R6---->R5---->R4---->R3---->R2--->R1--->R0(ACW LSP) 326 Each ring node inserts a new SENDER_TEMPLATE object into an incoming 327 Path message. The procedure for that is as follows: 329 When a ring node R3 receives a Path message initiated by anchor node 330 R0(for anchor lsp "lsp0"), R3 SHOULD make a copy of the received Path 331 message for "lsp0". R3 then inserts a new sender-template object 332 into the Path message for "lsp0". In the sender-template object, R3 333 uses the sender address as the loopback address of node R3 and lsp-id 334 = X. R3 then forwards this modified Path message to it's ring 335 neighbor. 337 So at this point, when Path messages heads out at R3, there will be 4 338 different SENDER_TEMPLATE objects in the outgoing Path message for 339 lsp0: 341 ----------------------------------------------------- 342 |SENDER_TEMPLATE_0 : SENDER_ADDRESS = R0, LSP_ID = 1 | 343 ----------------------------------------------------- 344 |SENDER_TEMPLATE_1 : SENDER_ADDRESS = R1, LSP_ID = 1 | 345 ----------------------------------------------------- 346 |SENDER_TEMPLATE_2 : SENDER_ADDRESS = R2, LSP_ID = 1 | 347 ----------------------------------------------------- 348 |SENDER_TEMPLATE_3 : SENDER_ADDRESS = R3, LSP_ID = 1 | 349 ----------------------------------------------------- 351 4.2.2. Resv Processing for RMR 353 When Egress node R0 receives the modified Path message, it replies 354 with the a Resv message containing multiple FLOW_DESCRIPTOR objects. 355 There should be 1 FLOW_DESCRIPTOR object corresponding to each of the 356 SENDER_TEMPLATE object in the incoming Path message. The SESSION 357 object of the Resv message will exactly match with the received Path 358 message. 360 [RFC 3209] already supports receiving a Resv message with multiple 361 flow-descriptors in it, as described in section 3.2 in that document. 362 In each flow-descriptor there is a separate: 364 a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent 365 in the Path message which could be admitted after admission-control 366 downstream, and 368 b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent 369 in the Path message that could be admitted after admission-control 370 downstream. 372 Each transit node removes the FLOW-DESCRIPTOR corresponding to itself 373 from the Resv message before sending the Resv message upstream. 375 4.3. Protection 377 In the rings, there are no protection LSPs -- no node or link bypass 378 LSPs, no standby LSPs and no detours. Protection is via the "other" 379 direction around the ring, which is why ring LSPs are in counter- 380 rotating pairs. Protection works in the same way for link, node and 381 ring LSP failures. 383 Since each ring LSP is a MP2P LSP, any ring node can inject traffic 384 onto a LSP whose anchor might be a different ring node. To achieve 385 the above, an ingress route will be installed as follows at every 386 ring node J, for a given ring-LSP with anchor Rk (say 1.2.3.4). 388 1.2.3.4 -> (Push CL_J+1,K, NH: R_J+1) # CW 389 -> (Push AL_J-1,K, NH: R_J-1) # AC 391 CL = Clockwise label 392 AL = Anti-Clockwise label 394 Traffic will either be load balanced in the CW and AC directions or 395 the traffic will be sent on just CW or AC lsp based on parameters 396 such as hop-count, policy etc. 398 Also, 2 transit routes will be installed for the anchor LSP 399 transiting from node Rj as follows: 401 CL_J,K -> SWAP(CL_J+1,K, NH: R_J+1) #CW 402 -> SWAP(AL_J-1,K , NH: R_J-1) #AC 404 CL = Clockwise label 405 AL = Anti-Clockwise label 406 CW NH has weight 1, AC NH has higher-weight. 408 AL_J,K -> SWAP(AL_J-1,K , NH: R_J-1) #AC 409 -> SWAP(CL_J+1,K, NH: R_J+1) #CW 411 CL = Clockwise label 412 AL = Anti-Clockwise label 413 AC NH has weight 1, CW NH has higher weight. 415 Suppose a packet headed in anti-clockwise direction towards R5 and it 416 arrives at node R7. Lets say that now R7 learns there is a link 417 failure in the AC direction. R7 reroutes this packet back onto the 418 clockwise direction. This reroute action is pre-programmed in the 419 LFIB, to minimize the time between detection of a fault and the 420 corresponding recovery action. 422 At this time, R7 also sends a notification to R0 that the AC 423 direction is not working. R0 modifies it's ingress route(for R5 LSP) 424 by removing the AC direction LSP's route. Thus, R0 switches traffic 425 to the CW direction. 427 These notification propagate CW until each traffic source on the ring 428 CW of the failure uses the CW direction.For RSVP-TE, this 429 notification is sent in the form of PathErr message. 431 To provide this notification, the ring node detecting failure SHOULD 432 send a Path Error message with error code of "Notify" and an error 433 value field of ("Tunnel locally repaired"). This Path Error code and 434 value is same as defined in RFC 4090[RFC4090] for the notification of 435 local repair. 437 Note that the failure of a node or a link will not necessarily affect 438 all ring LSPs. Thus, it is important to identify the affected LSPs 439 and only switch the affected LSPs. 441 4.4. Ring changes 443 A ring node can go down resulting in a smaller ring or a new node can 444 be added to the ring which will increase the ring size. In both of 445 the above cases, the ring auto-discovery process SHOULD kick in and 446 it SHOULD calculate a new ring with the changed ring nodes. 448 When the ring auto-discovery process is complete, IGP will signal 449 RSVP to begin the MBB process for the existing ring LSPs. For this 450 MBB process, the anchor node will create a new Path message with a 451 different Ring Instance ID in the SESSION object. All other fields 452 in the SESSION Object will remain same as the existing Path 453 message(before the ring change). 455 This new Path message will then propagate along the ring neighbors in 456 the same way as the original Path message. Each ring neighbor SHOULD 457 forward the Path message to it's appropriate neighbor based on the 458 new auto-discovery calculations. 460 For the ring links which are common between the old and new LSPs, the 461 LSPs will share resources(SE style reservation) on those ring links. 462 Note that here we are using Ring Instance ID in the SESSION object to 463 share resources instead of the LSP_ID in the SENDER_TEMPLATE 464 Object(which is used in RSVP-TE for sharing resources as described in 465 RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different 466 functionality as described in section Section 4.5. 468 4.5. Bandwidth management 470 For RSVP-TE LSPs, bandwidths may be signaled in both directions. 471 However, these are not provisioned either; rather, one does "reverse 472 call admission control". When a service needs to use an LSP, the 473 ring node where the traffic enters the ring attempts to increase the 474 bandwidth on the LSP to the egress. If successful, the service is 475 admitted to the ring. 477 . R0 . . . R1 478 . __________|| . 479 . / ________| . 480 R7 / / R2 481 Anti- | . / / . | 482 Clockwise | . | / . | Clockwise 483 v . | \ . v 484 R6 \ R3 485 . \ . 486 R5 . . . R4 488 Figure 2: BW Management in Ring with 8 nodes 490 Let's say that Ring node R5 wants to increase the BW for the LSP 491 whose egress is at node R1. To achieve this BW increase, Ring node 492 R5 has to increase BW along the LSP anchored at node R1(say lsp1). 494 R5 makes a copy of the existing ring Path message for lsp1. R5 then 495 modifies the sender-template object from the copied Path message for 496 "lsp1". In the sender-template object, R5 uses the sender address as 497 the loopback address of node R5 and lsp-id = X+1. R5 also modifies 498 the TSPEC object which represents the BW increase/decrease in this 499 new Path message. R5 then forwards this new Path message to it's 500 ring neighbor. The original anchor Path message has sender address 501 as loopback address of R1. 503 Now, let's say, node 5 wants to increase BW again for lsp1, then R5 504 adds a new SENDER_TEMPLATE object in the existing Path message for 505 "lsp1" with sender address as loopback of node 5 and lsp-id = X+2. 506 So at this point, there will be 2 different SENDER_TEMPLATE objects 507 corresponding to node 5 in the outgoing path message. 509 ----------------------------------------------------- 510 |SENDER_TEMPLATE_0 : SENDER_ADDRESS = R0, LSP_ID = 1 | 511 ----------------------------------------------------- 512 |SENDER_TEMPLATE_1 : SENDER_ADDRESS = R1, LSP_ID = 1 | 513 ----------------------------------------------------- 514 | ........ | 515 ----------------------------------------------------- 516 |SENDER_TEMPLATE_5 : SENDER_ADDRESS = R5, LSP_ID = 1 | 517 ----------------------------------------------------- 518 |SENDER_TEMPLATE_5 : SENDER_ADDRESS = R5, LSP_ID = 2 | 519 ----------------------------------------------------- 521 Similarly, if node R6 wants to increase the BW for "lsp1", it SHOULD 522 create a new Path message containing SENDER_TEMPLATE object with 523 sender address = loopback of node 6 and lsp-id = Y+1. Thus, it 524 should be noted that each ring-node independently tracks its own lsp- 525 ID that is currently in-use on a given RMR sub-LSP. This lsp-ID 526 value will (could) be different for each ring-node for a given ring 527 sub-LSP. 529 If sufficient BW is available all the way towards ring node R1, then 530 this new Path message reaches node R1. R1 generates a Resv message 531 with the correct FILTER_SPEC object corresponding to the received 532 SENDER_TEMPLATE object. This Resv message will also have the correct 533 FLOWSPEC object as per the requested bandwidth. 535 If sufficient BW is not available at some downstream (say node R9), 536 then ring node R9 SHOULD generate a PathErr message with the 537 corresponding Sender Template Object. When node R5 receives this 538 PathErr message, R5 understands that the BW increase was not 539 successful. Note that the existing established bandwidths for lsp1 540 are not affected by this new PathErr message. 542 When ring node R5 no longer needs the BW reservation, then ring node 543 R5 SHOULD originate a new Path message with the appropriate Sender 544 Template Object containing 0 BW as described above. Every downstream 545 node SHOULD then remove bandwidth allocated on the corresponding link 546 on receipt of this Path message. 548 Also, note that as part of this BW increase or decrease process, any 549 ring node does not actually change any label associated with the LSP. 550 So, the label remains same as it was signaled initially when the 551 anchor LSP came up. 553 5. Security Considerations 555 It is not anticipated that either the notion of MPLS rings or the 556 extensions to various protocols to support them will cause new 557 security loopholes. As this document is updated, this section will 558 also be updated. 560 6. Contributors 562 Ravi Singh 563 Juniper Networks, Inc. 564 1133 Innovation Way 565 Sunnyvale, CA 94089 566 USA 568 Email: ravis@juniper.net 570 Santosh Esale 571 Juniper Networks, Inc. 572 1133 Innovation Way 573 Sunnyvale, CA 94089 574 USA 576 Email: sesale@juniper.net 578 Raveendra Torvi 579 Juniper Networks, Inc. 580 10 Technology Park Dr 581 Westford, MA 01886 582 USA 584 Email: rtorvi@juniper.net 586 7. IANA Considerations 588 Requests to IANA will be made in a future version of this document. 590 8. References 592 8.1. Normative References 594 [I-D.ietf-mpls-rmr] 595 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 596 draft-ietf-mpls-rmr-07 (work in progress), March 2018. 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 8.2. Informative References 605 [I-D.dai-mpls-rsvp-te-mbb-label-reuse] 606 Dai, M. and M. Chaudhry, "MPLS RSVP-TE MBB Label Reuse", 607 draft-dai-mpls-rsvp-te-mbb-label-reuse-01 (work in 608 progress), September 2015. 610 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 611 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 612 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 613 September 1997, . 615 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 616 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 617 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 618 . 620 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 621 (TE) Extensions to OSPF Version 2", RFC 3630, 622 DOI 10.17487/RFC3630, September 2003, 623 . 625 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 626 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 627 DOI 10.17487/RFC4090, May 2005, 628 . 630 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 631 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 632 2008, . 634 Authors' Addresses 636 Abhishek Deshmukh 637 Juniper Networks, Inc. 638 10 Technology Park Dr 639 Westford, MA 01886 640 USA 642 Email: adeshmukh@juniper.net 643 Kireeti Kompella 644 Juniper Networks, Inc. 645 1133 Innovation Way 646 Sunnyvale, CA 94089 647 USA 649 Email: kireeti@juniper.net