diff options
Diffstat (limited to 'doc/rfc/rfc9059.txt')
| -rw-r--r-- | doc/rfc/rfc9059.txt | 1035 |
1 files changed, 1035 insertions, 0 deletions
diff --git a/doc/rfc/rfc9059.txt b/doc/rfc/rfc9059.txt new file mode 100644 index 0000000..704ab63 --- /dev/null +++ b/doc/rfc/rfc9059.txt @@ -0,0 +1,1035 @@ + + + + +Internet Engineering Task Force (IETF) R. Gandhi, Ed. +Request for Comments: 9059 Cisco Systems, Inc. +Category: Standards Track C. Barth +ISSN: 2070-1721 Juniper Networks + B. Wen + Comcast + June 2021 + + + Path Computation Element Communication Protocol (PCEP) Extensions for + Associated Bidirectional Label Switched Paths (LSPs) + +Abstract + + This document defines Path Computation Element Communication Protocol + (PCEP) extensions for grouping two unidirectional MPLS-TE Label + Switched Paths (LSPs), one in each direction in the network, into an + associated bidirectional LSP. These PCEP extensions can be applied + either using a stateful PCE for both PCE-initiated and PCC-initiated + LSPs or using a stateless PCE. The PCEP procedures defined are + applicable to the LSPs using RSVP-TE for signaling. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9059. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions Used in This Document + 2.1. Key Word Definitions + 2.2. Terminology + 3. Overview + 3.1. Single-Sided Initiation + 3.1.1. PCE-Initiated Single-Sided Bidirectional LSP + 3.1.2. PCC-Initiated Single-Sided Bidirectional LSP + 3.2. Double-Sided Initiation + 3.2.1. PCE-Initiated Double-Sided Bidirectional LSP + 3.2.2. PCC-Initiated Double-Sided Bidirectional LSP + 3.3. Co-routed Associated Bidirectional LSP + 3.4. Summary of PCEP Extensions + 3.5. Operational Considerations + 4. Protocol Extensions + 4.1. ASSOCIATION Object + 4.2. Bidirectional LSP Association Group TLV + 5. PCEP Procedure + 5.1. PCE-Initiated LSPs + 5.2. PCC-Initiated LSPs + 5.3. Stateless PCE + 5.4. Bidirectional (B) Flag + 5.5. PLSP-ID Usage + 5.6. State Synchronization + 5.7. Error Handling + 6. Security Considerations + 7. Manageability Considerations + 7.1. Control of Function and Policy + 7.2. Information and Data Models + 7.3. Liveness Detection and Monitoring + 7.4. Verify Correct Operations + 7.5. Requirements on Other Protocols + 7.6. Impact on Network Operations + 8. IANA Considerations + 8.1. Association Types + 8.2. Bidirectional LSP Association Group TLV + 8.2.1. Flag Field in Bidirectional LSP Association Group TLV + 8.3. PCEP Errors + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + [RFC5440] describes the Path Computation Element Communication + Protocol (PCEP) as a communication mechanism between a Path + Computation Client (PCC) and a Path Computation Element (PCE), or + between PCE and PCC, that enables computation of Multiprotocol Label + Switching (MPLS) - Traffic Engineering (TE) Label Switched Paths + (LSPs). + + [RFC8231] specifies extensions to PCEP to enable stateful control of + MPLS-TE LSPs. It describes two modes of operation: passive stateful + PCE and active stateful PCE. In [RFC8231], the focus is on active + stateful PCE where LSPs are provisioned on the PCC and control over + them is delegated to a PCE. Further, [RFC8281] describes the setup, + maintenance, and teardown of PCE-initiated LSPs for the stateful PCE + model. + + [RFC8697] introduces a generic mechanism for creating a grouping of + LSPs. This grouping can then be used to define associations between + sets of LSPs or between a set of LSPs and a set of attributes, and it + is equally applicable to the stateful PCE (active and passive modes) + and the stateless PCE. + + The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] + specifies that "MPLS-TP MUST support unidirectional, co-routed + bidirectional, and associated bidirectional point-to-point transport + paths". [RFC7551] defines RSVP signaling extensions for binding + forward and reverse unidirectional LSPs into an associated + bidirectional LSP. The fast reroute (FRR) procedures for associated + bidirectional LSPs are described in [RFC8537]. + + This document defines PCEP extensions for grouping two unidirectional + MPLS-TE LSPs into an associated bidirectional LSP for both single- + sided and double-sided initiation cases either when using a stateful + PCE for both PCE-initiated and PCC-initiated LSPs or when using a + stateless PCE. The procedures defined are applicable to the LSPs + using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) + for signaling [RFC3209]. Specifically, this document defines two new + Association Types, Single-Sided Bidirectional LSP Association and + Double-Sided Bidirectional LSP Association, as well as the + Bidirectional LSP Association Group TLV, to carry additional + information for the association. + + The procedure for associating two unidirectional Segment Routing (SR) + paths to form an associated bidirectional SR path is defined in + [BIDIR-PATH] and is outside the scope of this document. + +2. Conventions Used in This Document + +2.1. Key Word Definitions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.2. Terminology + + The reader is assumed to be familiar with the terminology defined in + [RFC5440], [RFC7551], [RFC8231], and [RFC8697]. + +3. Overview + + As shown in Figure 1, forward and reverse unidirectional LSPs can be + grouped to form an associated bidirectional LSP. Node A is the + ingress node for LSP1 and egress node for LSP2, whereas node D is the + ingress node for LSP2 and egress node for LSP1. There are two + methods of initiating the Bidirectional LSP Association, single-sided + and double-sided, as defined in [RFC7551] and described in the + following sections. + + LSP1 --> LSP1 --> LSP1 --> + +-----+ +-----+ +-----+ +-----+ + | A +-----------+ B +-----------+ C +-----------+ D | + +-----+ +--+--+ +--+--+ +-----+ + <-- LSP2 | | <-- LSP2 + | | + | | + +--+--+ +--+--+ + | E +-----------+ F | + +-----+ +-----+ + <-- LSP2 + + Figure 1: Example of Associated Bidirectional LSP + +3.1. Single-Sided Initiation + + As specified in [RFC7551], in the single-sided case, the + bidirectional tunnel is provisioned only on one endpoint node (PCC) + of the tunnel. Both endpoint nodes act as PCCs. Both forward and + reverse LSPs of this tunnel are initiated with the Association Type + set to "Single-Sided Bidirectional LSP Association" on the + originating endpoint node. The forward and reverse LSPs are + identified in the Bidirectional LSP Association Group TLV of their + PCEP ASSOCIATION objects. + + The originating endpoint node signals the properties for the reverse + LSP in the RSVP REVERSE_LSP object [RFC7551] of the forward LSP Path + message. The remote endpoint node then creates the corresponding + reverse tunnel and reverse LSP, and it then signals the reverse LSP + in response to the received RSVP-TE Path message. Similarly, the + remote endpoint node deletes the reverse LSP when it receives the + RSVP-TE message to delete the forward LSP [RFC3209]. + + As specified in [RFC8537], for fast reroute bypass tunnel assignment, + the LSP starting from the originating endpoint node is identified as + the forward LSP of the single-sided initiated bidirectional LSP. + +3.1.1. PCE-Initiated Single-Sided Bidirectional LSP + + +-----+ + | PCE | + +-----+ + Initiates: | \ + Tunnel 1 (F) | \ + (LSP1 (F, 0), LSP2 (R, 0)) | \ + Association #1 v \ + +-----+ +-----+ + | A | | D | + +-----+ +-----+ + + + +-----+ + | PCE | + +-----+ + Reports: ^ ^ Reports: + Tunnel 1 (F) | \ Tunnel 2 (F) + (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) + Association #1 | \ Association #1 + +-----+ +-----+ + | A | | D | + +-----+ +-----+ + + Legend: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs + + Figure 2: Example of PCE-Initiated Single-Sided Bidirectional LSP + + Using partial topology from Figure 1, as shown in Figure 2, the + forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated + on the originating endpoint node A by the PCE. The PCEP-specific LSP + identifiers (PLSP-IDs) used are P1 and P2 on the originating endpoint + node A and P3 on the remote endpoint node D. The originating + endpoint node A reports Tunnel 1 and forward LSP1 and reverse LSP2 to + the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the + PCE. + +3.1.2. PCC-Initiated Single-Sided Bidirectional LSP + + +-----+ + | PCE | + +-----+ + Reports/Delegates: ^ ^ Reports: + Tunnel 1 (F) | \ Tunnel 2 (F) + (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) + Association #2 | \ Association #2 + +-----+ +-----+ + | A | | D | + +-----+ +-----+ + + Legend: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs + + Figure 3: Example of PCC-Initiated Single-Sided Bidirectional LSP + + Using partial topology from Figure 1, as shown in Figure 3, the + forward Tunnel 1 and both forward LSP1 and reverse LSP2 are initiated + on the originating endpoint node A (the originating PCC). The PLSP- + IDs used are P1 and P2 on the originating endpoint node A and P3 on + the remote endpoint node D. The originating endpoint (PCC) node A + may delegate the forward LSP1 and reverse LSP2 to the PCE. The + originating endpoint node A reports Tunnel 1 and forward LSP1 and + reverse LSP2 to the PCE. The endpoint (PCC) node D reports Tunnel 2 + and LSP2 to the PCE. + +3.2. Double-Sided Initiation + + As specified in [RFC7551], in the double-sided case, the + bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of + the tunnel. The forward and reverse LSPs of this tunnel are + initiated with the Association Type set to "Double-Sided + Bidirectional LSP Association" on both endpoint nodes. The forward + and reverse LSPs are identified in the Bidirectional LSP Association + Group TLV of their ASSOCIATION objects. + + As specified in [RFC8537], for fast reroute bypass tunnel assignment, + the LSP with the higher source address [RFC3209] is identified as the + forward LSP of the double-sided initiated bidirectional LSP. + +3.2.1. PCE-Initiated Double-Sided Bidirectional LSP + + +-----+ + | PCE | + +-----+ + Initiates: | \ Initiates: + Tunnel 1 (F) | \ Tunnel 2 (F) + (LSP1 (F, 0)) | \ (LSP2 (F, 0)) + Association #3 v v Association #3 + +-----+ +-----+ + | A | | D | + +-----+ +-----+ + + + +-----+ + | PCE | + +-----+ + Reports: ^ ^ Reports: + Tunnel 1 (F) | \ Tunnel 2 (F) + (LSP1 (F, P4)) | \ (LSP2 (F, P5)) + Association #3 | \ Association #3 + +-----+ +-----+ + | A | | D | + +-----+ +-----+ + + Legend: F = Forward LSP, (0,P4,P5) = PLSP-IDs + + Figure 4: Example of PCE-Initiated Double-Sided Bidirectional LSP + + Using partial topology from Figure 1, as shown in Figure 4, the + forward Tunnel 1 and forward LSP1 are initiated on the endpoint node + A, and the reverse Tunnel 2 and reverse LSP2 are initiated on the + endpoint node D by the PCE. The PLSP-IDs used are P4 on the endpoint + node A and P5 on the endpoint node D. The endpoint node A (PCC) + reports the forward LSP1, and endpoint node D reports the forward + LSP2 to the PCE. + +3.2.2. PCC-Initiated Double-Sided Bidirectional LSP + + +-----+ + | PCE | + +-----+ + Reports/Delegates: ^ ^ Reports/Delegates: + Tunnel 1 (F) | \ Tunnel 2 (F) + (LSP1 (F, P4)) | \ (LSP2 (F, P5)) + Association #4 | \ Association #4 + +-----+ +-----+ + | A | | D | + +-----+ +-----+ + + Legend: F = Forward LSP, (P4,P5) = PLSP-IDs + + Figure 5: Example of PCC-Initiated Double-Sided Bidirectional LSP + + Using partial topology from Figure 1, as shown in Figure 5, the + forward Tunnel 1 and forward LSP1 are initiated on the endpoint node + A, and the reverse Tunnel 2 and reverse LSP2 are initiated on the + endpoint node D (the PCCs). The PLSP-IDs used are P4 on the endpoint + node A and P5 on the endpoint node D. Both endpoint (PCC) nodes may + delegate the forward LSP1 and LSP2 to the PCE. The endpoint node A + (PCC) reports the forward LSP1, and endpoint node D reports the + forward LSP2 to the PCE. + +3.3. Co-routed Associated Bidirectional LSP + + In both single-sided and double-sided initiation cases, forward and + reverse LSPs can be co-routed as shown in Figure 6, where both + forward and reverse LSPs of a bidirectional LSP follow the same + congruent path in the forward and reverse directions, respectively. + + LSP3 --> LSP3 --> LSP3 --> + +-----+ +-----+ +-----+ +-----+ + | A +-----------+ B +-----------+ C +-----------+ D | + +-----+ +-----+ +-----+ +-----+ + <-- LSP4 <-- LSP4 <-- LSP4 + + Figure 6: Example of Co-routed Associated Bidirectional LSP + + The procedure specified in [RFC8537] for fast reroute bypass tunnel + assignment is also applicable to the co-routed associated + bidirectional LSPs. + +3.4. Summary of PCEP Extensions + + The PCEP extensions defined in this document cover the following + modes of operation under the stateful PCE model: + + * A PCC initiates the forward and reverse LSP of a single-sided + bidirectional LSP and retains control of the LSPs. Similarly, + both PCCs initiate the forward LSPs of a double-sided + bidirectional LSP and retain control of the LSPs. The PCC + computes the path itself or makes a request for path computation + to a PCE. After the path setup, it reports the information and + state of the path to the PCE. This includes the association group + identifying the bidirectional LSP. This is the passive stateful + mode defined in [RFC8051]. + + * A PCC initiates the forward and reverse LSP of a single-sided + bidirectional LSP and delegates control of the LSPs to a stateful + PCE. Similarly, both PCCs initiate the forward LSPs of a double- + sided bidirectional LSP and delegate control of the LSPs to a + stateful PCE. During delegation, the association group + identifying the bidirectional LSP is included. The PCE computes + the path of the LSP and updates the PCC with the information about + the path as long as it controls the LSP. This is the active + stateful mode defined in [RFC8051]. + + * A PCE initiates the forward and reverse LSP of a single-sided + bidirectional LSP on a PCC and retains control of the LSP. + Similarly, a PCE initiates the forward LSPs of a double-sided + bidirectional LSP on both PCCs and retains control of the LSPs. + The PCE is responsible for computing the path of the LSP and + updating the PCC with the information about the path as well as + the association group identifying the bidirectional LSP. This is + the PCE-initiated mode defined in [RFC8281]. + + * A PCC requests co-routed or non-co-routed paths for forward and + reverse LSPs of a bidirectional LSP, including when using a + stateless PCE [RFC5440]. + +3.5. Operational Considerations + + The double-sided case has an advantage when compared to the single- + sided case, summarized as follows: + + * In the double-sided case, two existing unidirectional LSPs in + reverse directions in the network can be associated to form a + bidirectional LSP without significantly increasing the operational + complexity. + + The single-sided case has some advantages when compared to the + double-sided case, summarized as follows: + + * Some Operations, Administration, and Maintenance (OAM) use cases + may require an endpoint node to know both forward and reverse + paths for monitoring the bidirectional LSP. For such use cases, + the single-sided case may be preferred. + + * For co-routed associated bidirectional LSPs in PCC-initiated mode, + the single-sided case allows the originating PCC to dynamically + compute co-routed forward and reverse paths. This may not be + possible with the double-sided case where the forward and reverse + paths are computed separately as triggered by two different PCCs. + + * The associated bidirectional LSPs in the single-sided case can be + deployed in a network where PCEP is only enabled on the + originating endpoint nodes as remote endpoint nodes create the + reverse tunnels using RSVP-TE Path messages. + +4. Protocol Extensions + +4.1. ASSOCIATION Object + + As per [RFC8697], LSPs are associated by adding them to a common + association group. This document defines two new Association Types, + called "Single-Sided Bidirectional LSP Association" (4) and "Double- + Sided Bidirectional LSP Association" (5), using the generic + ASSOCIATION object (Object-Class value 40). A member of the + Bidirectional LSP Association can take the role of a forward or + reverse LSP and follows the following rules: + + * An LSP (forward or reverse) MUST NOT be part of more than one + Bidirectional LSP Association. + + * The LSPs in a Bidirectional LSP Association MUST have matching + endpoint nodes in the reverse directions. + + * The same tunnel (as defined in Section 2.1 of [RFC3209]) MUST + contain the forward and reverse LSPs of the Single-Sided + Bidirectional LSP Association on the originating node, albeit both + LSPs have reversed endpoint nodes. + + The Bidirectional LSP Association Types are considered to be both + dynamic and operator configured in nature. As per [RFC8697], the + association group could be manually created by the operator on the + PCEP peers, and the LSPs belonging to this association are conveyed + via PCEP messages to the PCEP peer; alternately, the association + group could be created dynamically by the PCEP speaker, and both the + association group information and the LSPs belonging to the + association group are conveyed to the PCEP peer. The operator- + configured Association Range MUST be set for this Association Type to + mark a range of Association Identifiers that are used for operator- + configured associations to avoid any Association Identifier clash + within the scope of the Association Source (refer to [RFC8697]). + + Specifically, for the PCE-initiated bidirectional LSPs, these + associations are dynamically created by the PCE on the PCE peers. + Similarly, for both the PCE-initiated and the PCC-initiated single- + sided cases, these associations are also dynamically created on the + remote endpoint node using the information received from the RSVP + message from the originating node. + + The Association ID, Association Source, optional Global Association + Source TLV, and optional Extended Association ID TLV in the + Bidirectional LSP ASSOCIATION object are initialized using the + procedures defined in [RFC8697] and [RFC7551]. + + [RFC8697] specifies the mechanism for the capability advertisement of + the Association Types supported by a PCEP speaker by defining an + ASSOC-Type-List TLV to be carried within an OPEN object. This + capability exchange for the Bidirectional LSP Association Types MUST + be done before using the Bidirectional LSP Association. Thus, the + PCEP speaker MUST include the Bidirectional LSP Association Types in + the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer + before using the Bidirectional LSP Association in PCEP messages. + +4.2. Bidirectional LSP Association Group TLV + + The Bidirectional LSP Association Group TLV is an OPTIONAL TLV for + use with Bidirectional LSP Associations (ASSOCIATION object with + Association Type 4 for Single-Sided Bidirectional LSP Association or + 5 for Double-Sided Bidirectional LSP Association). + + * The Bidirectional LSP Association Group TLV follows the PCEP TLV + format from [RFC5440]. + + * The Type (16 bits) of the TLV is 54. + + * The Length is 4 bytes. + + * The value comprises of a single field, the Flags field (32 bits), + where each bit represents a flag option. + + * If the Bidirectional LSP Association Group TLV is missing, it + means the LSP is the forward LSP, and it is not a co-routed LSP. + + * When the Bidirectional LSP Association Group TLV is present, the R + flag MUST be reset for the forward LSP for both co-routed and non- + co-routed LSPs. + + * For co-routed LSPs, this TLV MUST be present and the C flag set. + + * For reverse LSPs, this TLV MUST be present and the R flag set. + + * The Bidirectional LSP Association Group TLV MUST NOT be present + more than once. If it appears more than once, only the first + occurrence is processed, and any others MUST be ignored. + + The format of the Bidirectional LSP Association Group TLV is shown in + Figure 7. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 54 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags |C|R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Bidirectional LSP Association Group TLV Format + + Flags for the Bidirectional LSP Association Group TLV are defined as + follows. + + R (Reverse LSP, 1 bit, bit number 31): Indicates whether the LSP + associated is the reverse LSP of the bidirectional LSP. If this + flag is set, the LSP is a reverse LSP. If this flag is not set, + the LSP is a forward LSP. + + C (Co-routed Path, 1 bit, bit number 30): Indicates whether the + bidirectional LSP is co-routed. This flag MUST be set for both + the forward and reverse LSPs of a co-routed bidirectional LSP. + + The C flag is used by the PCE (both stateful and stateless) to + compute bidirectional paths of the forward and reverse LSPs of a co- + routed bidirectional LSP. + + The unassigned flags (bit numbers 0-29) MUST be set to 0 when sent + and MUST be ignored when received. + +5. PCEP Procedure + + The PCEP procedure defined in this document is applicable to the + following three scenarios: + + * Neither unidirectional LSP exists, and both must be established. + + * Both unidirectional LSPs exist, but the association must be + established. + + * One LSP exists, but the reverse associated LSP must be + established. + +5.1. PCE-Initiated LSPs + + As specified in [RFC8697], Bidirectional LSP Associations can be + created and updated by a stateful PCE. + + * For a Single-Sided Bidirectional LSP Association initiated by the + PCE, the PCE MUST send a PCInitiate message to the originating + endpoint node with both forward and reverse LSPs. For a Double- + Sided Bidirectional LSP Association initiated by the PCE, it MUST + send a PCInitiate message to both endpoint nodes with forward + LSPs. + + * Both PCCs MUST report the forward and reverse LSPs in the + Bidirectional LSP Association to the PCE. A PCC reports via a + PCRpt message. + + * Stateful PCEs MAY create and update the forward and reverse LSPs + independently for the Single-Sided Bidirectional LSP Association + on the originating endpoint node. + + * Stateful PCEs MAY create and update the forward LSP independently + for the Double-Sided Bidirectional LSP Association on the endpoint + nodes. + + * Stateful PCEs establish and remove the association relationship on + a per-LSP basis. + + * Stateful PCEs create and update the LSP and the association on + PCCs via PCInitiate and PCUpd messages, respectively, using the + procedures described in [RFC8697]. + +5.2. PCC-Initiated LSPs + + As specified in [RFC8697], Bidirectional LSP Associations can also be + created and updated by a PCC. + + * For a Single-Sided Bidirectional LSP Association initiated at a + PCC, the PCC MUST send a PCRpt message to the PCE with both + forward and reverse LSPs. For a Double-Sided Bidirectional LSP + Association initiated at the PCCs, both PCCs MUST send a PCRpt + message to the PCE with forward LSPs. + + * PCCs on the originating endpoint node MAY create and update the + forward and reverse LSPs independently for the Single-Sided + Bidirectional LSP Association. + + * PCCs on the endpoint nodes MAY create and update the forward LSP + independently for the Double-Sided Bidirectional LSP Association. + + * PCCs establish and remove the association group on a per-LSP + basis. PCCs MUST report the change in the association group of an + LSP to PCE(s) via a PCRpt message. + + * PCCs report the forward and reverse LSPs in the Bidirectional LSP + Association independently to PCE(s) via a PCRpt message. + + * PCCs for the single-sided case MAY delegate the forward and + reverse LSPs independently to a stateful PCE, where the PCE would + control the LSPs. In this case, the originating (PCC) endpoint + node SHOULD delegate both forward and reverse LSPs of a tunnel + together to a stateful PCE in order to avoid any race condition. + + * PCCs for the double-sided case MAY delegate the forward LSPs to a + stateful PCE, where the PCE would control the LSPs. + + * A stateful PCE updates the LSPs in the Bidirectional LSP + Association via a PCUpd message, using the procedures described in + [RFC8697]. + +5.3. Stateless PCE + + For a stateless PCE, it might be useful to associate a path + computation request to an association group, thus enabling it to + associate a common set of configuration parameters or behaviors with + the request [RFC8697]. A PCC can request co-routed or non-co-routed + forward and reverse paths from a stateless PCE for a Bidirectional + LSP Association. + +5.4. Bidirectional (B) Flag + + As defined in [RFC5440], the Bidirectional (B) flag in the Request + Parameters (RP) object is set when the PCC specifies that the path + computation request is for a bidirectional TE LSP with the same TE + requirements in each direction. For an associated bidirectional LSP, + the B flag is also set when the PCC makes the path computation + request for the same TE requirements for the forward and reverse + LSPs. + + Note that the B flag defined in a Stateful PCE Request Parameter + (SRP) object [STATEFUL-PCE-GMPLS] to indicate "bidirectional co- + routed LSP" is used for GMPLS-signaled bidirectional LSPs and is not + applicable to the associated bidirectional LSPs. + +5.5. PLSP-ID Usage + + As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is + created by a PCC to uniquely identify an LSP, and it remains the same + for the lifetime of a PCEP session. + + In the case of a Single-Sided Bidirectional LSP Association, the + reverse LSP of a bidirectional LSP created on the originating + endpoint node is identified by the PCE using two different PLSP-IDs, + based on the PCEP session on the ingress or egress node PCCs for the + LSP. In other words, the LSP will have a PLSP-ID P2 allocated at the + ingress node PCC, while it will have a PLSP-ID P3 allocated at the + egress node PCC (as shown in Figures 2 and 3). There is no change in + the PLSP-ID allocation procedure for the forward LSP of a single- + sided bidirectional LSP created on the originating endpoint node. + + In the case of a Double-Sided Bidirectional LSP Association, there is + no change in the PLSP-ID allocation procedure for the forward LSPs on + either PCC. + + For an associated bidirectional LSP, the LSP-IDENTIFIERS TLV + [RFC8231] MUST be included in all forward and reverse LSPs. + +5.6. State Synchronization + + During state synchronization, a PCC MUST report all the existing + Bidirectional LSP Associations to the stateful PCE, as per [RFC8697]. + After the state synchronization, the PCE MUST remove all previous + Bidirectional LSP Associations absent in the report. + +5.7. Error Handling + + If a PCE speaker receives an LSP with a Bidirectional LSP Association + Type that it does not support, the PCE speaker MUST send PCErr with + Error-Type = 26 (Association Error) and Error-value = 1 (Association + Type is not supported). + + An LSP (forward or reverse) cannot be part of more than one + Bidirectional LSP Association. If a PCE speaker receives an LSP not + complying to this rule, the PCE speaker MUST send PCErr with Error- + Type = 26 (Association Error) and Error-value = 14 (Association group + mismatch). + + The LSPs (forward or reverse) in a Single-Sided Bidirectional + Association MUST belong to the same TE tunnel (as defined in + [RFC3209]). If a PCE speaker attempts to add an LSP in a Single- + Sided Bidirectional LSP Association for a different tunnel, the PCE + speaker MUST send PCErr with Error-Type = 26 (Association Error) and + Error-value = 15 (Tunnel mismatch in the association group). + + The PCEP Path Setup Type (PST) for RSVP-TE is set to "Path is set up + using the RSVP-TE signaling protocol" (Value 0) [RFC8408]. If a PCEP + speaker receives a different PST value for the Bidirectional LSP + Associations defined in this document, the PCE speaker MUST return a + PCErr message with Error-Type = 26 (Association Error) and Error- + value = 16 (Path Setup Type not supported). + + A Bidirectional LSP Association cannot have both unidirectional LSPs + identified as reverse LSPs or both LSPs identified as forward LSPs. + If a PCE speaker receives an LSP not complying to this rule, the PCE + speaker MUST send PCErr with Error-Type = 26 (Association Error) and + Error-value = 17 (Bidirectional LSP direction mismatch). + + A Bidirectional LSP Association cannot have one unidirectional LSP + identified as co-routed and the other identified as non-co-routed. + If a PCE speaker receives an LSP not complying to this rule, the PCE + speaker MUST send PCErr with Error-Type = 26 (Association Error) and + Error-value = 18 (Bidirectional LSP co-routed mismatch). + + The unidirectional LSPs forming the Bidirectional LSP Association + MUST have matching endpoint nodes in the reverse directions. If a + PCE speaker receives an LSP not complying to this rule, the PCE + speaker MUST send PCErr with Error-Type = 26 (Association Error) and + Error-value = 19 (Endpoint mismatch in the association group). + + The processing rules as specified in Section 6.4 of [RFC8697] + continue to apply to the Association Types defined in this document. + +6. Security Considerations + + The security considerations described in [RFC5440], [RFC8231], and + [RFC8281] apply to the extensions defined in this document as well. + + Two new Association Types for the ASSOCIATION object, Single-Sided + Bidirectional LSP Association and Double-Sided Bidirectional LSP + Association, are introduced in this document. Additional security + considerations related to LSP associations due to a malicious PCEP + speaker are described in [RFC8697] and apply to these Association + Types. Hence, securing the PCEP session using Transport Layer + Security (TLS) [RFC8253] is RECOMMENDED. + +7. Manageability Considerations + +7.1. Control of Function and Policy + + The mechanisms defined in this document do not imply any control or + policy requirements in addition to those already listed in [RFC5440], + [RFC8231], and [RFC8281]. + +7.2. Information and Data Models + + [RFC7420] describes the PCEP MIB; there are no new MIB objects + defined for LSP associations. + + The PCEP YANG module [PCE-PCEP-YANG] defines a data model for LSP + associations. + +7.3. Liveness Detection and Monitoring + + The mechanisms defined in this document do not imply any new liveness + detection and monitoring requirements in addition to those already + listed in [RFC5440], [RFC8231], and [RFC8281]. + +7.4. Verify Correct Operations + + The mechanisms defined in this document do not imply any new + operation verification requirements in addition to those already + listed in [RFC5440], [RFC8231], and [RFC8281]. + +7.5. Requirements on Other Protocols + + The mechanisms defined in this document do not add any new + requirements on other protocols. + +7.6. Impact on Network Operations + + The mechanisms defined in this document do not have any impact on + network operations in addition to those already listed in [RFC5440], + [RFC8231], and [RFC8281]. + +8. IANA Considerations + +8.1. Association Types + + This document defines two new Association Types [RFC8697]. IANA has + assigned the following new values in the "ASSOCIATION Type Field" + subregistry [RFC8697] within the "Path Computation Element Protocol + (PCEP) Numbers" registry: + + +======+============================================+===========+ + | Type | Name | Reference | + +======+============================================+===========+ + | 4 | Single-Sided Bidirectional LSP Association | RFC 9059 | + +------+--------------------------------------------+-----------+ + | 5 | Double-Sided Bidirectional LSP Association | RFC 9059 | + +------+--------------------------------------------+-----------+ + + Table 1: Additions to ASSOCIATION Type Field Subregistry + +8.2. Bidirectional LSP Association Group TLV + + This document defines a new TLV for carrying additional information + about LSPs within a Bidirectional LSP Association. IANA has assigned + the following value in the "PCEP TLV Type Indicators" subregistry + within the "Path Computation Element Protocol (PCEP) Numbers" + registry: + + +=======+=========================================+===========+ + | Value | Meaning | Reference | + +=======+=========================================+===========+ + | 54 | Bidirectional LSP Association Group TLV | RFC 9059 | + +-------+-----------------------------------------+-----------+ + + Table 2: Addition to PCEP TLV Type Indicators Subregistry + +8.2.1. Flag Field in Bidirectional LSP Association Group TLV + + IANA has created a new subregistry, named "Bidirectional LSP + Association Group TLV Flag Field", within the "Path Computation + Element Protocol (PCEP) Numbers" registry to manage the Flag field in + the Bidirectional LSP Association Group TLV. New values are assigned + by Standards Action [RFC8126]. Each bit should be tracked with the + following qualities: + + * Bit number (count from 0 as the most significant bit) + + * Description + + * Reference + + The initial contents of this registry are as follows: + + +======+====================+===========+ + | Bit | Description | Reference | + +======+====================+===========+ + | 0-29 | Unassigned | | + +------+--------------------+-----------+ + | 30 | C - Co-routed Path | RFC 9059 | + +------+--------------------+-----------+ + | 31 | R - Reverse LSP | RFC 9059 | + +------+--------------------+-----------+ + + Table 3: New Bidirectional LSP + Association Group TLV Flag Field + Subregistry + +8.3. PCEP Errors + + This document defines new Error-values for Error-Type 26 (Association + Error). IANA has allocated the following new Error-values within the + "PCEP-ERROR Object Error Types and Values" subregistry of the "Path + Computation Element Protocol (PCEP) Numbers" registry: + + +============+=============+==========================+===========+ + | Error-Type | Meaning | Error-value | Reference | + +============+=============+==========================+===========+ + | 26 | Association | 14: Association group | RFC 9059 | + | | Error | mismatch | | + | | +--------------------------+-----------+ + | | | 15: Tunnel mismatch in | RFC 9059 | + | | | the association group | | + | | +--------------------------+-----------+ + | | | 16: Path Setup Type not | RFC 9059 | + | | | supported | | + | | +--------------------------+-----------+ + | | | 17: Bidirectional LSP | RFC 9059 | + | | | direction mismatch | | + | | +--------------------------+-----------+ + | | | 18: Bidirectional LSP | RFC 9059 | + | | | co-routed mismatch | | + | | +--------------------------+-----------+ + | | | 19: Endpoint mismatch in | RFC 9059 | + | | | the association group | | + +------------+-------------+--------------------------+-----------+ + + Table 4: Additions to PCEP-ERROR Object Error Types and Values + Subregistry + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + <https://www.rfc-editor.org/info/rfc3209>. + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <https://www.rfc-editor.org/info/rfc5440>. + + [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE + Extensions for Associated Bidirectional Label Switched + Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, + <https://www.rfc-editor.org/info/rfc7551>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for Stateful PCE", RFC 8231, + DOI 10.17487/RFC8231, September 2017, + <https://www.rfc-editor.org/info/rfc8231>. + + [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, + "PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP)", + RFC 8253, DOI 10.17487/RFC8253, October 2017, + <https://www.rfc-editor.org/info/rfc8253>. + + [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for PCE-Initiated LSP Setup in a Stateful PCE + Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, + <https://www.rfc-editor.org/info/rfc8281>. + + [RFC8537] Gandhi, R., Ed., Shah, H., and J. Whittaker, "Updates to + the Fast Reroute Procedures for Co-routed Associated + Bidirectional Label Switched Paths (LSPs)", RFC 8537, + DOI 10.17487/RFC8537, February 2019, + <https://www.rfc-editor.org/info/rfc8537>. + + [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., + Dhody, D., and Y. Tanaka, "Path Computation Element + Communication Protocol (PCEP) Extensions for Establishing + Relationships between Sets of Label Switched Paths + (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, + <https://www.rfc-editor.org/info/rfc8697>. + +9.2. Informative References + + [BIDIR-PATH] + Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, + "Path Computation Element Communication Protocol (PCEP) + Extensions for Associated Bidirectional Segment Routing + (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- + pce-sr-bidir-path-05, 26 January 2021, + <https://tools.ietf.org/html/draft-ietf-pce-sr-bidir-path- + 05>. + + [PCE-PCEP-YANG] + Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, + "A YANG Data Model for Path Computation Element + Communications Protocol (PCEP)", Work in Progress, + Internet-Draft, draft-ietf-pce-pcep-yang-16, 22 February + 2021, + <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16>. + + [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., + Sprecher, N., and S. Ueno, "Requirements of an MPLS + Transport Profile", RFC 5654, DOI 10.17487/RFC5654, + September 2009, <https://www.rfc-editor.org/info/rfc5654>. + + [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. + Hardwick, "Path Computation Element Communication Protocol + (PCEP) Management Information Base (MIB) Module", + RFC 7420, DOI 10.17487/RFC7420, December 2014, + <https://www.rfc-editor.org/info/rfc7420>. + + [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a + Stateful Path Computation Element (PCE)", RFC 8051, + DOI 10.17487/RFC8051, January 2017, + <https://www.rfc-editor.org/info/rfc8051>. + + [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. + Hardwick, "Conveying Path Setup Type in PCE Communication + Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, + July 2018, <https://www.rfc-editor.org/info/rfc8408>. + + [STATEFUL-PCE-GMPLS] + Lee, Y., Ed., Zheng, H., Ed., de Dios, O., Lopez, V., and + Z. Ali, "Path Computation Element (PCE) Protocol + Extensions for Stateful PCE Usage in GMPLS-controlled + Networks", Work in Progress, Internet-Draft, draft-ietf- + pce-pcep-stateful-pce-gmpls-14, 28 December 2020, + <https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful- + pce-gmpls-14>. + +Acknowledgments + + The authors would like to thank Dhruv Dhody for various discussions + on association groups and inputs to this document. The authors would + also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and + Marina Fizgeer for reviewing this document and providing valuable + comments. The authors would like to thank the following IESG members + for their review comments and suggestions: Barry Leiba, Éric Vyncke, + Benjamin Kaduk, Murray Kucherawy, Martin Duke, and Alvaro Retana. + +Authors' Addresses + + Rakesh Gandhi (editor) + Cisco Systems, Inc. + Canada + + Email: rgandhi@cisco.com + + + Colby Barth + Juniper Networks + + Email: cbarth@juniper.net + + + Bin Wen + Comcast + + Email: Bin_Wen@cable.comcast.com |