RFC 9059 | PCEP for Associated Bidirectional LSPs | June 2021 |
Gandhi, et al. | Standards Track | [Page] |
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.¶
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 (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.¶
[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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The procedure specified in [RFC8537] for fast reroute bypass tunnel assignment is also applicable to the co-routed associated bidirectional LSPs.¶
The PCEP extensions defined in this document cover the following modes of operation under the stateful PCE model:¶
The double-sided case has an advantage when compared to the single-sided case, summarized as follows:¶
The single-sided case has some advantages when compared to the double-sided case, summarized as follows:¶
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:¶
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.¶
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 format of the Bidirectional LSP Association Group TLV is shown in Figure 7.¶
Flags for the Bidirectional LSP Association Group TLV are defined as follows.¶
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.¶
The PCEP procedure defined in this document is applicable to the following three scenarios:¶
As specified in [RFC8697], Bidirectional LSP Associations can be created and updated by a stateful PCE.¶
As specified in [RFC8697], Bidirectional LSP Associations can also be created and updated by a PCC.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
[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.¶
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].¶
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].¶
The mechanisms defined in this document do not add any new requirements on other protocols.¶
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 |
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 |
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:¶
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 |
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 Error | 14: Association group mismatch | RFC 9059 |
15: Tunnel mismatch in the association group | RFC 9059 | ||
16: Path Setup Type not supported | RFC 9059 | ||
17: Bidirectional LSP direction mismatch | RFC 9059 | ||
18: Bidirectional LSP co-routed mismatch | RFC 9059 | ||
19: Endpoint mismatch in the association group | RFC 9059 |
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.¶