idnits 2.17.1 draft-ietf-pce-association-bidir-12.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 (February 05, 2021) is 1174 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 (-23) exists of draft-ietf-pce-pcep-stateful-pce-gmpls-14 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-13) exists of draft-ietf-pce-sr-bidir-path-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group R. Gandhi, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track C. Barth 5 Expires: August 9, 2021 Juniper Networks 6 B. Wen 7 Comcast 8 February 05, 2021 10 Path Computation Element Communication Protocol (PCEP) Extensions for 11 Associated Bidirectional Label Switched Paths (LSPs) 12 draft-ietf-pce-association-bidir-12 14 Abstract 16 This document defines Path Computation Element Communication Protocol 17 (PCEP) extensions for grouping two unidirectional MPLS-TE Label 18 Switched Paths (LSPs), one in each direction in the network, into an 19 Associated Bidirectional LSP. The mechanisms defined in this 20 document can be applied using a Stateful PCE for both PCE-Initiated 21 and PCC-Initiated LSPs, as well as when using a Stateless PCE. The 22 procedures defined are applicable to the LSPs using RSVP-TE for 23 signaling. 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 August 9, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 61 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 65 3.1.1. PCE-Initiated Single-sided Bidirectional LSP . . . . 5 66 3.1.2. PCC-Initiated Single-sided Bidirectional LSP . . . . 6 67 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7 68 3.2.1. PCE-Initiated Double-sided Bidirectional LSP . . . . 7 69 3.2.2. PCC-Initiated Double-sided Bidirectional LSP . . . . 8 70 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 9 71 3.4. Summary of PCEP Extensions . . . . . . . . . . . . . . . 10 72 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 10 74 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 12 75 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 13 77 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 14 78 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 15 79 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 15 80 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 15 81 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 16 82 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 83 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 84 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 17 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 8. Manageability Considerations . . . . . . . . . . . . . . . . 18 87 8.1. Control of Function and Policy . . . . . . . . . . . . . 18 88 8.2. Information and Data Models . . . . . . . . . . . . . . . 18 89 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 90 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 91 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 18 92 8.6. Impact On Network Operations . . . . . . . . . . . . . . 18 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 9.1. Association Types . . . . . . . . . . . . . . . . . . . . 19 95 9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 19 96 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 19 98 9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 20 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 10.2. Informative References . . . . . . . . . . . . . . . . . 22 102 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 105 1. Introduction 107 [RFC5440] describes the Path Computation Element Communication 108 Protocol (PCEP) as a communication mechanism between a Path 109 Computation Client (PCC) and a Path Control Element (PCE), or between 110 PCE and PCC, that enables computation of Multiprotocol Label 111 Switching (MPLS) - Traffic Engineering (TE) Label Switched Paths 112 (LSPs). 114 [RFC8231] specifies extensions to PCEP to enable stateful control of 115 MPLS-TE LSPs. It describes two modes of operation - Passive Stateful 116 PCE and Active Stateful PCE. In [RFC8231], the focus is on Active 117 Stateful PCE where LSPs are provisioned on the PCC and control over 118 them is delegated to a PCE. Further, [RFC8281] describes the setup, 119 maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE 120 model. 122 [RFC8697] introduces a generic mechanism to create a grouping of 123 LSPs. This grouping can then be used to define associations between 124 sets of LSPs or between a set of LSPs and a set of attributes, and it 125 is equally applicable to the stateful PCE (active and passive modes) 126 and the stateless PCE. 128 The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] 129 specifies that "MPLS-TP MUST support unidirectional, co-routed 130 bidirectional, and associated bidirectional point-to-point transport 131 paths". [RFC7551] defines RSVP signaling extensions for binding 132 forward and reverse unidirectional LSPs into an associated 133 bidirectional LSP. The fast reroute (FRR) procedures for associated 134 bidirectional LSPs are described in [RFC8537]. 136 This document defines PCEP extensions for grouping two unidirectional 137 MPLS-TE LSPs into an Associated Bidirectional LSP for both single- 138 sided and double-sided initiation cases when using a Stateful PCE for 139 both PCE-Initiated and PCC-Initiated LSPs as well as when using a 140 Stateless PCE. The procedures defined are applicable to the LSPs 141 using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 142 for signaling [RFC3209]. Specifically, this document defines two new 143 Association Types, "Single-sided Bidirectional LSP Association" and 144 "Double-sided Bidirectional LSP Association", as well as 145 "Bidirectional LSP Association Group TLV" to carry additional 146 information for the association. 148 The procedure for associating two unidirectional Segment Routing (SR) 149 Paths to form an Associated Bidirectional SR Path is defined in 150 [I-D.ietf-pce-sr-bidir-path], and is outside the scope of this 151 document. 153 2. Conventions Used in This Document 155 2.1. Key Word Definitions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119] [RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 2.2. Terminology 165 The reader is assumed to be familiar with the terminology defined in 166 [RFC5440], [RFC7551], [RFC8231], and [RFC8697]. 168 3. Overview 170 As shown in Figure 1, forward and reverse unidirectional LSPs can be 171 grouped to form an associated bidirectional LSP. The node A is 172 ingress node for LSP1 and egress node for LSP2, whereas node D is 173 ingress node for LSP2 and egress node for LSP1. There are two 174 methods of initiating the bidirectional LSP association, single-sided 175 and double-sided, as defined in [RFC7551] and described in the 176 following sections. 178 LSP1 --> LSP1 --> LSP1 --> 179 +-----+ +-----+ +-----+ +-----+ 180 | A +-----------+ B +-----------+ C +-----------+ D | 181 +-----+ +--+--+ +--+--+ +-----+ 182 <-- LSP2 | | <-- LSP2 183 | | 184 | | 185 +--+--+ +--+--+ 186 | E +-----------+ F | 187 +-----+ +-----+ 188 <-- LSP2 190 Figure 1: Example of Associated Bidirectional LSP 192 3.1. Single-sided Initiation 194 As specified in [RFC7551], in the single-sided case, the 195 bidirectional tunnel is provisioned only on one endpoint node (PCC) 196 of the tunnel. Both endpoint nodes act as PCCs. Both forward and 197 reverse LSPs of this tunnel are initiated with the Association Type 198 set to "Single-sided Bidirectional LSP Association" on the 199 originating endpoint node. The forward and reverse LSPs are 200 identified in the "Bidirectional LSP Association Group TLV" of their 201 PCEP ASSOCIATION Objects. 203 The originating endpoint node signals the properties for the reverse 204 LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path 205 message. The remote endpoint node then creates the corresponding 206 reverse tunnel and reverse LSP, and signals the reverse LSP in 207 response to the received RSVP-TE Path message. Similarly, the remote 208 endpoint node deletes the reverse LSP when it receives the RSVP-TE 209 message to delete the forward LSP [RFC3209]. 211 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 212 the LSP starting from the originating endpoint node is identified as 213 the forward LSP of the single-sided initiated bidirectional LSP. 215 3.1.1. PCE-Initiated Single-sided Bidirectional LSP 216 +-----+ 217 | PCE | 218 +-----+ 219 Initiates: | \ 220 Tunnel 1 (F) | \ 221 (LSP1 (F, 0), LSP2 (R, 0)) | \ 222 Association #1 v \ 223 +-----+ +-----+ 224 | A | | D | 225 +-----+ +-----+ 227 +-----+ 228 | PCE | 229 +-----+ 230 Reports: ^ ^ Reports: 231 Tunnel 1 (F) | \ Tunnel 2 (F) 232 (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) 233 Association #1 | \ Association #1 234 +-----+ +-----+ 235 | A | | D | 236 +-----+ +-----+ 238 Legends: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs 240 Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP 242 As shown in Figure 2, the forward tunnel 1 and both forward LSP1 and 243 reverse LSP2 are initiated on the originating endpoint node A by the 244 PCE. The PLSP-IDs used are P1 and P2 on the originating endpoint 245 node A and P3 on the remote endpoint node D. The originating 246 endpoint node A reports tunnels 1 and forward LSP1 and reverse LSP2 247 to the PCE. The endpoint (PCC) node D reports tunnel 2 and LSP2 to 248 the PCE. The endpoint (PCC) node D also reports the reverse LSP1 249 (not shown for simplicity) to the PCE. 251 3.1.2. PCC-Initiated Single-sided Bidirectional LSP 252 +-----+ 253 | PCE | 254 +-----+ 255 Reports/Delegates: ^ ^ Reports: 256 Tunnel 1 (F) | \ Tunnel 2 (F) 257 (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) 258 Association #2 | \ Association #2 259 +-----+ +-----+ 260 | A | | D | 261 +-----+ +-----+ 263 Legends: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs 265 Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP 267 As shown in Figure 3, the forward tunnel 1 and both forward LSP1 and 268 reverse LSP2 are initiated on the originating endpoint node A (the 269 originating PCC). The PLSP-IDs used are P1 and P2 on the originating 270 endpoint node A and P3 on the remote endpoint node D. The 271 originating endpoint (PCC) node A may delegate the forward LSP1 and 272 reverse LSP2 to the PCE. The originating endpoint node A reports 273 tunnels 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint 274 (PCC) node D reports tunnel 2 and LSP2 to the PCE. The endpoint 275 (PCC) node D also reports the reverse LSP1 (not shown for simplicity) 276 to the PCE. 278 3.2. Double-sided Initiation 280 As specified in [RFC7551], in the double-sided case, the 281 bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of 282 the tunnel. The forward and reverse LSPs of this tunnel are 283 initiated with the Association Type set to "Double-sided 284 Bidirectional LSP Association" on both endpoint nodes. The forward 285 and reverse LSPs are identified in the "Bidirectional LSP Association 286 Group TLV" of their ASSOCIATION Objects. 288 As specified in [RFC8537], for fast reroute bypass tunnel assignment, 289 the LSP with the higher Source Address [RFC3209] is identified as the 290 forward LSP of the double-sided initiated bidirectional LSP. 292 3.2.1. PCE-Initiated Double-sided Bidirectional LSP 293 +-----+ 294 | PCE | 295 +-----+ 296 Initiates: | \ Initiates: 297 Tunnel 1 (F) | \ Tunnel 2 (F) 298 (LSP1 (F, 0)) | \ (LSP2 (F, 0)) 299 Association #3 v v Association #3 300 +-----+ +-----+ 301 | A | | D | 302 +-----+ +-----+ 304 +-----+ 305 | PCE | 306 +-----+ 307 Reports: ^ ^ Reports: 308 Tunnel 1 (F) | \ Tunnel 2 (F) 309 (LSP1 (F, P4)) | \ (LSP2 (F, P5)) 310 Association #3 | \ Association #3 311 +-----+ +-----+ 312 | A | | D | 313 +-----+ +-----+ 315 Legends: F = Forward LSP, (0,P4,P5) = PLSP-IDs 317 Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP 319 As shown in Figure 4, the forward tunnel 1 and forward LSP1 are 320 initiated on the endpoint node A and the reverse tunnel 2 and reverse 321 LSP2 are initiated on the endpoint node D by the PCE. The PLSP-IDs 322 used are P4 on the endpoint node A and P5 on the endpoint node D. 323 The endpoint node A (PCC) reports the forward LSP1 and endpoint node 324 D reports the forward LSP2 to the PCE. Both endpoint (PCC) nodes 325 also report the reverse LSPs (not shown for simplicity) to the PCE. 327 3.2.2. PCC-Initiated Double-sided Bidirectional LSP 328 +-----+ 329 | PCE | 330 +-----+ 331 Reports/Delegates: ^ ^ Reports/Delegates: 332 Tunnel 1 (F) | \ Tunnel 2 (F) 333 (LSP1 (F, P4)) | \ (LSP2 (F, P5)) 334 Association #4 | \ Association #4 335 +-----+ +-----+ 336 | A | | D | 337 +-----+ +-----+ 339 Legends: F = Forward LSP, (P4,P5) = PLSP-IDs 341 Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP 343 As shown in Figure 5, the forward tunnel 1 and forward LSP1 are 344 initiated on the endpoint node A and the reverse tunnel 2 and reverse 345 LSP2 are initiated on the endpoint node D (the PCCs). The PLSP-IDs 346 used are P4 on the endpoint node A and P5 on the endpoint node D. 347 Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to 348 the PCE. The endpoint node A (PCC) reports the forward LSP1 and 349 endpoint node D reports the forward LSP2 to the PCE. Both endpoint 350 (PCC) nodes also report the reverse LSPs (not shown for simplicity) 351 to the PCE. 353 3.3. Co-routed Associated Bidirectional LSP 355 In both single-sided and double-sided initiation cases, forward and 356 reverse LSPs can be co-routed as shown in Figure 6, where both 357 forward and reverse LSPs of a bidirectional LSP follow the same 358 congruent path in the forward and reverse directions, respectively. 360 LSP3 --> LSP3 --> LSP3 --> 361 +-----+ +-----+ +-----+ +-----+ 362 | A +-----------+ B +-----------+ C +-----------+ D | 363 +-----+ +-----+ +-----+ +-----+ 364 <-- LSP4 <-- LSP4 <-- LSP4 366 Figure 6: Example of Co-routed Associated Bidirectional LSP 368 The procedure specified in [RFC8537] for fast reroute bypass tunnel 369 assignment is also applicable to the Co-routed Associated 370 Bidirectional LSPs. 372 3.4. Summary of PCEP Extensions 374 The PCEP extensions defined in this document cover the following 375 modes of operations under the stateful PCE model: 377 o A PCC initiates the forward and reverse LSP of a Single-sided 378 Bidirectional LSP and retains the control of the LSPs. Similarly, 379 both PCCs initiate the forward LSPs of a Double-sided 380 Bidirectional LSP and retain the control of the LSPs. The PCC 381 computes the path itself or makes a request for path computation 382 to a PCE. After the path setup, it reports the information and 383 state of the path to the PCE. This includes the association group 384 identifying the bidirectional LSP. This is the Passive Stateful 385 mode defined in [RFC8051]. 387 o A PCC initiates the forward and reverse LSP of a Single-sided 388 Bidirectional LSP and delegates the control of the LSPs to a 389 Stateful PCE. Similarly, both PCCs initiate the forward LSPs of a 390 Double-sided Bidirectional LSP and delegate the control of the 391 LSPs to a Stateful PCE. During delegation the association group 392 identifying the bidirectional LSP is included. The PCE computes 393 the path of the LSP and updates the PCC with the information about 394 the path as long as it controls the LSP. This is the Active 395 Stateful mode defined in [RFC8051]. 397 o A PCE initiates the forward and reverse LSP of a Single-sided 398 Bidirectional LSP on a PCC and retains the control of the LSP. 399 Similarly, a PCE initiates the forward LSPs of a Double-sided 400 Bidirectional LSP on both PCCs and retains the control of the 401 LSPs. The PCE is responsible for computing the path of the LSP 402 and updating the PCC with the information about the path as well 403 as the association group identifying the bidirectional LSP. This 404 is the PCE-Initiated mode defined in [RFC8281]. 406 o A PCC requests co-routed or non-co-routed paths for forward and 407 reverse LSPs of a bidirectional LSP including when using a 408 Stateless PCE [RFC5440]. 410 4. Protocol Extensions 412 4.1. ASSOCIATION Object 414 As per [RFC8697], LSPs are associated by adding them to a common 415 association group. This document defines two new Association Types, 416 called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided 417 Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object 418 ((Object-Class value 40). A member of the Bidirectional LSP 419 Association can take the role of a forward or reverse LSP and follows 420 the following rules: 422 o An LSP (forward or reverse) MUST NOT be part of more than one 423 Bidirectional LSP Association. 425 o The LSPs in a Bidirectional LSP Association MUST have matching 426 endpoint nodes in the reverse directions. 428 o The Tunnel (as defined in [RFC3209]) containing the forward and 429 reverse LSPs of the Single-sided Bidirectional LSP Association on 430 the originating node MUST have the same LSP parameters (as 431 described in section 3.1.1 of [RFC3209]), albeit both LSPs have 432 reversed endpoint nodes. 434 The Bidirectional LSP Association types are considered to be both 435 dynamic and operator-configured in nature. As per [RFC8697], the 436 association group could be manually created by the operator on the 437 PCEP peers, and the LSPs belonging to this association are conveyed 438 via PCEP messages to the PCEP peer; alternately, the association 439 group could be created dynamically by the PCEP speaker, and both the 440 association group information and the LSPs belonging to the 441 association group are conveyed to the PCEP peer. The Operator- 442 configured Association Range MUST be set for this association-type to 443 mark a range of Association Identifiers that are used for operator- 444 configured associations to avoid any Association Identifier clash 445 within the scope of the Association Source (Refer to [RFC8697]). 447 Specifically, for the PCE Initiated Bidirectional LSPs, these 448 Associations are dynamically created by the PCE on the PCE peers. 449 Similarly, for both PCE Initiated and PCC Initiated single-sided 450 case, these associations are also dynamically created on the remote 451 endpoint node using the information received from the RSVP message 452 from the originating node. 454 The Association ID, Association Source, optional Global Association 455 Source and optional Extended Association ID in the Bidirectional LSP 456 Association Object are initialized using the procedures defined in 457 [RFC8697] and [RFC7551]. 459 [RFC8697] specifies the mechanism for the capability advertisement of 460 the Association Types supported by a PCEP speaker by defining an 461 ASSOC-Type-List TLV to be carried within an OPEN Object. This 462 capability exchange for the Bidirectional LSP Association Types MUST 463 be done before using the Bidirectional LSP Association. Thus, the 464 PCEP speaker MUST include the Bidirectional LSP Association Types in 465 the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer 466 before using the Bidirectional LSP Association in PCEP messages. 468 4.2. Bidirectional LSP Association Group TLV 470 The "Bidirectional LSP Association Group TLV" is an OPTIONAL TLV for 471 use with the Bidirectional LSP Associations (ASSOCIATION Object with 472 Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for 473 Double-sided Bidirectional LSP). 475 o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV 476 format from [RFC5440]. 478 o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. 480 o The Length is 4 Bytes. 482 o The value comprises of a single field, the Bidirectional LSP 483 Association Flag (32 bits), where each bit represents a flag 484 option. 486 o If the "Bidirectional LSP Association Group TLV" is missing, it 487 means the LSP is the forward LSP and it is not co-routed LSP. 489 o When "Bidirectional LSP Association Group TLV" is present, the F 490 flag MUST be set for the forward LSP for both co-routed and non 491 co-routed LSPs. 493 o For co-routed LSPs, this TLV MUST be present and C flag set. 495 o For reverse LSPs, this TLV MUST be present and R flag set. 497 o The "Bidirectional LSP Association Group TLV" MUST NOT be present 498 more than once. If it appears more than once, only the first 499 occurrence is processed and any others MUST be ignored. 501 The format of the "Bidirectional LSP Association Group TLV" is shown 502 in Figure 7: 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type = TBD3 | Length | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Flags |C|R|F| 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 Figure 7: Bidirectional LSP Association Group TLV format 514 Flags for "Bidirectional LSP Association Group TLV" are defined as 515 following. 517 F (Forward LSP, 1 bit, Bit number 31) - Indicates whether the LSP 518 associated is the forward LSP of the bidirectional LSP. If this flag 519 is set, the LSP is a forward LSP. 521 R (Reverse LSP, 1 bit, Bit number 30) - Indicates whether the LSP 522 associated is the reverse LSP of the bidirectional LSP. If this flag 523 is set, the LSP is a reverse LSP. 525 C (Co-routed Path, 1 bit, Bit number 29) - Indicates whether the 526 bidirectional LSP is co-routed. This flag MUST be set for both the 527 forward and reverse LSPs of a co-routed bidirectional LSP. 529 The C flag is used by the PCE (for both Stateful and Stateless) to 530 compute bidirectional paths of the forward and reverse LSPs of a co- 531 routed bidirectional LSP. 533 The unassigned flags (Bit Number 0-28) MUST be set to 0 when sent and 534 MUST be ignored when received. 536 5. PCEP Procedure 538 The PCEP procedure defined in this document is applicable to the 539 following three scenarios: 541 o Neither unidirectional LSP exists, and both must be established. 543 o Both unidirectional LSPs exist, but the association must be 544 established. 546 o One LSP exists, but the reverse associated LSP must be 547 established. 549 5.1. PCE Initiated LSPs 551 As specified in [RFC8697], the Bidirectional LSP Associations can be 552 created and updated by a Stateful PCE. 554 o For Single-sided Bidirectional LSP Association initiated by the 555 PCE, it MUST send PCInitiate message to the originating endpoint 556 node with both direction LSPs. For Double-sided Bidirectional LSP 557 Association initiated by the PCE, it MUST send PCInitiate message 558 to both endpoint nodes with forward direction LSPs. 560 o Both PCCs MUST report the forward and reverse LSPs in the 561 Bidirectional LSP Association to the PCE. PCC reports via PCRpt 562 message. 564 o Stateful PCE MAY create and update the forward and reverse LSPs 565 independently for the Single-sided Bidirectional LSP Association 566 on the originating endpoint node. 568 o Stateful PCE MAY create and update the forward LSP independently 569 for the Double-sided Bidirectional LSP Association on the endpoint 570 nodes. 572 o Stateful PCE establishes and removes the association relationship 573 on a per LSP basis. 575 o Stateful PCE creates and updates the LSP and the association on a 576 PCC via PCInitiate and PCUpd messages, respectively, using the 577 procedures described in [RFC8697]. 579 5.2. PCC Initiated LSPs 581 As specified in [RFC8697], the Bidirectional LSP Associations can 582 also be created and updated by a PCC. 584 o For Single-sided Bidirectional LSP Association initiated at a PCC, 585 it MUST send PCRpt message to the PCE with both direction LSPs. 586 For Double-sided Bidirectional LSP Association initiated at the 587 PCCs, both PCCs MUST send PCRpt message to the PCE with forward 588 direction LSPs. 590 o PCC on the originating endpoint node MAY create and update the 591 forward and reverse LSPs independently for the Single-sided 592 Bidirectional LSP Association. 594 o PCC on the endpoint nodes MAY create and update the forward LSP 595 independently for the Double-sided Bidirectional LSP Association. 597 o PCC establishes and removes the association group on a per LSP 598 basis. PCC MUST report the change in the association group of an 599 LSP to PCE(s) via PCRpt message. 601 o PCC reports the forward and reverse LSPs in the Bidirectional LSP 602 Association independently to PCE(s) via PCRpt message. 604 o PCC for the single-sided case MAY delegate the forward and reverse 605 LSPs independently to a Stateful PCE, where PCE would control the 606 LSPs. In this case, the originating (PCC) endpoint node SHOULD 607 delegate both forward and reverse LSPs of a tunnel together to a 608 Stateful PCE in order to avoid any race condition. 610 o PCCs for the double-sided case MAY delegate the forward LSPs to a 611 Stateful PCE, where PCE would control the LSPs. 613 o Stateful PCE updates the LSPs in the Bidirectional LSP Association 614 via PCUpd message, using the procedures described in [RFC8697]. 616 5.3. Stateless PCE 618 For a stateless PCE, it might be useful to associate a path 619 computation request to an association group, thus enabling it to 620 associate a common set of configuration parameters or behaviors with 621 the request [RFC8697]. A PCC can request co-routed or non-co-routed 622 forward and reverse direction paths from a stateless PCE for a 623 Bidirectional LSP Association. 625 5.4. Bidirectional (B) Flag 627 As defined in [RFC5440], the Bidirectional (B) flag in the Request 628 Parameters (RP) Object is set when the PCC specifies that the path 629 computation request is for a bidirectional TE LSP with the same TE 630 requirements in each direction. For an associated bidirectional LSP, 631 the B-flag is also set when the PCC makes the path computation 632 request for the same TE requirements for the forward and reverse 633 direction LSPs. 635 Note that the B-flag defined in Stateful PCE Request Parameter (SRP) 636 Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate 637 'bidirectional co-routed LSP' is used for GMPLS signaled 638 bidirectional LSPs and is not applicable to the associated 639 bidirectional LSPs. 641 5.5. PLSP-ID Usage 643 As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 644 created by a PCC to uniquely identify an LSP and it remains the same 645 for the lifetime of a PCEP session. 647 In case of Single-sided Bidirectional LSP Association, the reverse 648 LSP of a bidirectional LSP created on the originating endpoint node 649 is identified by the PCE using 2 different PLSP-IDs based on the PCEP 650 session on the ingress or egress nodes for the LSP. In other words, 651 the reverse LSP will have a PLSP-ID P1 at the ingress node while it 652 will have a PLSP-ID P3 at the egress node. There is no change in the 653 PLSP-ID allocation procedure for the forward LSP of the Single-sided 654 Bidirectional LSP on the originating endpoint node. In case of 655 Double-sided Bidirectional LSP Association, there is no change in the 656 PLSP-ID allocation procedure. 658 For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] 659 MUST be included in all forward and reverse LSPs. 661 5.6. State Synchronization 663 During state synchronization, a PCC MUST report all the existing 664 Bidirectional LSP Associations to the Stateful PCE as per [RFC8697]. 665 After the state synchronization, the PCE MUST remove all previous 666 Bidirectional LSP Associations absent in the report. 668 5.7. Error Handling 670 If a PCE speaker receives an LSP with a Bidirectional LSP Association 671 Type that it does not support, the PCE speaker MUST send PCErr with 672 Error-Type = 26 (Association Error) and Error-Value = 1 (Association 673 Type is not supported). 675 An LSP (forward or reverse) cannot be part of more than one 676 Bidirectional LSP Association. If a PCE speaker receives an LSP not 677 complying to this rule, the PCE speaker MUST send PCErr with Error- 678 Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional 679 LSP Association - Group Mismatch). 681 The LSPs (forward or reverse) in a Single-sided Bidirectional 682 Association MUST belong to the same TE Tunnel (as defined in 683 [RFC3209]). If a PCE speaker attempts to add an LSP in a Single- 684 sided Bidirectional LSP Association for a different Tunnel, the PCE 685 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 686 Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). 688 The PCEP Path Setup Type (PST) for RSVP-TE is set to 'Path is set up 689 using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP 690 speaker receives a different PST value for the Bidirectional LSP 691 Associations defined in this document, the PCE speaker MUST return a 692 PCErr message with Error-Type = 26 (Association Error) and Error- 693 Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not 694 Supported). 696 A Bidirectional LSP Association cannot have both unidirectional LSPs 697 identified as Reverse LSPs or both LSPs identified as Forward LSPs. 698 If a PCE speaker receives an LSP not complying to this rule, the PCE 699 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 700 Error-Value = TBD7 (Bidirectional LSP Association - Direction 701 Mismatch). 703 A Bidirectional LSP Association cannot have one unidirectional LSP 704 identified as co-routed and the other identified as non-co-routed. 705 If a PCE speaker receives an LSP not complying to this rule, the PCE 706 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 707 Error-Value = TBD8 (Bidirectional LSP Association - Co-routed 708 Mismatch). 710 The unidirectional LSPs forming the Bidirectional LSP Association 711 MUST have matching endpoint nodes in the reverse directions. If a 712 PCE speaker receives an LSP not complying to this rule, the PCE 713 speaker MUST send PCErr with Error-Type = 26 (Association Error) and 714 Error-Value = TBD9 (Bidirectional LSP Association - Endpoint 715 Mismatch). 717 The processing rules as specified in Section 6.4 of [RFC8697] 718 continue to apply to the Association Types defined in this document. 720 6. Implementation Status 722 [Note to the RFC Editor - remove this section before publication, as 723 well as remove the reference to RFC 7942.] 725 This section records the status of known implementations of the 726 protocol defined by this specification at the time of posting of this 727 Internet-Draft, and is based on a proposal described in [RFC7942]. 728 The description of implementations in this section is intended to 729 assist the IETF in its decision processes in progressing drafts to 730 RFCs. Please note that the listing of any individual implementation 731 here does not imply endorsement by the IETF. Furthermore, no effort 732 has been spent to verify the information presented here that was 733 supplied by IETF contributors. This is not intended as, and must not 734 be construed to be, a catalog of available implementations or their 735 features. Readers are advised to note that other implementations may 736 exist. 738 According to [RFC7942], "this will allow reviewers and working groups 739 to assign due consideration to documents that have the benefit of 740 running code, which may serve as evidence of valuable experimentation 741 and feedback that have made the implemented protocols more mature. 742 It is up to the individual working groups to use this information as 743 they see fit". 745 6.1. Implementation 747 The PCEP extensions defined in this document has been implemented by 748 a vendor on their product. No further information is available at 749 this time. 751 7. Security Considerations 753 The security considerations described in [RFC5440], [RFC8231], and 754 [RFC8281] apply to the extensions defined in this document as well. 756 Two new Association Types for the ASSOCIATION Object, Single-sided 757 Bidirectional LSP Association and Double-sided Bidirectional LSP 758 Association are introduced in this document. Additional security 759 considerations related to LSP associations due to a malicious PCEP 760 speaker is described in [RFC8697] and apply to these Association 761 Types. Hence, securing the PCEP session using Transport Layer 762 Security (TLS) [RFC8253] is RECOMMENDED. 764 8. Manageability Considerations 766 8.1. Control of Function and Policy 768 The mechanisms defined in this document do not imply any control or 769 policy requirements in addition to those already listed in [RFC5440], 770 [RFC8231], and [RFC8281]. 772 8.2. Information and Data Models 774 [RFC7420] describes the PCEP MIB, there are no new MIB Objects 775 defined for LSP associations. 777 The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for 778 LSP associations. 780 8.3. Liveness Detection and Monitoring 782 The mechanisms defined in this document do not imply any new liveness 783 detection and monitoring requirements in addition to those already 784 listed in [RFC5440], [RFC8231], and [RFC8281]. 786 8.4. Verify Correct Operations 788 The mechanisms defined in this document do not imply any new 789 operation verification requirements in addition to those already 790 listed in [RFC5440], [RFC8231], and [RFC8281]. 792 8.5. Requirements On Other Protocols 794 The mechanisms defined in this document do not add any new 795 requirements on other protocols. 797 8.6. Impact On Network Operations 799 The mechanisms defined in this document do not have any impact on 800 network operations in addition to those already listed in [RFC5440], 801 [RFC8231], and [RFC8281]. 803 9. IANA Considerations 805 9.1. Association Types 807 This document defines two new Association Types, originally described 808 in [RFC8697]. IANA is requested to assign the following new values 809 in the "ASSOCIATION Type Field" subregistry [RFC8697] within the 810 "Path Computation Element Protocol (PCEP) Numbers" registry: 812 Type Name Reference 813 --------------------------------------------------------------------- 814 TBD1 Single-sided Bidirectional LSP Association [This document] 815 TBD2 Double-sided Bidirectional LSP Association [This document] 817 9.2. Bidirectional LSP Association Group TLV 819 This document defines a new TLV for carrying additional information 820 of LSPs within a Bidirectional LSP Association. IANA is requested to 821 add the assignment of a new value in the existing "PCEP TLV Type 822 Indicators" registry as follows: 824 Value Meaning Reference 825 ------------------------------------------------------------------- 826 TBD3 Bidirectional LSP Association Group TLV [This document] 828 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 830 This document requests that a new sub-registry, named "Bidirectional 831 LSP Association Group TLV Flag Field", is created within the "Path 832 Computation Element Protocol (PCEP) Numbers" registry to manage the 833 Flag field in the Bidirectional LSP Association Group TLV. New 834 values are to be assigned by Standards Action [RFC8126]. Each bit 835 should be tracked with the following qualities: 837 o Bit number (count from 0 as the most significant bit) 839 o Description 841 o Reference 843 The following values are defined in this document for the Flag field. 845 Bit No. Description Reference 846 --------------------------------------------------------- 847 31 F - Forward LSP [This document] 848 30 R - Reverse LSP [This document] 849 29 C - Co-routed Path [This document] 850 0-28 Unassigned 852 9.3. PCEP Errors 854 This document defines new Error value for Error Type 26 (Association 855 Error). IANA is requested to allocate new Error value within the 856 "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP 857 Numbers registry, as follows: 859 Error Type Description Reference 860 --------------------------------------------------------- 861 26 Association Error 863 Error value: TBD4 [This document] 864 Bidirectional LSP Association - Group Mismatch 866 Error value: TBD5 [This document] 867 Bidirectional LSP Association - Tunnel Mismatch 869 Error value: TBD6 [This document] 870 Bidirectional LSP Association - Path Setup Type 871 Not Supported 873 Error value: TBD7 [This document] 874 Bidirectional LSP Association - Direction Mismatch 876 Error value: TBD8 [This document] 877 Bidirectional LSP Association - Co-routed Mismatch 879 Error value: TBD9 [This document] 880 Bidirectional LSP Association - Endpoint Mismatch 882 10. References 884 10.1. Normative References 886 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, 888 DOI 10.17487/RFC2119, March 1997, 889 . 891 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 892 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 893 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 894 . 896 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 897 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 898 DOI 10.17487/RFC5440, March 2009, 899 . 901 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 902 Extensions for Associated Bidirectional Label Switched 903 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 904 . 906 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 907 Writing an IANA Considerations Section in RFCs", BCP 26, 908 RFC 8126, DOI 10.17487/RFC8126, June 2017, 909 . 911 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 912 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 913 May 2017, . 915 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 916 Computation Element Communication Protocol (PCEP) 917 Extensions for Stateful PCE", RFC 8231, 918 DOI 10.17487/RFC8231, September 2017, 919 . 921 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 922 Computation Element Communication Protocol (PCEP) 923 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 924 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 925 . 927 [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to 928 the Fast Reroute Procedures for Co-routed Associated 929 Bidirectional Label Switched Paths (LSPs)", RFC 8537, 930 DOI 10.17487/RFC8537, February 2019, 931 . 933 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 934 Dhody, D., and Y. Tanaka, "Path Computation Element 935 Communication Protocol (PCEP) Extensions for Establishing 936 Relationships between Sets of Label Switched Paths 937 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 938 . 940 10.2. Informative References 942 [I-D.ietf-pce-pcep-stateful-pce-gmpls] 943 Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path 944 Computation Element (PCE) Protocol Extensions for Stateful 945 PCE Usage in GMPLS-controlled Networks", draft-ietf-pce- 946 pcep-stateful-pce-gmpls-14 (work in progress), December 947 2020. 949 [I-D.ietf-pce-pcep-yang] 950 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 951 YANG Data Model for Path Computation Element 952 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 953 yang-15 (work in progress), October 2020. 955 [I-D.ietf-pce-sr-bidir-path] 956 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 957 "Path Computation Element Communication Protocol (PCEP) 958 Extensions for Associated Bidirectional Segment Routing 959 (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in 960 progress), January 2021. 962 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 963 Sprecher, N., and S. Ueno, "Requirements of an MPLS 964 Transport Profile", RFC 5654, DOI 10.17487/RFC5654, 965 September 2009, . 967 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 968 Hardwick, "Path Computation Element Communication Protocol 969 (PCEP) Management Information Base (MIB) Module", 970 RFC 7420, DOI 10.17487/RFC7420, December 2014, 971 . 973 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 974 Code: The Implementation Status Section", BCP 205, 975 RFC 7942, DOI 10.17487/RFC7942, July 2016, 976 . 978 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 979 Stateful Path Computation Element (PCE)", RFC 8051, 980 DOI 10.17487/RFC8051, January 2017, 981 . 983 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 984 "PCEPS: Usage of TLS to Provide a Secure Transport for the 985 Path Computation Element Communication Protocol (PCEP)", 986 RFC 8253, DOI 10.17487/RFC8253, October 2017, 987 . 989 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 990 Hardwick, "Conveying Path Setup Type in PCE Communication 991 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 992 July 2018, . 994 Acknowledgments 996 The authors would like to thank Dhruv Dhody for various discussions 997 on association groups and inputs to this document. The authors would 998 also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and 999 Marina Fizgeer for reviewing this document and providing valuable 1000 comments. 1002 Authors' Addresses 1004 Rakesh Gandhi (editor) 1005 Cisco Systems, Inc. 1006 Canada 1008 Email: rgandhi@cisco.com 1010 Colby Barth 1011 Juniper Networks 1013 Email: cbarth@juniper.net 1015 Bin Wen 1016 Comcast 1018 Email: Bin_Wen@cable.comcast.com