idnits 2.17.1 draft-tanaka-pce-stateful-pce-mbb-06.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 20, 2018) is 2127 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 (-10) exists of draft-ietf-pce-association-group-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Y. Tanaka 3 Internet-Draft Y. Kamite 4 Intended status: Standards Track NTT Communications 5 Expires: December 22, 2018 D. Dhody 6 R. Palleti 7 Huawei Technologies 8 June 20, 2018 10 Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure 11 using Stateful PCE 12 draft-tanaka-pce-stateful-pce-mbb-06 14 Abstract 16 Stateful Path Computation Element (PCE) and its corresponding 17 protocol extensions provide a mechanism that enables PCE to do 18 stateful control of Multiprotocol Label Switching (MPLS) Traffic 19 Engineering Label Switched Paths (TE LSP). Stateful PCE supports 20 manipulating of the existing LSP's state and attributes (e.g., 21 bandwidth and path) via delegation and also instantiation of new LSPs 22 in the network via PCE Initiation procedures. 24 In the current MPLS TE network using Resource ReSerVation Protocol 25 (RSVP-TE), LSPs are often controlled by Make-before-break (M-B-B) 26 signaling by the headend for the purpose of LSP restoration and 27 reoptimization. In most cases, it is an essential operation to 28 reroute LSP traffic without any data disruption. 30 This document specifies the procedure of applying stateful PCE's 31 control to make-before-break RSVP-TE signaling. In this document, 32 two types of restoration/reoptimization procedures are defined, 33 implicit mode and explicit mode. This document also specifies the 34 usage and handling of stateful PCEP (PCE Communication Protocol) 35 messages, expected behavior of PCC as RSVP-TE headend and necessary 36 extensions of additional PCEP objects. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 22, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions used in this document . . . . . . . . . . . . . . 3 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 5. Make-Before-Break LSP procedures . . . . . . . . . . . . . . 5 77 5.1. Implicit Make-Before-Break Mode . . . . . . . . . . . . . 6 78 5.2. Explicit Make-Before-Break Mode . . . . . . . . . . . . . 7 79 5.2.1. Initiate Association Group for old LSP . . . . . . . 8 80 5.2.2. Establish new Trial LSP . . . . . . . . . . . . . . . 9 81 5.2.3. Switchover Data Traffic triggered by a PCUpd message 11 82 6. Protocol extension . . . . . . . . . . . . . . . . . . . . . 12 83 6.1. Association group . . . . . . . . . . . . . . . . . . . . 13 84 6.2. Trial LSP TLV in ASSOCIATION Objects . . . . . . . . . . 13 85 6.3. Optional TLVs . . . . . . . . . . . . . . . . . . . . . . 14 86 6.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 14 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 8.1. PCEP TLV Indicators . . . . . . . . . . . . . . . . . . . 15 90 8.2. Association Object Type Indicator . . . . . . . . . . . . 15 91 9. Operational Considerations . . . . . . . . . . . . . . . . . 15 92 9.1. Operation in multiple PCEs . . . . . . . . . . . . . . . 15 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 96 11.2. Informative References . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 102 enables the communication between a Path Computation Client (PCC) and 103 a Path Control Element (PCE), or between PCE and PCE, for the purpose 104 of computation of Multiprotocol Label Switching (MPLS) as well as 105 Generalzied MPLS (GMPLS) for Traffic Engineering Label Switched Path 106 (TE LSP) characteristics. 108 [RFC8231] describes the stateful Path Computation Elements (PCE) and 109 defines the extensions to PCEP to enable stateful control of LSPs 110 within and across PCEP sessions, further it also describes mechanisms 111 to effect LSP state synchronization between PCCs and PCEs, and PCE 112 control of timing and sequence of path computations within and across 113 PCEP sessions. 115 Today, however, there is no detailed procedure specified for 116 restoration and reoptimization of MPLS-TE LSP using stateful PCE. In 117 today's MPLS RSVP-TE mechanism, make-before-break (M-B-B) is a widely 118 common scheme supported by headend Label Edge Router (LER) in order 119 to assure no traffic disruption during restoration and 120 reoptimization. Hence it is naturally desirable for stateful PCE to 121 control M-B-B based signaling and forwarding process. 123 This document specifies the definite procedures of applying stateful 124 PCE's control of the M-B-B procedures. In this document, two types 125 of restoration/reoptimization procedures are defined, Implicit mode 126 and Explicit mode. This document also specifies the usage and 127 handling of stateful PCEP (PCE Communication Protocol) messages, 128 expected behavior of PCC as RSVP-TE headend and several extensions of 129 additional objects. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here. 139 3. Terminology 141 This document uses the following terms defined in [RFC5440]: PCC, 142 PCE, PCEP Peer. 144 This document uses the following terms defined in [RFC3209]: make- 145 before-break (M-B-B), Path State Block (PSB). 147 This document uses the following terms defined in [RFC4426] and 148 [RFC4427]: recovery, protection, restoration. 150 According to their definition the term "recovery" is generically used 151 to denote both protection and restoration; the specific terms 152 "protection" and "restoration" are used only when differentiation is 153 required. The subtle distinction between protection and restoration 154 is made based on the resource allocation done during the recovery 155 period. Hence the protection allocates LSP resource in advance of a 156 failure, while the restoration allocates LSP resource after a failure 157 occur. 159 4. Motivation 161 As for current MPLS mechanism, make-before-break(M-B-B) concept is 162 outlined in [RFC3209], which allows adaptive and smooth RSVP-TE LSP 163 rerouting that does not disrupt traffic or adversely impact network 164 operations while rerouting is in progress. M-B-B is applicable for 165 reoptimizing LSP's route and resources for several use cases, for 166 example, to adopt better path for reversion after failure, to change 167 traversing node/links for planned maintenance, to change bandwidth of 168 LSPs etc. M-B-B is also used for global restoration scenario in case 169 of failure, which is effective if operators do not want to reserve 170 both working and standby LSP's bandwidth in advance. Once failure 171 occur, LSP becomes down, however PSB (Path State Block) of a headend 172 node remains and keep resources intact. Using M-B-B, the headend 173 node is able to resignals working LSP while the PSB remains until new 174 restoration LSP is successfully established. In real deployment, it 175 can also be operated with local protection scheme FRR (Fast ReRoute). 177 Since M-B-B operational scheme is universally common in MPLS network 178 today, it is naturally much desirable to utilize it under the 179 architecture of stateful PCE. 181 The basic procedure of the Make-Before-Break method is outlined as 182 follows: 184 1. Establish a new LSP 185 2. Transfer data traffic from old LSP onto the new LSP 186 3. Tear down the old LSP (Release old PSB) 188 In M-B-B, it is an important behavior that headend node handles the 189 sequence of data traffic switchover. The headend is able to Make one 190 or more new LSPs for a particular Tunnel (i.e., it is allowed to 191 signal multiple LSPs with different LSP-IDs that share a common 192 Tunnel IDs), and the headend will switch the traffic to only one (or 193 some) of those LSPs. In some use cases about stateful PCE, it is 194 expected that controller/operators can watch and control when the 195 data is switched over and which LSPs are used. Therefore, this 196 document covers such a procedure and related message extensions. 198 5. Make-Before-Break LSP procedures 200 There are possibly two modes introduced for Make-Before-Break 201 procedure under stateful PCE. The first one is "implicit M-B-B 202 mode", where the operation is triggered by a Update Request(PCUpd) 203 message from a PCE, and a PCC handles whole Make-Before-Break steps 204 (signaling, transferring data traffic and teardown) by itself. This 205 mode utilizes the existing messages and procedures as defined in 206 [RFC8231] . 208 The second one is "explicit M-B-B mode", where the operation is 209 triggered by a PCUpd message with a new TRIAL LSP TLV (defined in 210 Section 6.2). A PCE also controls timing and sequence of the M-B-B 211 steps that a PCC takes. This procedure uses ASSOCIATION Object that 212 is defined in [I-D.ietf-pce-association-group]. 214 Both types of procedure require at least two LSPs residing in a 215 single MPLS-TE tunnel, working LSP and trial LSPs. An ingress node 216 is currently transporting data traffic on the working LSP, and then 217 it establishes one or more trial LSPs. As per [RFC3209] Section 2.5. 218 "LSP ID" of a restoration LSP, which is newly signaled, differs from 219 that of a working LSP in RSVP-TE. Note that it is also used for LSP- 220 ID in LSP Identifiers TLVs in PCEP messages, and it differs from 221 PLSP-ID ([RFC8231]). In this document, LSP ID of a working LSP 222 describes "old" and that of a trial LSP describes "new" as a simple 223 example. 225 Implicit mode has high affinity with most existing MPLS edge node 226 implementations which perform entire steps of M-B-B automatically at 227 once. This mode is particularly applicable for migration scenario 228 for the existing deployment where service providers want their 229 recovery/reoptimization operation be delegated to a centralized PCE. 231 Explicit mode is much more flexible than Implicit mode since it 232 allows PCEs to manage each step of the M-B-B. Explicit mode is 233 applicable to several new use cases that require split control of 234 signaling and data switchover. For example, if end-to-end data path 235 is created by connecting multiple individual LSPs across different 236 segments (e.g., LSP stitching), in reoptimization scenario, data 237 flowing cannot be started unless signaling of all LSPs is completed. 238 Similarly, there is a case under Software Defined Networking (SDN) 239 applications, where MPLS domain is connected to other non-MPLS 240 domains, and the end-to-end data switchover timing should be 241 carefully coordinated with various different methods of path/flow 242 setup in each domain. 244 PCC and PCE can distinguish which mode, implicit mode or explicit 245 mode, is to be performed by checking the presence of ASSOCIATION and 246 certain TLV in the PCEP messages. The implementation MAY support 247 both modes, but for each restoration/reoptimization operation, either 248 one of them SHOULD be exclusively applied. 250 5.1. Implicit Make-Before-Break Mode 252 This specifies the detailed procedure of M-B-B LSP restoration and 253 reoptimization using existing messages which are defined in [RFC8231] 254 . This procedure is based on the existing messages/TLVs and no 255 extensions are required. Once a PCC receives PCUpd message from a 256 PCE, the PCC automatically executes the implicit M-B-B procedure as 257 described in [RFC8231] Section 6.2. 259 First, A PCUpd message is sent from a PCE to trigger M-B-B 260 procedure. Once receiving the PCUpd message, the PCC starts 261 signaling a new restoration/reoptimization LSP and it replies back 262 to the PCE a PCRpt message with LSP-IDENTIFIERS TLV (with new LSP- 263 ID) in the LSP Object to notify the result of signaling. If the 264 new LSP failed to setup, the PCC sends to the PCE the detail of 265 the result in a PCErr or PCRpt message with the same SRP (Stateful 266 PCE Request Parameters) object as that of the PCUpd message and it 267 MAY wait for a next instruction from the PCE. 269 Second, once a new LSP is successfully established, a PCC 270 transfers data traffic from working LSP to new LSP automatically. 271 Finally, when a PCC successfully transferred data traffic to the 272 new LSP, the PCC tears down the (previous) working LSP by RSVP-TE 273 signaling, then the PCC sends another PCRpt message. That PCRpt 274 message carries a LSP Object with LSP-IDENTIFIERS TLV (with old 275 LSP-ID) which indicates the value of RSVP-TE signaling the PCC has 276 just torn down. As per [RFC8231], the message has to have SRP-ID 277 set to 0x00000000. 279 Following Figure 1 illustrates the example of implicit M-B-B 280 procedure, in following conditions. Tunnel ID and LSP ID are 281 included in an LSP Identifiers TLV in a LSP Object. 283 working LSP : ERO=a-b, Tunnel ID=T1, LSP ID=old, PLSP-ID=X 284 restoration LSP : ERO=a-c-b, Tunnel ID=T1, LSP ID=new, PLSP-ID=X 286 __c__ 287 / \ 288 PCE PCC(Ingress)--a-------b---Egress 289 | | | 290 | Data on old LSP =>)))))))))))))))))))))))| 291 | | : | 292 |--PCUpd(PLSP-ID=X,->| : | 293 | SRP-ID=Y, | | 294 | ERO=a-c-b) |---Path(ERO=a-c-b-, --> | 295 | | LSP ID new) | 296 | | | 297 | | <-----Resv-------------| 298 | <- PCRpt(PLSP-ID=X,| | 299 | O=Up, | | 300 | SRP-ID=Y, | | 301 | Tunnel ID=T1, | | 302 | LSP ID=new) | | 303 | | | 304 | | | 305 | Transfer data |))))))))))))))))))))))))| 306 | from old to new =>}}}}}}}}}}}}}}}}}}}}}}}}| 307 | | : | 308 | | : | 309 | |---PathTear(ERO=a-b, -> | 310 | | LSP ID old) | 311 | <- PCRpt(PLSP-ID=X,| | 312 | O=Dn,R=1, | | 313 | SRP-ID=0, | | 314 | Tunnel ID=T1, | | 315 | LSP ID=old) | | 317 O flag = Operational flag in LSP object. 318 R flag = Remove flag in LSP object. 320 Figure 1: Implicit Make-Before-Break Procedure 322 5.2. Explicit Make-Before-Break Mode 324 Comparing to the implicit M-B-B mode, explicit M-B-B mode allows a 325 PCE to control timing and sequence of subsequent make-before-break 326 steps. 328 As per [I-D.ietf-pce-association-group], LSPs are associated with 329 other LSPs with which they interact by adding them to a common 330 association group. In this draft, this grouping is used to define 331 associations between a set of LSPs. This document define one new 332 association type called "Explicit MBB Association Type" of value 333 TBD1. 335 Prior to start of explicit M-B-B mode, PCE makes an association 336 group for the working LSP by including the Association Object 337 (defined in [I-D.ietf-pce-association-group]) with "Explicit MBB 338 Association Type". This allows the PCEs to identify the LSP 339 belong to a Make-Before-Break association group. PCE may include 340 the TRIAL-LSP TLV that is defined in this document with D(Data 341 Switchover) and T(Trial LSP) flags set to 0 in Association Object. 342 This is a pre-requisite for the explicit M-B-B. 343 First step of the explicit M-B-B, the PCE triggers signaling of a 344 new LSP at the PCC by sending a PCUpd/PCInitiate message with T 345 flag in TRIAL-LSP TLV set to 1, in the ASSOCIATION Object. The 346 PCC sends a PCRpt message back to the PCE to notify the result of 347 the signaling of the new LSP. 348 Second, the PCE instructs the PCC to transfer data traffic from 349 old LSP to new LSP by sending a PCUpd message with D flag in 350 TRIAL-LSP TLV set to 1, in the ASSOCIATION Object. The PCC 351 automatically tears down the (previous) working LSP once the 352 traffic switchover successfully is executed. Then it sends back 353 to the PCE a PCRpt message to notify the result of the switchover. 354 [Editor's Note - The operator may want to separate the second step 355 into traffic switchover and tearing down old LSP. It is further 356 study about the separate operation of third step.] 358 The following subsections specify each Explicit Make-Before-Break 359 step in detail. 361 5.2.1. Initiate Association Group for old LSP 363 As a pre-requisite before starting explicit M-B-B, PCE makes an 364 association group for working LSP by sending PCUpd message that 365 contains ASSOCIATION object with TRIAL-LSP TLV with both D and T 366 flags set to zero. TRIAL-LSP TLV is optional in the ASSOCIATION 367 object at this step. 369 Figure 2 illustrates an example of working LSP (PLSP-ID P1, Tunnel ID 370 T1, LSP-ID old, Association Group ID G1 and ERO Ingress-a-b-Egress). 372 __c__ 373 / \ 374 PCE PCC(Ingress)--a-------b---Egress 375 | data traffic on old LSP | 376 | |))))))))))))))))))))))))| 377 |--PCUpd ------>| : | 378 | LSP Object | : | 379 | PLSP-ID=P1 | : | 380 | SRP-ID=S1 | : | 381 | LSP ID=old | | 382 | ASSOC Object | | 383 | Assoc-Type=MBB | | 384 | Assoc-ID=G1 | | 385 | +TRIAL-LSP TLV | | 386 | D-Flag=0 | | 387 | T-Flag=0 | | 388 | | | 390 Figure 2: Initiate Associate Group for old LSP 392 5.2.2. Establish new Trial LSP 394 As a first step of M-B-B procedure, a PCC establishes a new LSP for 395 restoration once PCC receives a PCInitiate/PCUpd message with T flag 396 (in TRIAL-LSP TLV) set to 1, in a ASSOCIATION Object from a PCE. We 397 call this newly established LSPs for restoration "trial LSP". A 398 trial LSP is signaled the same RSVP-TE Tunnel ID but different LSP ID 399 from active working LSP, and both the active working LSP and new 400 trial LSPs MUST be signaled with Shared Explicit style as describes 401 in [RFC3209]. 403 When a new trial LSP was signaled successfully, the PCC sends a PCRpt 404 message toward the PCE to notify the result. The PCRpt message from 405 the PCC MUST have the LSP object with LSP-IDENTIFIERS TLV that 406 indicates RSVP-TE Tunnel ID and LSP ID the PCC has just established. 408 If a new trial LSP failed to be established by some reason of RSVP-TE 409 signaling, the PCC MUST send to the PCE a PCRpt message carrying LSP- 410 IDENTIFIERS TLV and RSVP-ERROR-SPEC TLV as defined in [RFC8231] 411 Section 7.3.4. 413 A PCC SHOULD accept multiple PCInitiate/PCUpd messages with TRIAL-LSP 414 TLV in a ASSOCIATION Object. And a PCC SHOULD establish as many 415 trial lsps as the number of PCInitiate/PCUpd messages it receives. A 416 PCC may also choose to implement a limit on the number of such 417 PCInitiate/PCUpd message. 419 Figure 3 illustrates a example, working LSP(PLSP-ID P1, Tunnel ID T1, 420 LSP-ID old, ERO Ingress-a-b-Egress), trial LSP(PLSP-ID P1, Tunnel ID 421 T1, LSP-ID new, ERO Ingress-a-c-b-Egress). 423 __c__ 424 / \ 425 PCE PCC(Ingress)--a-------b---Egress 426 | data traffic on old LSP | 427 | | | 428 | PCInitiate/ |))))))))))))))))))))))))| 429 |--PCUpd ------>| : | 430 | LSP Object | : | 431 | PLSP-ID=P1 | : | 432 | SRP-ID=S2 | : | 433 | Tunnel ID=T1 | | 434 | LSP ID=0 | | 435 | ASSOC Object | | 436 | Assoc-Type=MBB | | 437 | Assoc-ID=G1 | | 438 | +TRIAL-LSP TLV | | 439 | D-Flag=0 | | 440 | T-Flag=1 | | 441 | ERO Obj=a-c-b | | 442 | | | 443 | |---Path(LSP ID=new, --> | 444 | | ERO=a-c-b) | 445 | | | 446 | | <----- Resv------------| 447 |<--PCRpt ---------| | 448 | LSP Object | : | 449 | PLSP-ID=P1 |))))))))))))))))))))))))| 450 | SRP-ID=S2 | : | 451 | Tunnel ID=T1 | : | 452 | LSP ID=new | : | 453 | ASSOC Object | : | 454 | Assoc-Type=MBB | : | 455 | Assoc-ID=G1 | : | 456 | +TRIAL-LSP TLV | : | 457 | D-Flag=0 | : | 458 | T-Flag=1 | : | 459 | RRO Obj=a-c-b | : | 460 | | | 462 Figure 3: Establish new LSP 464 5.2.3. Switchover Data Traffic triggered by a PCUpd message 466 As a second step, the PCC(Ingress) transfers data traffic from a 467 working LSP to a trial LSP. To specify desired LSP for transferring 468 data traffic, a PCUpd message from a PCE MUST have a TRIAL-LSP TLV 469 set D flag to 1, in a ASSOCIATION Object. 471 Data switchover happens from old LSP to new trial LSP, once PCC 472 receives a PCUpd message with D flag in TRIAL-LSP TLV set to 1 in the 473 ASSOCIATION object from a PCE. 475 The PCC SHOULD tear down the old working LSP and other trial LSPs 476 which the data traffic is no longer used immediately once the data 477 traffic successfully switched over (See Figure 4). 479 [Editor's Note - Another option would be, a PCC tears down old lsp 480 separately using mechanism in [RFC8281] for PCE-Initiated LSPs.] 482 The PCC sends to the PCE a PCRpt message to notify the removal of 483 both old LSP and other trial LSPs, which SRP-ID is set to 0x00000000. 485 __c__ 486 / \ 487 PCE PCC(Ingress)--a-------b---Egress 488 | | | 489 | |))))))))))))))))))))))))| data on old LSP 490 |--PCUpd ------> |))))))))))))))))))))))))| 491 | LSP Object |}}}}}}}}}}}}}}}}}}}}}}}}| data on new LSP 492 | PLSP ID=P1 |}}}}}}}}}}}}}}}}}}}}}}}}| 493 | SRP ID=S3 |}}}}}}}}}}}}}}}}}}}}}}}}| 494 | Tunnel ID=T1 | : | 495 | LSP ID=new | : | 496 | ASSOC Object | : | 497 | Assoc-Type=MBB | | 498 | Assoc-ID=G1 | | 499 | +TRIAL-LSP TLV | | 500 | D-Flag=1 | | 501 | T-Flag=0 | | 502 | | | 503 | <-- PCRpt --------| | 504 | LSP Object | | 505 | PLSP ID=P1 | | 506 | SRP ID=S3 | | 507 | Tunnel ID=T1 | | 508 | LSP ID=new | | 509 | |--PathTear(ERO a-b, -->| Tear down old 510 | | Tunnel=T1,LSP ID=old) | automatically 511 | | | 512 | <-- PCRpt(O=Dn,R=1,| | 513 | PLSP ID=P1 | | 514 | SRP ID=0 | | 515 | Tunnel ID=T1 | | 516 | LSP-ID=old) | | 517 | | | 518 | | | 520 O flag = Operational flag in LSP object. 521 R flag = Remove flag in LSP object. 523 Figure 4: Transfer data traffic from old LSP to new LSP 525 6. Protocol extension 526 6.1. Association group 528 As per [I-D.ietf-pce-association-group], LSPs are associated with 529 other LSPs with which they interact by adding them to a common 530 association group. The Association ID will be used to identify the 531 MBB group a set of LSPs belongs to. This document defines a new 532 Association type, based on the generic Association object - 534 o Association type = TBD1 ("Explicit MBB Association Type"). 536 [I-D.ietf-pce-association-group] specify the mechanism for the 537 capability advertisement of the association types supported by a PCEP 538 speaker by defining a ASSOC-Type-List TLV to be carried within an 539 OPEN object. This capability exchange for the association type 540 described in this document (i.e. Explicit MBB Association Type) MUST 541 be done before using the policy association, i.e., the PCEP speaker 542 MUST include the Explicit MBB Association Type (TBD1) in the ASSOC- 543 Type-List TLV before using this association type in the PCEP 544 messages. 546 This Association-Type is dynamic in nature and created by the PCC or 547 PCE for the LSPs belonging to the same TE tunnel (as described in 548 [RFC3209]) originating at the same head node and terminating at the 549 same destination. These associations are conveyed via PCEP messages 550 to the PCEP peer. Operator-configured Association Range MUST NOT be 551 set for this association-type and MUST be ignored. 553 6.2. Trial LSP TLV in ASSOCIATION Objects 555 This document defines a new TLV named TRIAL-LSP TLV which can be 556 optionally carried in the ASSOCIATION object. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type=TBD2 | Length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Flags |D|T| 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 5: TRIAL-LSP TLV format 568 TRIAL-LSP TLV is an optional TLV of the ASSOCIATION Object and is 569 used in a PCInitiate/PCUpd message especially to perform explicit 570 mode M-B-B. A PCC signals a trial LSP once it receives a PCUpd in 571 which ASSOCIATION object has a TRIAL-LSP TLV. 573 T(Trial LSP - 1 bit): This field MUST be set to 1 in a PCInitiate/ 574 PCUpd message when a PCE requests a PCC to signal new trial LSP. 575 It MUST be zero for a working LSP. 576 D(Data switchover - 1 bit): This field MUST be set to 1 in a PCUpd 577 message when a PCE requests a PCC to switchover data traffic for 578 new trial LSP. It MUST be zero otherwise. 579 Flags: None defined. MUST be set to zero. Ignored on receipt. 581 6.3. Optional TLVs 583 The MBB association group MAY carry some optional TLVs including but 584 not limited to: 586 o VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor 587 specific behavioral information,, described in [RFC7470]. 589 6.4. Error Handling 591 As per the processing rules specified in section 5.4 of 592 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 593 this association-type, it would return a PCErr message with Error- 594 Type 26 (Early allocation by IANA) "Association Error" and Error- 595 Value 1 "Association-type is not supported". 597 All LSPs (new or old) within this association MUST belong to the same 598 TE Tunnel (as described in [RFC3209]) and have the same source and 599 destination. If a PCEP speaker attempts to add an LSP to this 600 association and the Tunnel ID (as carried in LSP-IDENTIFIERS TLV 601 [RFC8231], with description as per [RFC3209]) or source or 602 destination of the LSP is different from the LSP(s) in the PPAG, the 603 PCC MUST send PCErr with Error-Type= 29 (Early allocation by IANA) 604 (Association Error) [I-D.ietf-pce-association-group] and Error-Value 605 = TBD (Tunnel ID or End points mismatch). 607 All processing as per section 5.4 of [I-D.ietf-pce-association-group] 608 continue to apply. 610 7. Security Considerations 612 This document defines one new type for association, which do not add 613 any new security concerns beyond those discussed in [RFC5440], 614 [RFC8231] and [I-D.ietf-pce-association-group] in itself. 616 8. IANA Considerations 617 8.1. PCEP TLV Indicators 619 This document defines the following new PCEP TLVs: 621 Value Meaning Reference 622 TBD2 TRIAL-LSP TLV This document 624 8.2. Association Object Type Indicator 626 This document defines the following new association type originally 627 defined in [I-D.ietf-pce-association-group]. 629 Value Name Reference 630 TBD1 MBB Association Type This document 632 9. Operational Considerations 634 9.1. Operation in multiple PCEs 636 In addition to basic operations under multiple PCEs as described in 637 [RFC8231], a PCC supports both types of M-B-B operations. 639 Implicit mode M-B-B requires only one PCUpd message to trigger M-B-B 640 process, therefore a PCC accepts a message from a primary PCE whom 641 the PCC delegates the LSPs to. An attempt to update parameters of a 642 non-delegated LSP results in the PCC sending a PCErr message as 643 defined in [RFC8231]. 645 Explicit mode M-B-B requires at least three PCUpd messages(1. for new 646 Association-Group creation, 2. for trial-LSP signaling, 3. for 647 traffic switchover) to trigger each subsequent step. All steps MUST 648 be taken by one primary PCE because state synchronization of trial- 649 LSPs between the primary and backup PCE may be complex. If the PCC 650 revokes LSP delegations after a Redelegation Timeout Interval, the 651 PCC MUST tear down all trial-LSPs and redelegate a working LSP to 652 alternate PCE. An attempt to trigger either step of explicit mode 653 M-B-B of a non-delegated LSP results in the PCC sending the same 654 PCErr as implicit mode M-B-B. 656 10. Acknowledgments 658 Many thanks to Ina Minei, Adrian Farrel, Yimin Shen, and Xian Zhang 659 for their ideas and feedback in documentation. 661 11. References 663 11.1. Normative References 665 [I-D.ietf-pce-association-group] 666 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 667 Dhody, D., and Y. Tanaka, "PCEP Extensions for 668 Establishing Relationships Between Sets of LSPs", draft- 669 ietf-pce-association-group-06 (work in progress), June 670 2018. 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, 674 DOI 10.17487/RFC2119, March 1997, 675 . 677 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 678 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 679 DOI 10.17487/RFC5440, March 2009, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017, . 686 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 687 Computation Element Communication Protocol (PCEP) 688 Extensions for Stateful PCE", RFC 8231, 689 DOI 10.17487/RFC8231, September 2017, 690 . 692 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 693 Computation Element Communication Protocol (PCEP) 694 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 695 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 696 . 698 11.2. Informative References 700 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 701 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 702 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 703 . 705 [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, 706 Ed., "Generalized Multi-Protocol Label Switching (GMPLS) 707 Recovery Functional Specification", RFC 4426, 708 DOI 10.17487/RFC4426, March 2006, 709 . 711 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 712 (Protection and Restoration) Terminology for Generalized 713 Multi-Protocol Label Switching (GMPLS)", RFC 4427, 714 DOI 10.17487/RFC4427, March 2006, 715 . 717 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 718 Constraints in the Path Computation Element Communication 719 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 720 . 722 Authors' Addresses 724 Yosuke Tanaka 725 NTT Communications Corporation 726 Granpark Tower 727 3-4-1 Shibaura, Minato-ku 728 Tokyo 108-8118 729 Japan 731 Email: yosuke.tanaka@ntt.com 733 Yuji Kamite 734 NTT Communications Corporation 735 Granpark Tower 736 3-4-1 Shibaura, Minato-ku 737 Tokyo 108-8118 738 Japan 740 Email: y.kamite@ntt.com 742 Dhruv Dhody 743 Huawei Technologies 744 Divyashree Techno Park, Whitefield 745 Bangalore, Karnataka 560066 746 India 748 Email: dhruv.ietf@gmail.com 749 Ramanjaneya Reddy Palleti 750 Huawei Technologies 751 Divyashree Techno Park, Whitefield 752 Bangalore, Karnataka 560066 753 India 755 Email: ramanjaneya.palleti@huawei.com