| PCE Working Group | R. Gandhi, Ed. |
| Internet-Draft | Cisco Systems, Inc. |
| Intended status: Standards Track | C. Barth |
| Expires: September 14, 2020 | Juniper Networks |
| B. Wen | |
| Comcast | |
| March 13, 2020 |
PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-06
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP.
This document defines PCEP extensions for grouping two unidirectional MPLS TE LSPs (one in each direction in the network) into an Associated Bidirectional LSP. The mechanisms defined in this document can be applied using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs, as well as when using a Stateless PCE. The procedures defined are applicable to the LSPs using Resource Reservation Protocol (RSVP) for signaling.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2020.
Copyright (c) 2020 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 Protocol (PCEP) as a communication mechanism between a Path Computation Client (PCC) and a Path Control 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 to create a grouping of LSPs which can then be used to define associations between a set of LSPs and/or a set of attributes, for example primary and secondary LSP associations, and is equally applicable to the active and passive modes of a Stateful PCE [RFC8231] or a stateless PCE [RFC5440].
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] specifies that MPLS-TP MUST support associated bidirectional point-to-point LSPs. [RFC7551] defines RSVP signaling extensions for binding two reverse unidirectional LSPs [RFC3209] 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 when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE. The procedures defined are applicable to the TE LSPs using Resource Reservation Protocol (RSVP) for signaling [RFC3209]. The procedure for associating two unidirectional Segment Routing (SR) Paths to form an Associated Bidirectional SR Path is defined in [I-D.ietf-pce-sr-bidir-path], and is outside the scope of this document.
The PCEP extensions defined in this document cover the following cases:
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.
The reader is assumed to be familiar with the terminology defined in [RFC5440], [RFC7551], [RFC8231], and [RFC8697].
As shown in Figure 1, two reverse unidirectional LSPs can be grouped to form an associated bidirectional LSP. 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
As specified in [RFC7551], in the single-sided case, the bidirectional tunnel is provisioned only on one endpoint node (PCC) of the tunnel. 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 revere LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path message. The remote endpoint then creates the corresponding reverse tunnel and signals the reverse LSP in response to the received RSVP Path message. Similarly, the remote endpoint node deletes the reverse LSP when it receives the RSVP Path delete message [RFC3209] for the forward LSP.
The originating endpoint (PCC) node may report/ delegate the forward and reverse direction LSPs to a PCE. The remote endpoint (PCC) node may report its forward direction LSP to a PCE.
+-----+
| PCE |
+-----+
Initiates: | ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (F))
Association #1 v \ Association #1
+-----+ +-----+
| A | | D |
+-----+ +-----+
Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP
+-----+
| PCE |
+-----+
Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (F))
Association #2 | \ Association #2
+-----+ +-----+
| A | | D |
+-----+ +-----+
Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP
As shown in Figures 2 and 3, the forward tunnel and both forward LSP1 and reverse LSP2 are initiated on the originating endpoint node A, either by the PCE or the originating PCC, respectively. The originating endpoint node A signals the properties of reverse LSP2 in the RSVP REVERSE_LSP Object in the Path message of the forward LSP1. The creation of reverse tunnel and reverse LSP2 on the remote endpoint node D is triggered by the RSVP signaled forward LSP1.
As specified in [RFC8537], for fast reroute bypass tunnel assignment, the LSP starting from the originating node is identified as the forward LSP of the single-sided initiated bidirectional LSP.
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.
The endpoint (PCC) nodes may report/ delegate the forward and reverse direction LSPs to a PCE.
+-----+
| PCE |
+-----+
Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F)) | \ (LSP2 (F))
Association #3 v v Association #3
+-----+ +-----+
| A | | D |
+-----+ +-----+
Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP
+-----+
| PCE |
+-----+
Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F)) | \ (LSP2 (F))
Association #4 | \ Association #4
+-----+ +-----+
| A | | D |
+-----+ +-----+
Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP
As shown in Figures 4 and 5, the forward tunnel and forward LSP1 are initiated on the endpoint node A and the reverse tunnel and reverse LSP2 are initiated on the endpoint node D, either by the PCE or the PCCs, respectively.
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.
In both single-sided and double-sided initiation cases, forward and reverse LSPs may 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
As per [RFC8697], LSPs are associated by adding them to a common association group. This document defines two new Bidirectional LSP Association Groups to be used by the associated bidirectional LSPs. A member of the Bidirectional LSP Association Group can take the role of a forward or reverse LSP and follows the following rules:
This document defines two new Association Types for the ASSOCIATION Object (Object-Class value 40) as follows:
These Association Types are operator-configured associations in nature and statically created by the operator on the PCEP peers. 'Operator-configured Association Range' TLV (Value 29) [RFC8697] MUST NOT be sent for these Association Types, and MUST be ignored, so that the entire range of association ID can be used for them.
The Association ID, Association Source, optional Global Association Source and optional Extended Association ID in the Bidirectional LSP Association Group Object are initialized using the procedures defined in [RFC8697] and [RFC7551].
The Bidirectional LSP Association Group TLV is defined for use with the Single-sided and Double-sided Bidirectional LSP Association Group Object Types.
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 = TBD3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |C|R|F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Bidirectional LSP Association Group TLV format
Flags for Bidirectional LSP Association Group TLV are defined as following.
F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the forward LSP of the bidirectional LSP. If this flag is set, the LSP is a forward LSP.
R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the reverse LSP of the bidirectional LSP. If this flag is set, the LSP is a reverse LSP.
C (Co-routed Path, 1 bit) - 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 (for both Stateful and Stateless) to compute bidirectional paths of the forward and reverse LSPs of a co-routed bidirectional LSP.
The Reserved flags MUST be set to 0 when sent and MUST be ignored when received.
As specified in [RFC8697], the Bidirectional LSP Association Groups can be created by a Stateful PCE.
As specified in [RFC8697], Bidirectional LSP Association Groups can also be created 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. A PCC can request co-routed or non-co-routed forward and reverse direction paths from a stateless PCE for a Bidirectional LSP Association Group.
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 direction LSPs.
Note that the B-flag defined in Stateful PCE Request Parameter (SRP) object [I-D.ietf-pce-pcep-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 case of Single-sided Bidirectional LSP Association, the reverse LSP of a bidirectional LSP created on the originating node is identified by the PCE using 2 different PLSP-IDs based on the PCEP session on the ingress or egress nodes for the LSP. In other words, the reverse LSP on the originating node will have a PLSP-ID A at the ingress node while it will have a PLSP-ID B at the egress node. This is not the case for the forward LSP of the Single-sided Bidirectional LSP on the originating node and there is no change in the PLSP-ID allocation procedure for it. In case of Double-sided Bidirectional LSP Association, there is no change in the PLSP-ID allocation procedure.
For an Associated Bidirectional LSP, 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 Association Groups to the Stateful PCE as per [RFC8697]. After the state synchronization, the PCE MUST remove all stale Bidirectional LSP Associations.
An LSP (forward or reverse) cannot be part of more than one Bidirectional LSP Association Group. If a PCE attempts to add an LSP not complying to this rule, the PCC MUST send PCErr with Error-Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if a PCC attempts to add an LSP at PCE not complying to this rule, the PCE MUST send this PCErr.
The LSPs (forward or reverse) in a Single-sided Bidirectional Association Group MUST belong to the same TE Tunnel (as defined in [RFC3209]). If a PCE attempts to add an LSP in a Single-sided Bidirectional LSP Association Group for a different Tunnel, the PCC MUST send PCErr with Error-Type = 26 (Association Error) and Error-Value = TBD5 (Bidirectional Association - Tunnel Mismatch). Similarly, if a PCC attempts to add an LSP to a Single-sided Bidirectional LSP Association Group at PCE not complying to this rule, the PCE MUST send this PCErr.
The PCEP Path Setup Type (PST) for RSVP 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 Association Groups defined in this document and it does not support; it MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-Value = TBD6 (Bidirectional LSP Association - Path Setup Type Not Supported).
The processing rules as specified in Section 6.4 of [RFC8697] continue to apply to the Association Types defined in this document.
[Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.]
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".
The PCEP extensions defined in this document has been implemented by a vendor on their product. No further information is available at this time.
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 Group and Double-sided Bidirectional LSP Association Group are introduced in this document. Additional security considerations related to LSP associations due to a malicious PCEP speaker is 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 [I-D.ietf-pce-pcep-yang] defines 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.
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].
This document adds new Association Types for the ASSOCIATION Object (Object-class value 40) defined [RFC8697]. IANA is requested to make the assignment of values for the sub-registry "ASSOCIATION Type" [RFC8697], as follows:
Type Name Reference --------------------------------------------------------------------- TBD1 Single-sided Bidirectional LSP Association Group [This document] TBD2 Double-sided Bidirectional LSP Association Group [This document]
This document defines a new TLV for carrying additional information of LSPs within a Bidirectional LSP Association Group. IANA is requested to add the assignment of a new value in the existing "PCEP TLV Type Indicators" registry as follows:
Value Meaning Reference ------------------------------------------------------------------- TBD3 Bidirectional LSP Association Group TLV [This document]
This document requests that a new sub-registry, named "Bidirectional LSP Association Group TLV Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the Bidirectional LSP Association Group TLV. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
The following values are defined in this document for the Flag field.
Bit No. Description Reference --------------------------------------------------------- 31 F - Forward LSP [This document] 30 R - Reverse LSP [This document] 29 C - Co-routed Path [This document]
This document defines new Error value for Error Type 26 (Association Error). IANA is requested to allocate new Error value within the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows:
Error Type Description Reference
---------------------------------------------------------
26 Association Error
Error value: TBD4 [This document]
Bidirectional LSP Association - Group Mismatch
Error value: TBD5 [This document]
Bidirectional LSP Association - Tunnel Mismatch
Error value: TBD6 [This document]
Bidirectional LSP Association - Path Setup Type
Not Supported
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 Dhruv Dhody, Mike Taillon, and Marina Fizgeer for reviewing this document and providing valuable comments.