draft-ietf-pce-association-bidir-08.txt   draft-ietf-pce-association-bidir-09.txt 
PCE Working Group R. Gandhi, Ed. PCE Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track C. Barth Intended status: Standards Track C. Barth
Expires: March 19, 2021 Juniper Networks Expires: June 19, 2021 Juniper Networks
B. Wen B. Wen
Comcast Comcast
September 15, 2020 December 16, 2020
PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) Path Computation Element Communication Protocol (PCEP) Extensions for
draft-ietf-pce-association-bidir-08 Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-09
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multiprotocol The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. (LSPs) using PCEP.
This document defines PCEP extensions for grouping two unidirectional This document defines PCEP extensions for grouping two unidirectional
MPLS TE LSPs (one in each direction in the network) into an MPLS TE LSPs (one in each direction in the network) into an
Associated Bidirectional LSP. The mechanisms defined in this Associated Bidirectional LSP. The mechanisms defined in this
document can be applied using a Stateful PCE for both PCE-Initiated 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 and PCC-Initiated LSPs, as well as when using a Stateless PCE. The
procedures defined are applicable to the LSPs using Resource procedures defined are applicable to the LSPs using Resource
Reservation Protocol (RSVP) for signaling. Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2021. This Internet-Draft will expire on June 19, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Summary of PCEP Extensions . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5
3.1.1. PCE-Initiated Single-sided Bidirectional LSP . . . . 5
3.1.2. PCC-Initiated Single-sided Bidirectional LSP . . . . 6
3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 7
3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 8 3.2.1. PCE-Initiated Double-sided Bidirectional LSP . . . . 7
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. PCC-Initiated Double-sided Bidirectional LSP . . . . 8
4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 8 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . 9
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 3.4. Summary of PCEP Extensions . . . . . . . . . . . . . . . 9
5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10
5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 11 4.1. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . 10
5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 11 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 11
5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 12 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 12 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . 13
5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 12 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . 14
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 13 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 15
5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . 15
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 5.5. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 14 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
8. Manageability Considerations . . . . . . . . . . . . . . . . 14 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
8.1. Control of Function and Policy . . . . . . . . . . . . . 14 6.1. Implementation . . . . . . . . . . . . . . . . . . . . . 17
8.2. Information and Data Models . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 8. Manageability Considerations . . . . . . . . . . . . . . . . 18
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 8.1. Control of Function and Policy . . . . . . . . . . . . . 18
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 8.2. Information and Data Models . . . . . . . . . . . . . . . 18
8.6. Impact On Network Operations . . . . . . . . . . . . . . 15 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18
9.1. Association Types . . . . . . . . . . . . . . . . . . . . 15 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 18
9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 15 8.6. Impact On Network Operations . . . . . . . . . . . . . . 18
9.2.1. Flag Field in Bidirectional LSP Association Group TLV 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Association Types . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Bidirectional LSP Association Group TLV . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2.1. Flag Field in Bidirectional LSP Association Group TLV 19
10.2. Informative References . . . . . . . . . . . . . . . . . 18 9.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP) as a [RFC5440] describes the Path Computation Element Communication
communication mechanism between a Path Computation Client (PCC) and a Protocol (PCEP) as a communication mechanism between a Path
Path Control Element (PCE), or between PCE and PCC, that enables Computation Client (PCC) and a Path Control Element (PCE), or between
computation of Multiprotocol Label Switching (MPLS) Traffic PCE and PCC, that enables computation of Multiprotocol Label
Engineering (TE) Label Switched Paths (LSPs). Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs).
[RFC8231] specifies extensions to PCEP to enable stateful control of [RFC8231] specifies extensions to PCEP to enable stateful control of
MPLS TE LSPs. It describes two modes of operation - Passive Stateful MPLS TE LSPs. It describes two modes of operation - Passive Stateful
PCE and Active Stateful PCE. In [RFC8231], the focus is on Active PCE and Active Stateful PCE. In [RFC8231], the focus is on Active
Stateful PCE where LSPs are provisioned on the PCC and control over Stateful PCE where LSPs are provisioned on the PCC and control over
them is delegated to a PCE. Further, [RFC8281] describes the setup, them is delegated to a PCE. Further, [RFC8281] describes the setup,
maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE maintenance and teardown of PCE-Initiated LSPs for the Stateful PCE
model. model.
[RFC8697] introduces a generic mechanism to create a grouping of LSPs [RFC8697] introduces a generic mechanism to create a grouping of
which can then be used to define associations between a set of LSPs LSPs. This grouping can then be used to define associations between
and/or a set of attributes, for example primary and secondary LSP sets of LSPs or between a set of LSPs and a set of attributes, and it
associations, and is equally applicable to the active and passive is equally applicable to the stateful PCE (active and passive modes)
modes of a Stateful PCE [RFC8231] or a stateless PCE [RFC5440]. and the stateless PCE.
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654] The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
specifies that MPLS-TP MUST support associated bidirectional point- specifies that "MPLS-TP MUST support unidirectional, co-routed
to-point LSPs. [RFC7551] defines RSVP signaling extensions for bidirectional, and associated bidirectional point-to-point transport
binding two reverse unidirectional LSPs [RFC3209] into an associated 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 LSP. The fast reroute (FRR) procedures for associated
bidirectional LSPs are described in [RFC8537]. bidirectional LSPs are described in [RFC8537].
This document defines PCEP extensions for grouping two unidirectional This document defines PCEP extensions for grouping two unidirectional
MPLS-TE LSPs into an Associated Bidirectional LSP for both single- MPLS-TE LSPs into an Associated Bidirectional LSP for both single-
sided and double-sided initiation cases when using a Stateful PCE for 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 both PCE-Initiated and PCC-Initiated LSPs as well as when using a
Stateless PCE. The procedures defined are applicable to the TE LSPs Stateless PCE. The procedures defined are applicable to the LSPs
using Resource Reservation Protocol (RSVP) for signaling [RFC3209]. 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) The procedure for associating two unidirectional Segment Routing (SR)
Paths to form an Associated Bidirectional SR Path is defined in 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 [I-D.ietf-pce-sr-bidir-path], and is outside the scope of this
document. document.
1.1. Summary of PCEP Extensions
The PCEP extensions defined in this document cover the following
cases:
o A PCC initiates the forward and/ or reverse LSP of a single-sided
or double-sided bidirectional LSP and retains the control of the
LSP. 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].
o A PCC initiates the forward and/ or reverse LSP of a single-sided
or double-sided bidirectional LSP and delegates the control of the
LSP 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].
o A PCE initiates the forward and/ or reverse LSP of a single-sided
or double-sided bidirectional LSP on a PCC and retains the control
of the LSP. 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].
o A PCC requests co-routed or non-co-routed paths for forward and
reverse LSPs of a bidirectional LSP from a Stateless PCE
[RFC5440].
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology defined in The reader is assumed to be familiar with the terminology defined in
[RFC5440], [RFC7551], [RFC8231], and [RFC8697]. [RFC5440], [RFC7551], [RFC8231], and [RFC8697].
3. Overview 3. Overview
As shown in Figure 1, two reverse unidirectional LSPs can be grouped As shown in Figure 1, forward and reverse unidirectional LSPs can be
to form an associated bidirectional LSP. There are two methods of grouped to form an associated bidirectional LSP. The node A is
initiating the bidirectional LSP association, single-sided and ingress node for LSP1 and egress node for LSP2, whereas node D is
double-sided, as defined in [RFC7551] and described in the following ingress node for LSP2 and egress node for LSP1. There are two
sections. 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 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+
<-- LSP2 | | <-- LSP2 <-- LSP2 | | <-- LSP2
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| E +-----------+ F | | E +-----------+ F |
+-----+ +-----+ +-----+ +-----+
<-- LSP2 <-- LSP2
Figure 1: Example of Associated Bidirectional LSP Figure 1: Example of Associated Bidirectional LSP
3.1. Single-sided Initiation 3.1. Single-sided Initiation
As specified in [RFC7551], in the single-sided case, the As specified in [RFC7551], in the single-sided case, the
bidirectional tunnel is provisioned only on one endpoint node (PCC) bidirectional tunnel is provisioned only on one endpoint node (PCC)
of the tunnel. Both forward and reverse LSPs of this tunnel are of the tunnel. Both endpoint nodes act as a PCC. Both forward and
initiated with the Association Type set to "Single-sided reverse LSPs of this tunnel are initiated with the Association Type
Bidirectional LSP Association" on the originating endpoint node. The set to "Single-sided Bidirectional LSP Association" on the
forward and reverse LSPs are identified in the Bidirectional LSP originating endpoint node. The forward and reverse LSPs are
Association Group TLV of their PCEP ASSOCIATION Objects. identified in the "Bidirectional LSP Association Group TLV" of their
PCEP ASSOCIATION Objects.
The originating endpoint node signals the properties for the revere The originating endpoint node signals the properties for the reverse
LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path LSP in the RSVP REVERSE_LSP Object [RFC7551] of the forward LSP Path
message. The remote endpoint then creates the corresponding reverse message. The remote endpoint node then creates the corresponding
tunnel and signals the reverse LSP in response to the received RSVP reverse tunnel and reverse LSP, and signals the reverse LSP in
Path message. Similarly, the remote endpoint node deletes the response to the received RSVP-TE Path message. Similarly, the remote
reverse LSP when it receives the RSVP Path delete message [RFC3209] endpoint node deletes the reverse LSP when it receives the RSVP-TE
for the forward LSP. message to delete the forward LSP [RFC3209].
The originating endpoint (PCC) node may report/ delegate the forward As specified in [RFC8537], for fast reroute bypass tunnel assignment,
and reverse direction LSPs to a PCE. The remote endpoint (PCC) node the LSP starting from the originating endpoint node is identified as
may report its forward direction LSP to a PCE. the forward LSP of the single-sided initiated bidirectional LSP.
+-----+ 3.1.1. PCE-Initiated Single-sided Bidirectional LSP
| PCE | +-----+
+-----+ | PCE |
Initiates: | \ +-----+
Tunnel 1 (F) | \ Initiates: | \
(LSP1 (F, 0), LSP2 (R, 0)) | \ Tunnel 1 (F) | \
Association #1 v \ (LSP1 (F, 0), LSP2 (R, 0)) | \
+-----+ +-----+ Association #1 v \
| A | | D | +-----+ +-----+
+-----+ +-----+ | A | | D |
+-----+ +-----+
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #1 | \ Association #1 Association #1 | \ Association #1
+-----+ +-----+ +-----+ +-----+
| A | | D | | 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 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 | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports: Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #2 | \ Association #2 Association #2 | \ Association #2
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP Legends: F = Forward LSP, R = Reverse LSP, (P1, P2, P3) = PLSP-IDs
As shown in Figures 2 and 3, the forward tunnel and both forward LSP1 Figure 3: Example of PCC-Initiated Single-sided Bidirectional LSP
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.
PLSP-IDs used are shown in the Figures as P1, P2 and P3.
As specified in [RFC8537], for fast reroute bypass tunnel assignment, As shown in Figure 3, the forward tunnel 1 and both forward LSP1 and
the LSP starting from the originating node is identified as the reverse LSP2 are initiated on the originating endpoint node A (the
forward LSP of the single-sided initiated bidirectional LSP. 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 3.2. Double-sided Initiation
As specified in [RFC7551], in the double-sided case, the As specified in [RFC7551], in the double-sided case, the
bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of bidirectional tunnel is provisioned on both endpoint nodes (PCCs) of
the tunnel. The forward and reverse LSPs of this tunnel are the tunnel. The forward and reverse LSPs of this tunnel are
initiated with the Association Type set to "Double-sided initiated with the Association Type set to "Double-sided
Bidirectional LSP Association" on both endpoint nodes. The forward Bidirectional LSP Association" on both endpoint nodes. The forward
and reverse LSPs are identified in the Bidirectional LSP Association and reverse LSPs are identified in the "Bidirectional LSP Association
Group TLV of their ASSOCIATION Objects. Group TLV" of their ASSOCIATION Objects.
The endpoint (PCC) nodes may report/ delegate the forward and reverse As specified in [RFC8537], for fast reroute bypass tunnel assignment,
direction LSPs to a PCE. 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 | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, 0)) | \ (LSP2 (F, 0)) (LSP1 (F, 0)) | \ (LSP2 (F, 0))
Association #3 v v Association #3 Association #3 v v Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
skipping to change at page 7, line 44 skipping to change at page 8, line 26
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #3 | \ Association #3 Association #3 | \ Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F = Forward LSP, (0, P4, P5) = PLSP-IDs
Figure 4: Example of PCE-Initiated Double-sided Bidirectional LSP 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 | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports/Delegates: Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #4 | \ Association #4 Association #4 | \ Association #4
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP Legends: F = Forward LSP, (P4, P5) = PLSP-IDs
As shown in Figures 4 and 5, the forward tunnel and forward LSP1 are Figure 5: Example of PCC-Initiated Double-sided Bidirectional LSP
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. PLSP-IDs used are shown in the Figures as P4 and
P5.
As specified in [RFC8537], for fast reroute bypass tunnel assignment, As shown in Figure 5, the forward tunnel 1 and forward LSP1 are
the LSP with the higher Source Address [RFC3209] is identified as the initiated on the endpoint node A and the reverse tunnel 2 and reverse
forward LSP of the double-sided initiated bidirectional LSP. 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 3.3. Co-routed Associated Bidirectional LSP
In both single-sided and double-sided initiation cases, forward and In both single-sided and double-sided initiation cases, forward and
reverse LSPs may be co-routed as shown in Figure 6, where both reverse LSPs can be co-routed as shown in Figure 6, where both
forward and reverse LSPs of a bidirectional LSP follow the same forward and reverse LSPs of a bidirectional LSP follow the same
congruent path in the forward and reverse directions, respectively. congruent path in the forward and reverse directions, respectively.
LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 --> LSP3 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
<-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4
Figure 6: Example of Co-routed Associated Bidirectional LSP 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:
o 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].
o 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].
o 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].
o 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. Protocol Extensions
4.1. ASSOCIATION Object 4.1. ASSOCIATION Object
As per [RFC8697], LSPs are associated by adding them to a common As per [RFC8697], LSPs are associated by adding them to a common
association group. This document defines two new Bidirectional LSP association group. This document defines two new Association Types,
Association Groups to be used by the associated bidirectional LSPs. called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided
A member of the Bidirectional LSP Association Group can take the role Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object
of a forward or reverse LSP and follows the following rules: ((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:
o An LSP (forward or reverse) cannot be part of more than one o An LSP (forward or reverse) MUST NOT be part of more than one
Bidirectional LSP Association Group. More than one forward LSP Bidirectional LSP Association.
and/ or reverse LSP can be part of a Bidirectional LSP Association
Group.
o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs o A Bidirectional LSP Association SHOULD NOT have more than two
of the Single-sided Bidirectional LSP Association on the unidirectional LSPs.
originating node MUST be the same.
This document defines two new Association Types for the ASSOCIATION o The LSPs in a Bidirectional LSP Association MUST have matching
Object (Object-Class value 40) as follows: endpoint nodes in the reverse directions.
o Association Type (TBD1) = Single-sided Bidirectional LSP o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs
Association Group of the Single-sided Bidirectional LSP Association on the
originating endpoint node MUST be the same, albeit with reverse
endpoint nodes.
o Association Type (TBD2) = Double-sided Bidirectional LSP The Bidirectional LSP Association types are considered to be both
Association Group 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]).
These Association Types are operator-configured associations in Specifically, for the PCE Initiated Bidirectional LSPs, these
nature and statically created by the operator on the PCEP peers. Associations are dynamically created by the PCE on the PCE peers.
'Operator-configured Association Range' TLV (Value 29) [RFC8697] MUST Similarly, for both PCE Initiated and PCC Initiated single-sided
NOT be sent for these Association Types, and MUST be ignored, so that case, these associations are also dynamically created on thee remote
the entire range of association ID can be used for them. endpoint node using the information received from the RSVP message
from the originating node.
The Association ID, Association Source, optional Global Association The Association ID, Association Source, optional Global Association
Source and optional Extended Association ID in the Bidirectional LSP Source and optional Extended Association ID in the Bidirectional LSP
Association Group Object are initialized using the procedures defined Association Object are initialized using the procedures defined in
in [RFC8697] and [RFC7551]. [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 4.2. Bidirectional LSP Association Group TLV
The Bidirectional LSP Association Group TLV is defined for use with The "Bidirectional LSP Association Group TLV" an OPTIONAL TLV for use
the Single-sided and Double-sided Bidirectional LSP Association Group with the Bidirectional LSP Associations (ASSOCIATION Object with
Object Types. Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for
Double-sided Bidirectional LSP).
o The Bidirectional LSP Association Group TLV follows the PCEP TLV o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV
format from [RFC5440]. format from [RFC5440].
o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA.
o The Length is 4 Bytes. o The Length is 4 Bytes.
o The value comprises of a single field, the Bidirectional LSP o The value comprises of a single field, the Bidirectional LSP
Association Flag (32 bits), where each bit represents a flag Association Flag (32 bits), where each bit represents a flag
option. option.
o If the Bidirectional LSP Association Group TLV is missing, it o If the "Bidirectional LSP Association Group TLV" is missing, it
means the LSP is the forward LSP and it is not co-routed LSP. means the LSP is the forward LSP and it is not co-routed LSP.
o For co-routed LSPs, this TLV MUST be present. o For co-routed LSPs, this TLV MUST be present and C flag set.
o For reverse LSPs, this TLV MUST be present. o For reverse LSPs, this TLV MUST be present and R flag set.
o The Bidirectional LSP Association Group TLV MUST NOT be present o The "Bidirectional LSP Association Group TLV" MUST NOT be present
more than once. If it appears more than once, only the first more than once. If it appears more than once, only the first
occurrence is processed and any others MUST be ignored. occurrence is processed and any others MUST be ignored.
The format of the Bidirectional LSP Association Group TLV is shown in The format of the "Bidirectional LSP Association Group TLV" is shown
Figure 7: in Figure 7:
0 1 2 3 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 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 | | Type = TBD3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C|R|F| | Flags |C|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Bidirectional LSP Association Group TLV format Figure 7: Bidirectional LSP Association Group TLV format
Flags for Bidirectional LSP Association Group TLV are defined as Flags for "Bidirectional LSP Association Group TLV" are defined as
following. following.
F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the F (Forward LSP, 1 bit, Bit number 31) - Indicates whether the LSP
forward LSP of the bidirectional LSP. If this flag is set, the LSP associated is the forward LSP of the bidirectional LSP. If this flag
is a forward LSP. is set, the LSP is a forward LSP.
R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the R (Reverse LSP, 1 bit, Bit number 30) - Indicates whether the LSP
reverse LSP of the bidirectional LSP. If this flag is set, the LSP associated is the reverse LSP of the bidirectional LSP. If this flag
is a reverse LSP. is set, the LSP is a reverse LSP.
C (Co-routed Path, 1 bit) - Indicates whether the bidirectional LSP C (Co-routed Path, 1 bit, Bit number 29) - Indicates whether the
is co-routed. This flag MUST be set for both the forward and reverse bidirectional LSP is co-routed. This flag MUST be set for both the
LSPs of a co-routed bidirectional LSP. forward and reverse LSPs of a co-routed bidirectional LSP.
The C flag is used by the PCE (for both Stateful and Stateless) to 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- compute bidirectional paths of the forward and reverse LSPs of a co-
routed bidirectional LSP. routed bidirectional LSP.
The Reserved flags MUST be set to 0 when sent and MUST be ignored The unassigned flags (Bit Number 0-28) MUST be set to 0 when sent and
when received. MUST be ignored when received.
5. PCEP Procedure 5. PCEP Procedure
The PCEP procedure defined in this document is applicable to the
following three scenarios:
o Neither unidirectional LSP exists, and both must be established.
o Both unidirectional LSPs exist, but the association must be
established.
o One LSP exists, but the reverse associated LSP must be
established.
5.1. PCE Initiated LSPs 5.1. PCE Initiated LSPs
As specified in [RFC8697], the Bidirectional LSP Association Groups As specified in [RFC8697], the Bidirectional LSP Associations can be
can be created by a Stateful PCE. created and updated by a Stateful PCE.
o Stateful PCE can create and update the forward and reverse LSPs o For Single-sided Bidirectional LSP Association initiated by the
independently for both Single-sided and Double-sided Bidirectional PCE, it MUST send PCInitiate message to the originating endpoint
LSP Association Groups. 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.
o Stateful PCE can establish and remove the association relationship o Both PCCs MUST report the forward and reverse LSPs in the
Bidirectional LSP Association to the PCE. PCC reports via PCRpt
message.
o Stateful PCE MAY create and update the forward and reverse LSPs
independently for the Single-sided Bidirectional LSP Association
on the originating endpoint node.
o Stateful PCE MAY create and update the forward LSP independently
for the Double-sided Bidirectional LSP Association on the endpoint
nodes.
o Stateful PCE establishes and removes the association relationship
on a per LSP basis. on a per LSP basis.
o Stateful PCE can create and update the LSP and the association on o Stateful PCE creates and updates the LSP and the association on a
a PCC via PCInitiate and PCUpd messages, respectively, using the PCC via PCInitiate and PCUpd messages, respectively, using the
procedures described in [RFC8697]. procedures described in [RFC8697].
5.2. PCC Initiated LSPs 5.2. PCC Initiated LSPs
As specified in [RFC8697], Bidirectional LSP Association Groups can As specified in [RFC8697], Bidirectional LSP Associations can also be
also be created by a PCC. created and updated by a PCC.
o PCC can create and update the forward and reverse LSPs o For Single-sided Bidirectional LSP Association initiated at a PCC,
independently for both Single-sided and Double-sided Bidirectional it MUST send PCRpt message to the PCE with both direction LSPs.
LSP Association Groups. For Double-sided Bidirectional LSP Association initiated at the
PCCs, both PCCs MUST send PCRpt message to the PCE with forward
direction LSPs.
o PCC can establish and remove the association relationship on a per o PCC on the originating endpoint node MAY create and update the
LSP basis. forward and reverse LSPs independently for the Single-sided
Bidirectional LSP Association.
o PCC MUST report the change in the association group of an LSP to o PCC on the endpoint nodes MAY create and update the forward LSP
PCE(s) via PCRpt message. independently for the Double-sided Bidirectional LSP Association.
o PCC can report the forward and reverse LSPs independently to o PCC establishes and removes the association group on a per LSP
PCE(s) via PCRpt message. basis. PCC MUST report the change in the association group of an
LSP to PCE(s) via PCRpt message.
o PCC can delegate the forward and reverse LSPs independently to a o PCC reports the forward and reverse LSPs in the Bidirectional LSP
Stateful PCE, where PCE would control the LSPs. For single-sided Association independently to PCE(s) via PCRpt message.
case, originating (PCC) node can delegate both forward and reverse
LSPs of a tunnel together to a Stateful PCE in order to avoid any
race condition.
o Stateful PCE can update the LSPs in the Bidirectional LSP o PCC for the single-sided case MAY delegate the forward and reverse
Association Group via PCUpd message, using the procedures LSPs independently to a Stateful PCE, where PCE would control the
described in [RFC8697]. 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.
o PCCs for the double-sided case MAY delegate the forward LSPs to a
Stateful PCE, where PCE would control the LSPs.
o Stateful PCE updates the LSPs in the Bidirectional LSP Association
via PCUpd message, using the procedures described in [RFC8697].
5.3. Stateless PCE 5.3. Stateless PCE
For a stateless PCE, it might be useful to associate a path For a stateless PCE, it might be useful to associate a path
computation request to an association group, thus enabling it to computation request to an association group, thus enabling it to
associate a common set of configuration parameters or behaviors with associate a common set of configuration parameters or behaviors with
the request. A PCC can request co-routed or non-co-routed forward the request [RFC8697]. A PCC can request co-routed or non-co-routed
and reverse direction paths from a stateless PCE for a Bidirectional forward and reverse direction paths from a stateless PCE for a
LSP Association Group. Bidirectional LSP Association.
5.4. Bidirectional (B) Flag 5.4. Bidirectional (B) Flag
As defined in [RFC5440], the Bidirectional (B) flag in the Request As defined in [RFC5440], the Bidirectional (B) flag in the Request
Parameters (RP) object is set when the PCC specifies that the path Parameters (RP) Object is set when the PCC specifies that the path
computation request is for a bidirectional TE LSP with the same TE computation request is for a bidirectional TE LSP with the same TE
requirements in each direction. For an associated bidirectional LSP, requirements in each direction. For an associated bidirectional LSP,
the B-flag is also set when the PCC makes the path computation the B-flag is also set when the PCC makes the path computation
request for the same TE requirements for the forward and reverse request for the same TE requirements for the forward and reverse
direction LSPs. direction LSPs.
Note that the B-flag defined in Stateful PCE Request Parameter (SRP) Note that the B-flag defined in Stateful PCE Request Parameter (SRP)
object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate Object [I-D.ietf-pce-pcep-stateful-pce-gmpls] to indicate
'bidirectional co-routed LSP' is used for GMPLS signaled 'bidirectional co-routed LSP' is used for GMPLS signaled
bidirectional LSPs and is not applicable to the associated bidirectional LSPs and is not applicable to the associated
bidirectional LSPs. bidirectional LSPs.
5.5. PLSP-ID Usage 5.5. PLSP-ID Usage
As defined in [RFC8231], a PCEP-specific LSP Identifier (PLSP-ID) is 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 created by a PCC to uniquely identify an LSP and it remains the same
for the lifetime of a PCEP session. for the lifetime of a PCEP session.
In case of Single-sided Bidirectional LSP Association, the reverse In case of Single-sided Bidirectional LSP Association, the reverse
LSP of a bidirectional LSP created on the originating node is LSP of a bidirectional LSP created on the originating endpoint node
identified by the PCE using 2 different PLSP-IDs based on the PCEP 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, 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 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 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 PLSP-ID allocation procedure for the forward LSP of the Single-sided
Bidirectional LSP on the originating node. In case of Double-sided Bidirectional LSP on the originating endpoint node. In case of
Bidirectional LSP Association, there is no change in the PLSP-ID Double-sided Bidirectional LSP Association, there is no change in the
allocation procedure. PLSP-ID allocation procedure.
For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231]
MUST be included in all forward and reverse LSPs. MUST be included in all forward and reverse LSPs.
5.6. State Synchronization 5.6. State Synchronization
During state synchronization, a PCC MUST report all the existing During state synchronization, a PCC MUST report all the existing
Bidirectional LSP Association Groups to the Stateful PCE as per Bidirectional LSP Associations to the Stateful PCE as per [RFC8697].
[RFC8697]. After the state synchronization, the PCE MUST remove all After the state synchronization, the PCE MUST remove all stale
stale Bidirectional LSP Associations. Bidirectional LSP Associations.
5.7. Error Handling 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 An LSP (forward or reverse) cannot be part of more than one
Bidirectional LSP Association Group. If a PCE attempts to add an LSP Bidirectional LSP Association. If a PCE speaker receives an LSP not
not complying to this rule, the PCC MUST send PCErr with Error-Type = complying to this rule, the PCE speaker MUST send PCErr with Error-
26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP Type = 26 (Association Error) and Error-Value = TBD4 (Bidirectional
Association - Group Mismatch). Similarly, if a PCC attempts to add LSP Association - Group Mismatch).
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 The LSPs (forward or reverse) in a Single-sided Bidirectional
Association Group MUST belong to the same TE Tunnel (as defined in Association MUST belong to the same TE Tunnel (as defined in
[RFC3209]). If a PCE attempts to add an LSP in a Single-sided [RFC3209]). If a PCE speaker attempts to add an LSP in a Single-
Bidirectional LSP Association Group for a different Tunnel, the PCC sided Bidirectional LSP Association for a different Tunnel, the PCE
MUST send PCErr with Error-Type = 26 (Association Error) and Error- speaker MUST send PCErr with Error-Type = 26 (Association Error) and
Value = TBD5 (Bidirectional Association - Tunnel Mismatch). 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 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 using the RSVP-TE signaling protocol' (Value 0) [RFC8408]. If a PCEP
speaker receives a different PST value for the Bidirectional LSP speaker receives a different PST value for the Bidirectional LSP
Association Groups defined in this document and it does not support; Associations defined in this document and it does not support; the
it MUST return a PCErr message with Error-Type = 26 (Association PCE speaker MUST return a PCErr message with Error-Type = 26
Error) and Error-Value = TBD6 (Bidirectional LSP Association - Path (Association Error) and Error-Value = TBD6 (Bidirectional LSP
Setup Type Not Supported). 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] The processing rules as specified in Section 6.4 of [RFC8697]
continue to apply to the Association Types defined in this document. continue to apply to the Association Types defined in this document.
6. Implementation Status 6. Implementation Status
[Note to the RFC Editor - remove this section before publication, as [Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.] well as remove the reference to RFC 7942.]
This section records the status of known implementations of the This section records the status of known implementations of the
skipping to change at page 14, line 31 skipping to change at page 17, line 52
The PCEP extensions defined in this document has been implemented by The PCEP extensions defined in this document has been implemented by
a vendor on their product. No further information is available at a vendor on their product. No further information is available at
this time. this time.
7. Security Considerations 7. Security Considerations
The security considerations described in [RFC5440], [RFC8231], and The security considerations described in [RFC5440], [RFC8231], and
[RFC8281] apply to the extensions defined in this document as well. [RFC8281] apply to the extensions defined in this document as well.
Two new Association Types for the ASSOCIATION Object, Single-sided Two new Association Types for the ASSOCIATION Object, Single-sided
Bidirectional LSP Association Group and Double-sided Bidirectional Bidirectional LSP Association and Double-sided Bidirectional LSP
LSP Association Group are introduced in this document. Additional Association are introduced in this document. Additional security
security considerations related to LSP associations due to a considerations related to LSP associations due to a malicious PCEP
malicious PCEP speaker is described in [RFC8697] and apply to these speaker is described in [RFC8697] and apply to these Association
Association Types. Hence, securing the PCEP session using Transport Types. Hence, securing the PCEP session using Transport Layer
Layer Security (TLS) [RFC8253] is recommended. Security (TLS) [RFC8253] is recommended.
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.1. Control of Function and Policy
The mechanisms defined in this document do not imply any control or The mechanisms defined in this document do not imply any control or
policy requirements in addition to those already listed in [RFC5440], policy requirements in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
8.2. Information and Data Models 8.2. Information and Data Models
skipping to change at page 15, line 35 skipping to change at page 19, line 9
8.6. Impact On Network Operations 8.6. Impact On Network Operations
The mechanisms defined in this document do not have any impact on The mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in [RFC5440], network operations in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
9. IANA Considerations 9. IANA Considerations
9.1. Association Types 9.1. Association Types
This document adds new Association Types for the ASSOCIATION Object This document defines two new Association Types, originally described
(Object-class value 40) defined [RFC8697]. IANA is requested to make in [RFC8697]. IANA is requested to assign the following new values
the assignment of values for the sub-registry "ASSOCIATION Type" in the "ASSOCIATION Type Field" subregistry [RFC8697] within the
[RFC8697], as follows: "Path Computation Element Protocol (PCEP) Numbers" registry:
Type Name Reference Type Name Reference
--------------------------------------------------------------------- ---------------------------------------------------------------------
TBD1 Single-sided Bidirectional LSP Association Group [This document] TBD1 Single-sided Bidirectional LSP Association [This document]
TBD2 Double-sided Bidirectional LSP Association Group [This document] TBD2 Double-sided Bidirectional LSP Association [This document]
9.2. Bidirectional LSP Association Group TLV 9.2. Bidirectional LSP Association Group TLV
This document defines a new TLV for carrying additional information This document defines a new TLV for carrying additional information
of LSPs within a Bidirectional LSP Association Group. IANA is of LSPs within a Bidirectional LSP Association. IANA is requested to
requested to add the assignment of a new value in the existing "PCEP add the assignment of a new value in the existing "PCEP TLV Type
TLV Type Indicators" registry as follows: Indicators" registry as follows:
Value Meaning Reference Value Meaning Reference
------------------------------------------------------------------- -------------------------------------------------------------------
TBD3 Bidirectional LSP Association Group TLV [This document] TBD3 Bidirectional LSP Association Group TLV [This document]
9.2.1. Flag Field in Bidirectional LSP Association Group TLV 9.2.1. Flag Field in Bidirectional LSP Association Group TLV
This document requests that a new sub-registry, named "Bidirectional This document requests that a new sub-registry, named "Bidirectional
LSP Association Group TLV Flag Field", is created within the "Path LSP Association Group TLV Flag Field", is created within the "Path
Computation Element Protocol (PCEP) Numbers" registry to manage the Computation Element Protocol (PCEP) Numbers" registry to manage the
skipping to change at page 16, line 31 skipping to change at page 19, line 52
o Reference o Reference
The following values are defined in this document for the Flag field. The following values are defined in this document for the Flag field.
Bit No. Description Reference Bit No. Description Reference
--------------------------------------------------------- ---------------------------------------------------------
31 F - Forward LSP [This document] 31 F - Forward LSP [This document]
30 R - Reverse LSP [This document] 30 R - Reverse LSP [This document]
29 C - Co-routed Path [This document] 29 C - Co-routed Path [This document]
0-28 Unassigned
9.3. PCEP Errors 9.3. PCEP Errors
This document defines new Error value for Error Type 26 (Association This document defines new Error value for Error Type 26 (Association
Error). IANA is requested to allocate new Error value within the Error). IANA is requested to allocate new Error value within the
"PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP
Numbers registry, as follows: Numbers registry, as follows:
Error Type Description Reference Error Type Description Reference
--------------------------------------------------------- ---------------------------------------------------------
skipping to change at page 17, line 19 skipping to change at page 20, line 26
Error value: TBD4 [This document] Error value: TBD4 [This document]
Bidirectional LSP Association - Group Mismatch Bidirectional LSP Association - Group Mismatch
Error value: TBD5 [This document] Error value: TBD5 [This document]
Bidirectional LSP Association - Tunnel Mismatch Bidirectional LSP Association - Tunnel Mismatch
Error value: TBD6 [This document] Error value: TBD6 [This document]
Bidirectional LSP Association - Path Setup Type Bidirectional LSP Association - Path Setup Type
Not Supported 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. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
skipping to change at page 18, line 33 skipping to change at page 22, line 8
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-pce-pcep-stateful-pce-gmpls] [I-D.ietf-pce-pcep-stateful-pce-gmpls]
Lee, Y., Zheng, H., Dios, O., Lopezalvarez, V., and Z. Lee, Y., Zheng, H., Dios, O., Lopez, V., and Z. Ali, "Path
Ali, "Path Computation Element (PCE) Protocol Extensions Computation Element (PCE) Protocol Extensions for Stateful
for Stateful PCE Usage in GMPLS-controlled Networks", PCE Usage in GMPLS-controlled Networks", draft-ietf-pce-
draft-ietf-pce-pcep-stateful-pce-gmpls-13 (work in pcep-stateful-pce-gmpls-13 (work in progress), April 2020.
progress), April 2020.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-14 (work in progress), July 2020. yang-15 (work in progress), October 2020.
[I-D.ietf-pce-sr-bidir-path] [I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"PCEP Extensions for Associated Bidirectional Segment "PCEP Extensions for Associated Bidirectional Segment
Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-02 (work Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work
in progress), March 2020. in progress), September 2020.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
skipping to change at page 19, line 41 skipping to change at page 23, line 14
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
Acknowledgments Acknowledgments
The authors would like to thank Dhruv Dhody for various discussions The authors would like to thank Dhruv Dhody for various discussions
on association groups and inputs to this document. The authors would on association groups and inputs to this document. The authors would
also like to thank Dhruv Dhody, Mike Taillon, and Marina Fizgeer for also like to thank Mike Taillon, and Marina Fizgeer for reviewing
reviewing this document and providing valuable comments. this document and providing valuable comments.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Colby Barth Colby Barth
Juniper Networks Juniper Networks
Email: cbarth@juniper.net Email: cbarth@juniper.net
Bin Wen Bin Wen
Comcast Comcast
Email: Bin_Wen@cable.comcast.com Email: Bin_Wen@cable.comcast.com
 End of changes. 91 change blocks. 
285 lines changed or deleted 422 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/