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.
As specified in [
RFC 8697], 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 [RFC 8697].
As specified in [
RFC 8697], 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 [RFC 8697].
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 [
RFC 8697]. 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 [
RFC 5440], 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 [
RFC 8231], 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 [
RFC 8231]
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 [
RFC 8697]. 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 [
RFC 3209]). 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) [
RFC 8408]. 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
RFC 8697 continue to apply to the Association Types defined in this document.