Internet-Draft PCEP for Associated Bidirectional LSP December 2020
Gandhi, et al. Expires 19 June 2021 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-ietf-pce-association-bidir-09
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. Gandhi, Ed.
Cisco Systems, Inc.
C. Barth
Juniper Networks
B. Wen
Comcast

Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)

Abstract

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 - Traffic Engineering (RSVP-TE) for signaling.

Status of This Memo

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 19 June 2021.

Table of Contents

1. Introduction

[RFC5440] describes the Path Computation Element Communication 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. 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 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 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 "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 [I-D.ietf-pce-sr-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. The node A is ingress node for LSP1 and egress node for LSP2, whereas node D is 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 a PCC. 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 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  |
                              +-----+    +-----+

   Legends: F = Forward LSP, R = Reverse LSP, (0, P1, P2, P3) = PLSP-IDs
Figure 2: Example of PCE-Initiated Single-sided Bidirectional LSP

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 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 tunnels 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint (PCC) node D reports tunnel 2 and LSP2 to the PCE. The endpoint (PCC) node D also reports the reverse LSP1 (not shown for simplicity) 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  |
                              +-----+    +-----+

   Legends: F = Forward LSP, R = Reverse LSP, (P1, P2, P3) = PLSP-IDs
Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP

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 tunnels 1 and forward LSP1 and reverse LSP2 to the PCE. The endpoint (PCC) node D reports tunnel 2 and LSP2 to the PCE. The endpoint (PCC) node D also reports the reverse LSP1 (not shown for simplicity) 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  |
                          +-----+    +-----+

   Legends: F = Forward LSP, (0, P4, P5) = PLSP-IDs
Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP

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. Both endpoint (PCC) nodes report the forward LSP1 and LSP2 to the PCE. Both endpoint (PCC) nodes also report the reverse LSPs (not shown for simplicity) 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  |
                          +-----+    +-----+

   Legends: F = Forward LSP, (P4, P5) = PLSP-IDs
Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP

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. Both endpoint (PCC) nodes report the forward LSP1 and LSP2 to the PCE. Both endpoint (PCC) nodes also report the reverse LSPs (not shown for simplicity) 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

3.4. Summary of PCEP Extensions

The PCEP extensions defined in this document cover the following modes of operations under the stateful PCE model:

  • A PCC initiates the forward and reverse LSP of a Single-sided Bidirectional LSP and retains the control of the LSPs. Similarly, both PCCs initiate the forward LSPs of a Double-sided Bidirectional LSP and retain the 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 the control of the LSPs to a Stateful PCE. Similarly, both PCCs initiate the forward LSPs of a Double-sided Bidirectional LSP and delegate the 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 the control of the LSP. Similarly, a PCE initiates the forward LSPs of a Double-sided Bidirectional LSP on both PCCs and retains the 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].

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" (TBD1) and "Double-sided Bidirectional LSP" (TBD2), based on 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.
  • A Bidirectional LSP Association SHOULD NOT have more than two unidirectional LSPs.
  • The LSPs in a Bidirectional LSP Association MUST have matching endpoint nodes in the reverse directions.
  • The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs of the Single-sided Bidirectional LSP Association on the originating endpoint node MUST be the same, albeit with reverse 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 PCE Initiated and PCC Initiated single-sided case, these associations are also dynamically created on thee remote endpoint node using the information received from the RSVP message from the originating node.

The Association ID, Association Source, optional Global Association Source and optional Extended Association ID 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" an OPTIONAL TLV for use with the Bidirectional LSP Associations (ASSOCIATION Object with Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for Double-sided Bidirectional LSP).

  • The "Bidirectional LSP Association Group TLV" follows the PCEP TLV format from [RFC5440].
  • The Type (16 bits) of the TLV is TBD3, to be assigned by IANA.
  • The Length is 4 Bytes.
  • The value comprises of a single field, the Bidirectional LSP Association Flag (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 co-routed LSP.
  • For co-routed LSPs, this TLV MUST be present and C flag set.
  • For reverse LSPs, this TLV MUST be present and 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 = TBD3           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Flags                             |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, Bit number 31) - 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, Bit number 30) - 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, Bit number 29) - 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 unassigned flags (Bit Number 0-28) 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:

5.1. PCE Initiated LSPs

As specified in [RFC8697], the Bidirectional LSP Associations can be created and updated by a Stateful PCE.

  • For Single-sided Bidirectional LSP Association initiated by the PCE, it MUST send PCInitiate message to the originating endpoint node with both direction LSPs. For Double-sided Bidirectional LSP Association initiated by the PCE, it MUST send PCInitiate message to both endpoint nodes with forward direction LSPs.
  • Both PCCs MUST report the forward and reverse LSPs in the Bidirectional LSP Association to the PCE. PCC reports via PCRpt message.
  • Stateful PCE MAY create and update the forward and reverse LSPs independently for the Single-sided Bidirectional LSP Association on the originating endpoint node.
  • Stateful PCE MAY create and update the forward LSP independently for the Double-sided Bidirectional LSP Association on the endpoint nodes.
  • Stateful PCE establishes and removes the association relationship on a per LSP basis.
  • Stateful PCE creates and updates the LSP and the association on a PCC 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 Single-sided Bidirectional LSP Association initiated at a PCC, it MUST send PCRpt message to the PCE with both direction LSPs. For Double-sided Bidirectional LSP Association initiated at the PCCs, both PCCs MUST send PCRpt message to the PCE with forward direction LSPs.
  • PCC on the originating endpoint node MAY create and update the forward and reverse LSPs independently for the Single-sided Bidirectional LSP Association.
  • PCC on the endpoint nodes MAY create and update the forward LSP independently for the Double-sided Bidirectional LSP Association.
  • PCC establishes and removes the association group on a per LSP basis. PCC MUST report the change in the association group of an LSP to PCE(s) via PCRpt message.
  • PCC reports the forward and reverse LSPs in the Bidirectional LSP Association independently to PCE(s) via PCRpt message.
  • PCC for the single-sided case MAY delegate the forward and reverse LSPs independently to a Stateful PCE, where 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 PCE would control the LSPs.
  • Stateful PCE updates the LSPs in the Bidirectional LSP Association via 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 direction 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 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.

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 case of Single-sided Bidirectional LSP Association, the reverse LSP of a bidirectional LSP created on the originating endpoint 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 will have a PLSP-ID P1 at the ingress node while it will have a PLSP-ID P3 at the egress node. There is no change in the PLSP-ID allocation procedure for the forward LSP of the Single-sided Bidirectional LSP on the originating endpoint node. 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.

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 stale Bidirectional LSP Associations.

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 = TBD4 (Bidirectional LSP 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 = TBD5 (Bidirectional Association - Tunnel Mismatch).

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 and it does not support; the PCE speaker MUST return a PCErr message with Error-Type = 26 (Association Error) and Error-Value = TBD6 (Bidirectional LSP Association - 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 = TBD7 (Bidirectional LSP Association - 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 = TBD8 (Bidirectional LSP Association - 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 = TBD9 (Bidirectional LSP Association - Endpoint Mismatch).

The processing rules as specified in Section 6.4 of [RFC8697] continue to apply to the Association Types defined in this document.

6. Implementation Status

[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".

6.1. Implementation

The PCEP extensions defined in this document has been implemented by a vendor on their product. No further information is available at this time.

7. 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 is described in [RFC8697] and apply to these Association Types. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] is recommended.

8. Manageability Considerations

8.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].

8.2. Information and Data Models

[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.

8.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].

8.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].

8.5. Requirements On Other Protocols

The mechanisms defined in this document do not add any new requirements on other protocols.

8.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].

9. IANA Considerations

9.1. Association Types

This document defines two new Association Types, originally described in [RFC8697]. IANA is requested to assign the following new values in the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path Computation Element Protocol (PCEP) Numbers" registry:

Type Name                                             Reference
---------------------------------------------------------------------
TBD1 Single-sided Bidirectional LSP Association      [This document]
TBD2 Double-sided Bidirectional LSP Association      [This document]

9.2. Bidirectional LSP Association Group TLV

This document defines a new TLV for carrying additional information of LSPs within a Bidirectional LSP Association. 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]

9.2.1. Flag Field in Bidirectional LSP Association Group TLV

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:

  • Bit number (count from 0 as the most significant bit)
  • Description
  • Reference

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]
 0-28       Unassigned

9.3. PCEP Errors

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

            Error value: TBD7            [This document]
            Bidirectional LSP Association - Direction Mismatch

            Error value: TBD8            [This document]
            Bidirectional LSP Association - Co-routed Mismatch

            Error value: TBD9            [This document]
            Bidirectional LSP Association - Endpoint Mismatch

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8231>.
[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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8697>.

10.2. Informative References

[I-D.ietf-pce-pcep-stateful-pce-gmpls]
Lee, Y., Zheng, H., 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-13, , <http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-stateful-pce-gmpls-13.txt>.
[I-D.ietf-pce-pcep-yang]
Dhody, D., 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-15, , <http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-yang-15.txt>.
[I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-pce-sr-bidir-path-03, , <http://www.ietf.org/internet-drafts/draft-ietf-pce-sr-bidir-path-03.txt>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc7420>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC8051]
Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, , <https://www.rfc-editor.org/info/rfc8051>.
[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, , <https://www.rfc-editor.org/info/rfc8253>.
[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, , <https://www.rfc-editor.org/info/rfc8408>.

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, and Marina Fizgeer for reviewing this document and providing valuable comments.

Authors' Addresses

Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Colby Barth
Juniper Networks
Bin Wen
Comcast