draft-ietf-pce-association-bidir-00.txt   draft-ietf-pce-association-bidir-01.txt 
PCE Working Group C. Barth PCE Working Group C. Barth
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Gandhi, Ed. Intended status: Standards Track R. Gandhi, Ed.
Expires: October 29, 2018 Cisco Systems, Inc. Expires: November 19, 2018 Cisco Systems, Inc.
B. Wen B. Wen
Comcast Comcast
April 27, 2018 May 18, 2018
PCEP Extensions for PCEP Extensions for
Associated Bidirectional Label Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-00 draft-ietf-pce-association-bidir-01
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.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5
3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 5 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6
3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 6 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 7
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8
4.1. Association Object . . . . . . . . . . . . . . . . . . . . 6 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 8
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 7 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9
5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 8 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10
5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 8 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10
5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 9 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11
5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Manageability Considerations . . . . . . . . . . . . . . . . . 10 7. Manageability Considerations . . . . . . . . . . . . . . . . . 12
7.1. Control of Function and Policy . . . . . . . . . . . . . . 10 7.1. Control of Function and Policy . . . . . . . . . . . . . . 12
7.2. Information and Data Models . . . . . . . . . . . . . . . 10 7.2. Information and Data Models . . . . . . . . . . . . . . . 12
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13
7.6. Impact On Network Operations . . . . . . . . . . . . . . . 10 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. Association Types . . . . . . . . . . . . . . . . . . . . 10 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 13
8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 11 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 13
8.2.1. Flag Fields in Bidirectional LSP Association Group 8.2.1. Flag Fields in Bidirectional LSP Association Group
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP) as a [RFC5440] describes the Path Computation Element Protocol (PCEP) as a
communication mechanism between a Path Computation Client (PCC) and a communication mechanism between a Path Computation Client (PCC) and a
Path Control Element (PCE), or between PCE and PCC, that enables Path Control Element (PCE), or between PCE and PCC, that enables
computation of Multiprotocol Label Switching (MPLS) Traffic computation of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Label Switched Paths (LSPs). 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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
[I-D.ietf-pce-association] introduces a generic mechanism to create a [I-D.ietf-pce-association] introduces a generic mechanism to create a
grouping of LSPs which can then be used to define associations grouping of LSPs which can then be used to define associations
between a set of LSPs and/or a set of attributes, for example primary between a set of LSPs and/or a set of attributes, for example primary
and secondary LSP associations, and is equally applicable to the and secondary LSP associations, and is equally applicable to the
active and passive modes of a Stateful PCE [RFC8231] or a stateless active and passive modes of a Stateful PCE [RFC8231] or a stateless
PCE [RFC5440]. PCE [RFC5440].
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 specifies that MPLS-TP MUST support associated bidirectional
point-to-point LSPs. [RFC7551] specifies RSVP signaling extensions point-to-point LSPs. [RFC7551] defines RSVP signaling extensions for
for binding two reverse unidirectional LSPs [RFC3209] into an binding two reverse unidirectional LSPs [RFC3209] into an associated
associated bidirectional LSP. The fast reroute (FRR) procedures for bidirectional LSP. The fast reroute (FRR) procedures for associated
associated bidirectional LSPs are described in bidirectional LSPs are described in
[I-D.ietf-teas-assoc-corouted-bidir-frr]. [I-D.ietf-teas-assoc-corouted-bidir-frr].
This document specifies PCEP extensions for grouping two reverse This document specifies PCEP extensions for grouping two reverse
unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for unidirectional MPLS-TE LSPs into an Associated Bidirectional LSP for
both single-sided and double-sided initiation cases when using a both single-sided and double-sided initiation cases when using a
Stateful (both active and passive modes) or Stateless PCE. The PCEP Stateful (both active and passive modes) or Stateless PCE. The PCEP
extensions cover the following cases: extensions cover the following cases:
o A PCC initiates the forward and/ or reverse LSP of a single-sided 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 or double-sided bidirectional LSP and retains the control of the
skipping to change at page 4, line 25 skipping to change at page 4, line 25
o A PCC requests co-routed or non co-routed paths for forward and o A PCC requests co-routed or non co-routed paths for forward and
reverse LSPs of a bidirectional LSP from a Stateless PCE reverse LSPs of a bidirectional LSP from a Stateless PCE
[RFC5440]. [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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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 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 [I-D.ietf-pce-association]. [RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association].
3. Overview 3. Overview
As shown in Figure 1, two reverse unidirectional LSPs can be grouped As shown in Figure 1, two reverse unidirectional LSPs can be grouped
to form an associated bidirectional LSP. There are two methods of to form an associated bidirectional LSP. There are two methods of
initiating the bidirectional LSP association, single-sided and initiating the bidirectional LSP association, single-sided and
double-sided as described in the following sections. 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 |
skipping to change at page 5, line 23 skipping to change at page 5, line 33
of the tunnel. Both forward and reverse LSPs of this tunnel are of the tunnel. Both forward and reverse LSPs of this tunnel are
initiated with the Association Type set to "Single-sided initiated with the Association Type set to "Single-sided
Bidirectional LSP Association" on the originating endpoint node. The Bidirectional LSP Association" on the originating endpoint node. The
forward and reverse LSPs are identified in the Bidirectional LSP forward and reverse LSPs are identified in the Bidirectional LSP
Association Group TLV of their PCEP Association Objects. 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 revere
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 then creates the corresponding reverse
tunnel and signals the reverse LSP in response to the received RSVP tunnel and signals the reverse LSP in response to the received RSVP
Path message. Path message. Similarly, the remote endpoint node deletes the
reverse LSP when it receives the RSVP Path delete message [RFC3209]
for the forward LSP.
The two unidirectional reverse LSPs on the originating endpoint node The originating endpoint (PCC) node may report/ delegate the forward
are grouped together using the PCEP Association Object and on the and reverse LSPs to a PCE. The remote endpoint (PCC) node may report
remote endpoint node by the RSVP signaled Association Object. the reverse LSP to a PCE.
As shown in Figure 1, the forward tunnel and both the forward LSP +-----+
LSP1 and the reverse LSP LSP2 are initiated on the originating | PCE |
endpoint node A, either by the PCE or the PCC. The creation of +-----+
reverse tunnel and reverse LSP2 on the remote endpoint node D is Initiates: | ^ Reports:
triggered by the RSVP signaled LSP1. Tunnel 1 (F) | \ Tunnel 2 (R)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (R))
v \
+-----+ +-----+
| A | | D |
+-----+ +-----+
As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for Figure 2A: Example of PCE-Initiated Single-sided Bidirectional LSP
fast-reroute bypass tunnel assignment, the LSP starting from the +-----+
| PCE |
+-----+
Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (R)
(LSP1 (F), LSP2 (R)) | \ (LSP2 (R))
| \
+-----+ +-----+
| A | | D |
+-----+ +-----+
Figure 2B: Example of PCC-Initiated Single-sided Bidirectional LSP
As shown in Figures 2A and 2B, the forward tunnel and both forward
LSP1 and reverse LSP2 are initiated on the originating endpoint node
A, either by the PCE or the originating PCC. The originating
endpoint node A signals the properties of reverse LSP2 in the RSVP
REVERSE_LSP Object in the Path message of the forward LSP1. The
creation of reverse tunnel and reverse LSP2 on the remote endpoint
node D is triggered by the RSVP signaled forward LSP1.
As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast
reroute bypass tunnel assignment, the LSP starting from the
originating node is identified as the forward LSP of the single-sided originating node is identified as the forward LSP of the single-sided
initiated bidirectional LSP. initiated bidirectional LSP.
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 two reverse unidirectional LSPs on both the endpoint nodes are The endpoint (PCC) nodes may report/ delegate the forward and reverse
grouped together by using the PCEP Association Object. LSPs to a PCE.
As shown in Figure 1, the forward tunnel and LSP1 are initiated on +-----+
the endpoint node A and the reverse tunnel and LSP2 are initiated on | PCE |
the endpoint node D, either by the PCE or the PCCs. +-----+
Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (R)
(LSP1 (F)) | \ (LSP2 (R))
v v
+-----+ +-----+
| A | | D |
+-----+ +-----+
As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast- Figure 3A: Example of PCE-Initiated Double-sided Bidirectional LSP
+-----+
| PCE |
+-----+
Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (R)
(LSP1 (F)) | \ (LSP2 (R))
| \
+-----+ +-----+
| A | | D |
+-----+ +-----+
Figure 3B: Example of PCC-Initiated Double-sided Bidirectional LSP
As shown in Figures 3A and 3B, the forward tunnel and forward LSP1
are initiated on the endpoint node A and the reverse tunnel and
reverse LSP2 are initiated on the endpoint node D, either by the PCE
or the PCCs.
As specified in [I-D.ietf-teas-assoc-corouted-bidir-frr], for fast
reroute bypass tunnel assignment, the LSP with the higher Source reroute bypass tunnel assignment, the LSP with the higher Source
Address [RFC3209] is identified as the forward LSP of the Address [RFC3209] is identified as the forward LSP of the
double-sided initiated bidirectional LSP. double-sided initiated bidirectional LSP.
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 2, where both reverse LSPs may be co-routed as shown in Figure 4, where both
forward and reverse LSPs follow the same congruent path in the forward and reverse LSPs of a bidirectional LSP follow the same
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 2: Example of Co-routed Associated Bidirectional LSP Figure 4: Example of Co-routed Associated Bidirectional LSP
4. Protocol Extensions 4. Protocol Extensions
4.1. Association Object 4.1. Association Object
As per [I-D.ietf-pce-association], LSPs are associated by adding them As per [I-D.ietf-pce-association], LSPs are associated by adding them
to a common association group. This document defines two new to a common association group. This document defines two new
Bidirectional LSP Association Groups to be used by the associated Bidirectional LSP Association Groups to be used by the associated
bidirectional LSPs. A member of the Bidirectional LSP Association bidirectional LSPs. A member of the Bidirectional LSP Association
Group can take the role of a forward or reverse LSP and follows the Group can take the role of a forward or reverse LSP and follows the
following rules: following rules:
o An LSP can not be part of more than one Bidirectional LSP o An LSP (forward or reverse) can not be part of more than one
Association Group. Bidirectional LSP Association Group. More than one forward LSP
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 The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs
of the single-sided bidirectional association MUST be the same. of the single-sided bidirectional LSP association on the
originating node MUST be the same.
This document defines two new Association Types for the Association This document defines two new Association Types for the Association
Object as follows: Object as follows:
o Association Type (TBD1) = Single-sided Bidirectional LSP o Association Type (TBD1) = Single-sided Bidirectional LSP
Association Group Association Group
o Association Type (TBD2) = Double-sided Bidirectional LSP o Association Type (TBD2) = Double-sided Bidirectional LSP
Association Group Association Group
skipping to change at page 7, line 19 skipping to change at page 9, line 6
nature and statically created by the operator on the PCEP peers. The nature and statically created by the operator on the PCEP peers. The
LSP belonging to these associations is conveyed via PCEP messages to LSP belonging to these associations is conveyed via PCEP messages to
the PCEP peer. Operator-configured Association Range TLV the PCEP peer. Operator-configured Association Range TLV
[I-D.ietf-pce-association] MUST NOT be sent for these Association [I-D.ietf-pce-association] MUST NOT be sent for these Association
Types, and MUST be ignored, so that the entire range of association Types, and MUST be ignored, so that the entire range of association
ID can be used for them. ID can be used for them.
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 Group Object are initialized using the procedures defined
in [RFC7551] and [I-D.ietf-pce-association]. in [I-D.ietf-pce-association] and [RFC7551].
4.2. Bidirectional LSP Association Group TLV 4.2. Bidirectional LSP Association Group TLV
The Bidirectional LSP Association Group TLV is an optional TLV for The Bidirectional LSP Association Group TLV is defined for use with
use with the Single-sided and Double-sided Bidirectional LSP the Single-sided and Double-sided Bidirectional LSP Association Group
Association Group Object Types. Object Types.
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 Flags (32 bits), where each bit represents a flag Association Flags (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. 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 reverse LSPs, this TLV MUST be present.
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 in
Figure 3: Figure 5:
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| | Reserved |C|R|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bidirectional LSP Association Group TLV format Figure 5: Bidirectional LSP Association Group TLV format
Bidirectional LSP Association Flags are defined as following. Bidirectional LSP Association Flags are defined as following.
F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the F (Forward LSP, 1 bit) - Indicates whether the LSP associated is the
forward LSP of the bidirectional LSP. If this flag is set, the LSP forward LSP of the bidirectional LSP. If this flag is set, the LSP
is a forward LSP. is a forward LSP.
R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the R (Reverse LSP, 1 bit) - Indicates whether the LSP associated is the
reverse LSP of the bidirectional LSP. If this flag is set, the LSP reverse LSP of the bidirectional LSP. If this flag is set, the LSP
is a reverse LSP. is a reverse LSP.
C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is C (Co-routed LSP, 1 bit) - Indicates whether the bidirectional LSP is
co-routed. This flag MUST be set for both the forward and reverse co-routed. This flag MUST be set for both the forward and reverse
LSPs of a co-routed bidirectional LSP. 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. compute bidirectional paths of the forward and reverse LSPs of a
co-routed bidirectional LSP.
The Reserved flags MUST be set to 0 when sent and MUST be ignored The Reserved flags MUST be set to 0 when sent and MUST be ignored
when received. when received.
5. PCEP Procedure 5. PCEP Procedure
5.1. PCE Initiated LSPs 5.1. PCE Initiated LSPs
As specified in [I-D.ietf-pce-association], Association Groups can be As specified in [I-D.ietf-pce-association], Bidirectional LSP
created by both Stateful PCE and PCC. Association Groups can be created by a Stateful PCE.
A Stateful PCE can create and update the forward and reverse LSPs o Stateful PCE can create and update the forward and reverse LSPs
independently for both Single-sided and Double-sided bidirectional independently for both single-sided and double-sided bidirectional
LSP association groups. The establishment and removal of the LSP association groups.
association relationship can be done on a per LSP basis. A PCE can
create and update the association of the LSP on a PCC via PCInitiate o Stateful PCE can establish and remove the association relationship
and PCUpd messages, respectively, using the procedures described in on a per LSP basis.
[I-D.ietf-pce-association].
o Stateful PCE can create and update the LSP and the association on
a PCC via PCInitiate and PCUpd messages, respectively, using the
procedures described in [I-D.ietf-pce-association].
5.2. PCC Initiated LSPs 5.2. PCC Initiated LSPs
A PCC can create and update the forward and reverse LSPs As specified in [I-D.ietf-pce-association], Bidirectional LSP
independently for both Single-sided and Double-sided bidirectional Association Groups can also be created by a PCC.
LSP association groups. The establishment and removal of the
association relationship can be done on a per LSP basis. In both o PCC can create and update the forward and reverse LSPs
cases, the PCC must report the change in association to PCE(s) via independently for both single-sided and double-sided bidirectional
PCRpt message. A PCC can also delegate the forward and reverse LSPs LSP association groups.
to a Stateful PCE, where PCE would control the LSPs. The Stateful
PCE could update the LSPs in the association group via PCUpd message, o PCC can establish and remove the association relationship on a per
using the procedures described in [I-D.ietf-pce-association]. LSP basis.
o PCC MUST report the change in the association group of an LSP to
PCE(s) via PCRpt message.
o PCC can report the forward and reverse LSPs independently to
PCE(s) via PCRpt message.
o PCC can delegate the forward and reverse LSPs independently to a
Stateful PCE, where PCE would control the LSPs. For single-sided
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
association group via PCUpd message, using the procedures
described in [I-D.ietf-pce-association].
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. A PCC can request co-routed or non co-routed forward
and reverse direction paths from a stateless PCE for the and reverse direction paths from a stateless PCE for a bidirectional
bidirectional LSP association group. LSP association group.
5.4. State Synchronization 5.4. 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 association groups to the Stateful PCE as per
[I-D.ietf-pce-association]. After the state synchronization, the PCE [I-D.ietf-pce-association]. After the state synchronization, the PCE
MUST remove all stale bidirectional associations. MUST remove all stale bidirectional LSP associations.
5.5. Error Handling 5.5. Error Handling
An LSP (forward or reverse) can not be part of more than one
Bidirectional LSP Association Group. If a PCE attempts to add an LSP
not complying to this rule, the PCC MUST send PCErr with Error-Type =
29 (Early allocation by IANA) (Association Error) and Error-Value =
TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if
a PCC attempts to add an LSP at PCE not complying to this rule, the
PCE MUST send this PCErr.
The LSPs (forward or reverse) in a single-sided bidirectional LSP The LSPs (forward or reverse) in a single-sided bidirectional LSP
association group MUST belong to the same TE Tunnel (as defined in association group MUST belong to the same TE Tunnel (as defined in
[RFC3209]). If a PCE attempts to add an LSP in a single-sided [RFC3209]). If a PCE attempts to add an LSP in a single-sided
bidirectional LSP association group for a different Tunnel, the PCC bidirectional LSP association group for a different Tunnel, the PCC
MUST send PCErr with Error-Type = 29 (Early allocation by IANA) MUST send PCErr with Error-Type = 29 (Early allocation by IANA)
(Association Error) and Error-Value = TBD4 (Bidirectional Association (Association Error) and Error-Value = TBD5 (Bidirectional LSP
Tunnel Mismatch). Similarly, if a PCC attempts to add an LSP to a Association - Tunnel Mismatch). Similarly, if a PCC attempts to add
single-sided bidirectional LSP association group at PCE not complying an LSP to a single-sided bidirectional LSP association group at PCE
to this rule, the PCE MUST send this PCErr. not complying to this rule, the PCE MUST send this PCErr.
6. Security Considerations 6. 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, Double-sided Two new Association Types for the Association Object, Single-sided
Bidirectional LSP Association Group and Single-sided Associated Bidirectional LSP Association Group and Double-sided Associated
Bidirectional LSP Group are introduced in this document. Additional Bidirectional LSP Group are introduced in this document. Additional
security considerations related to LSP associations due to a security considerations related to LSP associations due to a
malicious PCEP speaker is described in [I-D.ietf-pce-association] and malicious PCEP speaker is described in [I-D.ietf-pce-association] and
apply to these Association Types. Hence, securing the PCEP session apply to these Association Types. Hence, securing the PCEP session
using Transport Layer Security (TLS) [RFC8253] is recommended. using Transport Layer Security (TLS) [RFC8253] is recommended.
7. Manageability Considerations 7. Manageability Considerations
7.1. Control of Function and Policy 7.1. Control of Function and Policy
skipping to change at page 12, line 6 skipping to change at page 14, line 26
8.3. PCEP Errors 8.3. PCEP Errors
This document defines new Error value for Error Type 29 (Association This document defines new Error value for Error Type 29 (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
--------------------------------------------------------------------- ---------------------------------------------------------------------
29 Association Error 29 Association Error
Error value: TBD4 [This document] Error value: TBD4 [This document]
Bidirectional Association Tunnel Mismatch Bidirectional LSP Association - Group Mismatch
Error value: TBD5 [This document]
Bidirectional LSP Association - Tunnel Mismatch
9. References 9. References
9.1. Normative References 9.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, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997. 10.17487/RFC2119, March 1997.
[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 13, line 29 skipping to change at page 15, line 29
March 2009. March 2009.
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
Extensions for Associated Bidirectional LSPs", RFC 7551, Extensions for Associated Bidirectional LSPs", RFC 7551,
May 2015. May 2015.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017. RFC 8126, DOI 10.17487/RFC8126, June 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, DOI Extensions for Stateful PCE", RFC 8231, DOI
10.17487/RFC8231, September 2017. 10.17487/RFC8231, September 2017.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", RFC 8281, December 2017. Model", RFC 8281, December 2017.
[I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S., [I-D.ietf-pce-association] Minei, I., Crabbe, E., Sivabalan, S.,
skipping to change at page 15, line 7 skipping to change at page 17, line 7
Computation Element Communication Protocol (PCEP)", RFC Computation Element Communication Protocol (PCEP)", RFC
8253, October 2017. 8253, October 2017.
[I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J.
Tantsura, "A YANG Data Model for Path Computation Element Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
(work in progress). (work in progress).
Acknowledgments Acknowledgments
Authors would like to thank Dhruv Dhody for various discussions on The authors would like to thank Dhruv Dhody for various discussions
association groups. on association groups. The authors would also like to thank Dhruv
Dhody and Mike Taillon for reviewing this document and providing
valuable comments.
Authors' Addresses Authors' Addresses
Colby Barth Colby Barth
Juniper Networks Juniper Networks
Email: cbarth@juniper.net Email: cbarth@juniper.net
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 37 change blocks. 
103 lines changed or deleted 207 lines changed or added

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