idnits 2.17.1 draft-ietf-teas-rsvp-rmr-extension-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 : ---------------------------------------------------------------------------- ** 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 (July 8, 2019) is 1744 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) == Unused Reference: 'I-D.ietf-mpls-rmr' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'I-D.dai-mpls-rsvp-te-mbb-label-reuse' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 644, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-11 Summary: 1 error (**), 0 flaws (~~), 6 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: January 9, 2020 July 8, 2019 7 RSVP Extensions for RMR 8 draft-ietf-teas-rsvp-rmr-extension-02 10 Abstract 12 Ring topology is commonly found in access and aggregation networks. 13 However, the use of MPLS as the transport protocol for rings is very 14 limited today. {{!I-D.ietf-mpls-rmr}} describes a mechanism to 15 handle rings efficiently using MPLS. This document describes the 16 extensions to the RSVP-TE protocol for signaling MPLS label switched 17 paths in rings. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Session Object . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects . . . . . . . . . . . 5 59 4. Ring Signaling Procedures . . . . . . . . . . . . . . . . . . 5 60 4.1. Differences from regular RSVP-TE LSPs . . . . . . . . . . 5 61 4.2. LSP signaling . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2.1. Path Propagation for RMR . . . . . . . . . . . . . . 8 63 4.2.2. Resv Processing for RMR . . . . . . . . . . . . . . . 8 64 4.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.4. Ring changes . . . . . . . . . . . . . . . . . . . . . . 10 66 4.5. Express Links . . . . . . . . . . . . . . . . . . . . . . 11 67 4.6. Bandwidth management . . . . . . . . . . . . . . . . . . 11 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 8.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 This document extends RSVP-TE [RFC3209] to establish label-switched 79 path (LSP) tunnels in the ring topology. Rings are auto-discovered 80 using the mechanisms mentioned in the {{!I-D.ietf-mpls-rmr}}. Either 81 IS-IS [RFC5305] or OSPF[RFC3630] can be used as the IGP for auto- 82 discovering the rings. 84 After the rings are auto-discovered, each node in the ring knows its 85 clockwise(CW) and anti-clockwise (AC) ring neighbors and its ring 86 links. All of the express links in the ring also get identified as 87 part of the auto-discovery process. At this point, every node in the 88 ring informs the RSVP protocol to begin the signaling of the ring 89 LSPs. 91 Section 2 covers the terminology used in this document. Section 3 92 presents the RSVP protocol extensions needed to support MPLS rings. 93 Section 4 describes the procedures of RSVP LSP signaling in detail. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Terminology 105 Assuming there are n nodes in the network, a ring gets formed by a 106 subset of those n nodes {Ri, Ri+1, Ri+2,...Rn}. We define the 107 direction from node Ri to Ri+1 as "clockwise" (CW) and the reverse 108 direction as "anti-clockwise" (AC). As there might be several rings 109 in a graph, each ring is identified by it's own distinct ring ID - 110 RID. 112 R0 . . . R1 113 . . 114 R7 R2 115 Anti- | . Ring . | 116 Clockwise | . . | Clockwise 117 v . RID = 17 . v 118 R6 R3 119 . . 120 R5 . . . R4 122 Figure 1: Ring with 8 nodes 124 The following terminology is used for ring LSPs: 126 Ring ID (RID): A non-zero number that identifies a ring; this is 127 unique in a Service Provider's network. A node may belong to 128 multiple rings. 130 Ring node: A member of a ring. Note that a device may belong to 131 several rings. 133 Node index: A logical numbering of nodes in a ring, from zero up to 134 one less than the ring size. Used purely for exposition in this 135 document. 137 Ring neighbors: Nodes whose indices differ by one (modulo ring 138 size). 140 Ring links: Links that connect ring neighbors. 142 Express links: Links that connect non-neighboring ring nodes. 144 MP2P LSP: Each LSP in the ring is a multipoint to point LSP such 145 that LSP can have multiple ingress nodes and one egress node. 147 3. RSVP Extensions 149 Due to the new ring LSP semantics, the signaling-message 150 identification of ring LSPs will be different than the regular RSVP 151 LSPs. So, a new C-Type is defined here for the SESSION object. This 152 new C-Type will help to clearly differentiate ring LSPs from regular 153 LSPs. In addition, new flags are introduced in the SESSION object to 154 represent the ring direction of the corresponding Path message. 156 3.1. Session Object 158 Class = SESSION, LSP_TUNNEL_IPv4 C-Type = TBD 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Ring anchor node address | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Ring Flags | Ring Instance ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Ring ID | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 SESSION Object 172 Ring anchor node address: IPv4 address of the anchor node. Each 173 anchor node creates a LSP addressed to itself. 175 Ring Instance ID: A 16-bit identifier used in the SESSION. This 176 Ring Instance ID is useful for graceful ring changes. If a new 177 node is being added to the ring(resulting in signaling of a larger 178 ring) or some existing node goes down(resulting in signaling of a 179 smaller ring), in those cases, anchor node creates a new tunnel 180 with a different Ring Instance ID. 182 Ring ID: A 32-bit number that identifies a ring; this is unique in 183 some scope of a Service Provider's network. This number remains 184 constant throughout the existence of ring. 186 Ring Flags: For each ring, the anchor node starts signaling of a 187 ring LSP. Ring LSP named RLi, anchored on node Ri, consists of 188 two counter-rotating unicast LSPs that start and end at Ri. One 189 LSP will be in the clockwise direction and other LSP will be in 190 the anti-clockwise direction. A ring LSP is "multipoint": any 191 node along the ring can use LSP RLi to send traffic to Ri; this 192 can be in either the CW or AC directions, or both (i.e., load 193 balanced). Two new flags are defined in the SESSION object which 194 define the ring direction of the corresponding Path message. 196 ClockWise(CW) Direction 0x01: This flag indicates that the 197 corresponding Path message is traveling in the ClockWise(CW) 198 direction along the ring. 200 Anti-ClockWise(AC) Direction 0x02: This flag indicates that the 201 corresponding Path message is traveling in the Anti-ClockWise(AC) 202 direction along the ring. 204 Express Link 0x04: This flag indicates that the corresponding Path 205 message is traveling along the Express link in the ring. 207 3.2. SENDER_TEMPLATE,FILTER_SPEC Objects 209 There will be no changes to the SENDER_TEMPLATE and FILTER_SPEC 210 objects. The format of the above 2 objects will be similar to the 211 definitions in RFC 3209. [RFC3209] Only the semantics of these 212 objects will slightly change. This will be explained in section 213 Section 4.6 below. 215 4. Ring Signaling Procedures 217 A ring node indicates in its IGP updates the ring LSP signaling 218 protocols that it supports. This can be LDP and/or RSVP-TE. 219 Ideally, each node should support both. If the ring is configured 220 with RSVP as the signaling protocol, then once a ring node R_i knows 221 the RID, its ring links and directions, it kicks off ring RSVP LSP 222 signaling automatically. 224 4.1. Differences from regular RSVP-TE LSPs 226 Ring LSPs differ from regular RSVP-TE LSPs in several ways: 228 1. Ring LSPs (by construction) form a loop. 230 2. Ring LSPs are multipoint-to-point. Any ring node can inject 231 traffic into a ring LSP. 233 3. The bandwidth of a ring LSP can change hop-by-hop. 235 4. Ring LSPs are protected without the use of bypass or detour LSPs. 236 Protection is handled by the ring LSP traversing in the opposite 237 direction. 239 4.2. LSP signaling 241 After the ring auto-discovery process, each anchor node creates a LSP 242 addressed to itself. This ring LSP contains of a pair of counter- 243 rotating unicast LSPs. So, for a ring containing N nodes, there will 244 be 2N total LSPs signaled. 246 There is no need for ERO object in the Path message. The Path 247 message for ring LSPs has the following format: 249 ::= [ ] 250 251 252 253 [ ] 254 256 ::= | 257 258 ::= 260 The anchor node creates 2 Path messages traveling in opposite 261 directions. The SESSION format MUST be as per the description in 262 Section 3.1. The anchor node which creates the LSP will insert it's 263 own address in the "Ring anchor node address" field of the SESSION 264 object. So effectively, the Path messages are addressed to the 265 originating node itself. 267 The SESSION flags of these 2 Path messages are different. The Path 268 message sent to the CW neighbor MUST have the CW flag set in the 269 SESSION object to signal the LSP going in the clockwise direction. 270 The Path message sent to the AC neighbor MUST have the AC flag set to 271 signal the LSP in the anti-clockwise direction. 273 When an incoming Path message is received at the ring node Ri, it 274 consults the results of auto-discovery to find the appropriate ring 275 neighbor. If the incoming Path message has CW direction flag set, 276 then Ri includes its own SENDER_DESCRIPTOR in the path message and 277 forwards the Path message to its CW ring neighbor(Ri+1). Similarly 278 if the incoming Path message has AC direction flag set, then Ri 279 includes its own SENDER_TEMPPLATE and forwards that Path message to 280 it's AC ring neighbor(Ri-1). Thus, there is no need of ERO in the 281 Path message. The Path message is routed locally at each ring based 282 on the ring auto-discovery calculations. 284 The RESV message for ring LSPs also uses the new RING_IPv4 SESSION 285 object. When the Path message originated from the anchor node Ri 286 reaches back to Ri, Ri generates a Resv message. Note that this 287 means that anchor node is both Ingress and Egress for the Path 288 message. The Resv message copies the same ring flags as received in 289 the corresponding Path message. So, a Resv message for a CW LSP goes 290 in the AC direction (unlike the Path message, which goes CW). This 291 is done to correctly match Path and corresponding Resv messages at 292 transit ring nodes. Upon receiving Resv message with CW flag set, 293 the ring node will forward the Resv message to its AC neighbor. 295 Each ring node Ri allocates CW and AC labels for each ring LSP RLx(x 296 between i..n). As the signaling propagates around the ring, CW and 297 AC labels are exchanged. When Ri receives CW and AC labels for LSP 298 RLx from its ring neighbors, primary and fast reroute (FRR) paths for 299 RLx are installed at Ri. 301 Consider the following three nodes of the ring, and their signaling 302 interactions for LSP RL5 originating from anchor node R5: 304 P5_CW -> P5_CW -> 305 Q5_CW <- Q5_CW <- 306 ... ------ R7 --------- R8 --------- R9 ------ ... 307 P5_AC <- P5_AC <- 308 Q5_AC -> Q5_AC -> 310 P corresponds to the Path message and Q corresponds to the Resv 311 message. 313 As explained above, an RMR LSP consists of two counter-rotating ring 314 LSPs that start and end at the same node, say R1. As such, this 315 appears to cause a loop, something that is normally avoided by RSVP- 316 TE. There are some benefits to this: 318 Having a ring LSP form a loop allows the anchor node R1 to ping 319 itself and thus verify the end-to-end operation of the LSP. This, in 320 conjunction with link-level OAM, offers a good indication of the 321 operational state of the LSP. Also, having R1 to be the ingress 322 means that R1 can initiate the Path messages for the two ring LSPs. 323 This avoids R1 having to coordinate with its neighbors to signal the 324 LSPs, and simplifies the case where a ring update changes R1's ring 325 neighbors. The cost of this is a little more signaling and a couple 326 more label entries in the LFIB. However, we will let experiences 327 from implementation guide us when we evaluate this approach. 329 4.2.1. Path Propagation for RMR 331 Ring LSPs are MP2P in nature. It means that every non-egress node is 332 also an ingress and a merge-point for the LSP. Focussing on ring- 333 LSP-0 (i.e ring-LSPs starting at R0): 335 R0---->R1---->R2---->R3---->R4---->R5---->R6--->R7--->R0(CW LSP) 336 R0---->R7---->R6---->R5---->R4---->R3---->R2--->R1--->R0(ACW LSP) 338 Each ring node inserts a new SENDER_TEMPLATE object into an incoming 339 Path message. The procedure for that is as follows: 341 When a ring node R3 receives a Path message initiated by anchor node 342 R0(for anchor lsp "lsp0"), R3 SHOULD make a copy of the received Path 343 message for "lsp0". R3 then inserts a new sender-template object 344 into the Path message for "lsp0". In the sender-template object, R3 345 uses the sender address as the loopback address of node R3 and lsp-id 346 = X. R3 then forwards this modified Path message to it's ring 347 neighbor. 349 So at this point, when Path messages heads out at R3, there will be 4 350 different SENDER_TEMPLATE objects in the outgoing Path message for 351 lsp0: 353 ----------------------------------------------------- 354 |SENDER_TEMPLATE_0 : SENDER_ADDRESS = R0, LSP_ID = 1 | 355 ----------------------------------------------------- 356 |SENDER_TEMPLATE_1 : SENDER_ADDRESS = R1, LSP_ID = 1 | 357 ----------------------------------------------------- 358 |SENDER_TEMPLATE_2 : SENDER_ADDRESS = R2, LSP_ID = 1 | 359 ----------------------------------------------------- 360 |SENDER_TEMPLATE_3 : SENDER_ADDRESS = R3, LSP_ID = 1 | 361 ----------------------------------------------------- 363 4.2.2. Resv Processing for RMR 365 When Egress node R0 receives the modified Path message, it replies 366 with the a Resv message containing multiple FLOW_DESCRIPTOR objects. 367 There should be 1 FLOW_DESCRIPTOR object corresponding to each of the 368 SENDER_TEMPLATE object in the incoming Path message. The SESSION 369 object of the Resv message will exactly match with the received Path 370 message. 372 RFC 3209[RFC3209] already supports receiving a Resv message with 373 multiple flow-descriptors in it, as described in section 3.2 in that 374 document. In each flow-descriptor there is a separate: 376 a. FLOW_SPEC object corresponding to the SENDER_TSPEC that was sent 377 in the Path message which could be admitted after admission-control 378 downstream, and 380 b. FILTER_SPEC object corresponding to SENDER_TEMPLATE that was sent 381 in the Path message that could be admitted after admission-control 382 downstream. 384 Each transit node removes the FLOW-DESCRIPTOR corresponding to itself 385 from the Resv message before sending the Resv message upstream. 387 4.3. Protection 389 In the rings, there are no protection LSPs -- no node or link bypass 390 LSPs, no standby LSPs and no detours. Protection is via the "other" 391 direction around the ring, which is why ring LSPs are in counter- 392 rotating pairs. Protection works in the same way for link, node and 393 ring LSP failures. 395 Since each ring LSP is a MP2P LSP, any ring node can inject traffic 396 onto a LSP whose anchor might be a different ring node. To achieve 397 the above, an ingress route will be installed as follows at every 398 ring node J, for a given ring-LSP with anchor Rk (say 1.2.3.4). 400 1.2.3.4 -> (Push CL_J+1,K, NH: R_J+1) # CW 401 -> (Push AL_J-1,K, NH: R_J-1) # AC 403 CL = Clockwise label 404 AL = Anti-Clockwise label 406 Traffic will either be load balanced in the CW and AC directions or 407 the traffic will be sent on just CW or AC lsp based on parameters 408 such as hop-count, policy etc. 410 Also, 2 transit routes will be installed for the anchor LSP 411 transiting from node Rj as follows: 413 CL_J,K -> SWAP(CL_J+1,K, NH: R_J+1) #CW 414 -> SWAP(AL_J-1,K , NH: R_J-1) #AC 416 CL = Clockwise label 417 AL = Anti-Clockwise label 418 CW NH has weight 1, AC NH has higher-weight. 420 AL_J,K -> SWAP(AL_J-1,K , NH: R_J-1) #AC 421 -> SWAP(CL_J+1,K, NH: R_J+1) #CW 423 CL = Clockwise label 424 AL = Anti-Clockwise label 425 AC NH has weight 1, CW NH has higher weight. 427 Suppose a packet headed in anti-clockwise direction towards R5 and it 428 arrives at node R7. Lets say that now R7 learns there is a link 429 failure in the AC direction. R7 reroutes this packet back onto the 430 clockwise direction. This reroute action is pre-programmed in the 431 LFIB, to minimize the time between detection of a fault and the 432 corresponding recovery action. 434 At this time, R7 also sends a notification to R0 that the AC 435 direction is not working. R0 modifies it's ingress route(for R5 LSP) 436 by removing the AC direction LSP's route. Thus, R0 switches traffic 437 to the CW direction. 439 These notification propagate CW until each traffic source on the ring 440 CW of the failure uses the CW direction.For RSVP-TE, this 441 notification is sent in the form of PathErr message. 443 To provide this notification, the ring node detecting failure SHOULD 444 send a Path Error message with error code of "Notify" and an error 445 value field of ("Tunnel locally repaired"). This Path Error code and 446 value is same as defined in RFC 4090[RFC4090] for the notification of 447 local repair. 449 Note that the failure of a node or a link will not necessarily affect 450 all ring LSPs. Thus, it is important to identify the affected LSPs 451 and only switch the affected LSPs. 453 4.4. Ring changes 455 A ring node can go down resulting in a smaller ring or a new node can 456 be added to the ring which will increase the ring size. In both of 457 the above cases, the ring auto-discovery process SHOULD kick in and 458 it SHOULD calculate a new ring with the changed ring nodes. 460 When the ring auto-discovery process is complete, IGP will signal 461 RSVP to begin the MBB process for the existing ring LSPs. For this 462 MBB process, the anchor node will create a new Path message with a 463 different Ring Instance ID in the SESSION object. All other fields 464 in the SESSION Object will remain same as the existing Path 465 message(before the ring change). 467 This new Path message will then propagate along the ring neighbors in 468 the same way as the original Path message. Each ring neighbor SHOULD 469 forward the Path message to it's appropriate neighbor based on the 470 new auto-discovery calculations. 472 For the ring links which are common between the old and new LSPs, the 473 LSPs will share resources(SE style reservation) on those ring links. 474 Note that here we are using Ring Instance ID in the SESSION object to 475 share resources instead of the LSP_ID in the SENDER_TEMPLATE 476 Object(which is used in RSVP-TE for sharing resources as described in 477 RFC 3209 [RFC4090]). The LSP_ID use is reserved for a different 478 functionality as described in section Section 4.6. 480 4.5. Express Links 482 Express links are discovered once ring nodes, ring links and 483 directions have been established. As defined earlier, express links 484 are links joining non-neighboring ring nodes. Express links are both 485 clockwise and anti-clockwise. 487 A ring node with an Express link replicates the incoming Path message 488 over the Express link. The "Express Link" flag is set in the SESSION 489 object of the replicated Path message. Also, the ring node Ri 490 includes an additional SENDER_DESCRIPTOR with a new LSP_ID in the 491 outgoing PATH message. 493 When this Path message with Express link flag is received at the 494 other end of Express link, the other ring node replies with the Resv 495 message. It does not forward this Path message to any of it's ring 496 neighbors. Thus, the "Express" LSPs are effectively 1 hop LSPs 497 formed over the "Express Links". 499 4.6. Bandwidth management 501 For RSVP-TE LSPs, bandwidths may be signaled in both directions. 502 However, these are not provisioned either; rather, one does "reverse 503 call admission control". When a service needs to use an LSP, the 504 ring node where the traffic enters the ring attempts to increase the 505 bandwidth on the LSP to the egress. If successful, the service is 506 admitted to the ring. 508 . R0 . . . R1 509 . __________|| . 510 . / ________| . 511 R7 / / R2 512 Anti- | . / / . | 513 Clockwise | . | / . | Clockwise 514 v . | \ . v 515 R6 \ R3 516 . \ . 517 R5 . . . R4 519 Figure 2: BW Management in Ring with 8 nodes 521 Let's say that Ring node R5 wants to increase the BW for the LSP 522 whose egress is at node R1. To achieve this BW increase, Ring node 523 R5 has to increase BW along the LSP anchored at node R1(say lsp1). 525 R5 makes a copy of the existing ring Path message for lsp1. R5 then 526 modifies the sender-template object from the copied Path message for 527 "lsp1". In the sender-template object, R5 uses the sender address as 528 the loopback address of node R5 and lsp-id = X+1. R5 also modifies 529 the TSPEC object which represents the BW increase/decrease in this 530 new Path message. R5 then forwards this new Path message to it's 531 ring neighbor. The original anchor Path message has sender address 532 as loopback address of R1. 534 Now, let's say, node 5 wants to increase BW again for lsp1, then R5 535 adds a new SENDER_TEMPLATE object in the existing Path message for 536 "lsp1" with sender address as loopback of node 5 and lsp-id = X+2. 537 So at this point, there will be 2 different SENDER_TEMPLATE objects 538 corresponding to node 5 in the outgoing path message. 540 ----------------------------------------------------- 541 |SENDER_TEMPLATE_0 : SENDER_ADDRESS = R0, LSP_ID = 1 | 542 ----------------------------------------------------- 543 |SENDER_TEMPLATE_1 : SENDER_ADDRESS = R1, LSP_ID = 1 | 544 ----------------------------------------------------- 545 | ........ | 546 ----------------------------------------------------- 547 |SENDER_TEMPLATE_5 : SENDER_ADDRESS = R5, LSP_ID = 1 | 548 ----------------------------------------------------- 549 |SENDER_TEMPLATE_5 : SENDER_ADDRESS = R5, LSP_ID = 2 | 550 ----------------------------------------------------- 552 Similarly, if node R6 wants to increase the BW for "lsp1", it SHOULD 553 create a new Path message containing SENDER_TEMPLATE object with 554 sender address = loopback of node 6 and lsp-id = Y+1. Thus, it 555 should be noted that each ring-node independently tracks its own lsp- 556 ID that is currently in-use on a given RMR sub-LSP. This lsp-ID 557 value will (could) be different for each ring-node for a given ring 558 sub-LSP. 560 If sufficient BW is available all the way towards ring node R1, then 561 this new Path message reaches node R1. R1 generates a Resv message 562 with the correct FILTER_SPEC object corresponding to the received 563 SENDER_TEMPLATE object. This Resv message will also have the correct 564 FLOWSPEC object as per the requested bandwidth. 566 If sufficient BW is not available at some downstream (say node R9), 567 then ring node R9 SHOULD generate a PathErr message with the 568 corresponding Sender Template Object. When node R5 receives this 569 PathErr message, R5 understands that the BW increase was not 570 successful. Note that the existing established bandwidths for lsp1 571 are not affected by this new PathErr message. 573 When ring node R5 no longer needs the BW reservation, then ring node 574 R5 SHOULD originate a new Path message with the appropriate Sender 575 Template Object containing 0 BW as described above. Every downstream 576 node SHOULD then remove bandwidth allocated on the corresponding link 577 on receipt of this Path message. 579 Also, note that as part of this BW increase or decrease process, any 580 ring node does not actually change any label associated with the LSP. 581 So, the label remains same as it was signaled initially when the 582 anchor LSP came up. 584 5. Security Considerations 586 It is not anticipated that either the notion of MPLS rings or the 587 extensions to various protocols to support them will cause new 588 security loopholes. As this document is updated, this section will 589 also be updated. 591 6. Contributors 593 Ravi Singh 594 Juniper Networks, Inc. 595 1133 Innovation Way 596 Sunnyvale, CA 94089 597 USA 599 Email: ravis@juniper.net 600 Santosh Esale 601 Juniper Networks, Inc. 602 1133 Innovation Way 603 Sunnyvale, CA 94089 604 USA 606 Email: sesale@juniper.net 608 Raveendra Torvi 609 Juniper Networks, Inc. 610 10 Technology Park Dr 611 Westford, MA 01886 612 USA 614 Email: rtorvi@juniper.net 616 7. IANA Considerations 618 Requests to IANA will be made in a future version of this document. 620 8. References 622 8.1. Normative References 624 [I-D.ietf-mpls-rmr] 625 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 626 draft-ietf-mpls-rmr-11 (work in progress), June 2019. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 634 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 635 May 2017, . 637 8.2. Informative References 639 [I-D.dai-mpls-rsvp-te-mbb-label-reuse] 640 Dai, M. and M. Chaudhry, "MPLS RSVP-TE MBB Label Reuse", 641 draft-dai-mpls-rsvp-te-mbb-label-reuse-01 (work in 642 progress), September 2015. 644 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 645 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 646 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 647 September 1997, . 649 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 650 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 651 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 652 . 654 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 655 (TE) Extensions to OSPF Version 2", RFC 3630, 656 DOI 10.17487/RFC3630, September 2003, 657 . 659 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 660 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 661 DOI 10.17487/RFC4090, May 2005, 662 . 664 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 665 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 666 2008, . 668 Authors' Addresses 670 Abhishek Deshmukh 671 Juniper Networks, Inc. 672 10 Technology Park Dr 673 Westford, MA 01886 674 USA 676 Email: adeshmukh@juniper.net 678 Kireeti Kompella 679 Juniper Networks, Inc. 680 1133 Innovation Way 681 Sunnyvale, CA 94089 682 USA 684 Email: kireeti@juniper.net