< draft-ietf-pce-pcep-extension-for-pce-controller-07.txt   draft-ietf-pce-pcep-extension-for-pce-controller-08.txt >
PCE Working Group Z. Li PCE Working Group Z. Li
Internet-Draft S. Peng Internet-Draft S. Peng
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: March 5, 2021 M. Negi Expires: May 5, 2021 M. Negi
RtBrick India RtBrick Inc
Q. Zhao Q. Zhao
Etheric Networks Etheric Networks
C. Zhou C. Zhou
HPE HPE
September 1, 2020 November 1, 2020
PCEP Procedures and Protocol Extensions for Using PCE as a Central PCEP Procedures and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs Controller (PCECC) of LSPs
draft-ietf-pce-pcep-extension-for-pce-controller-07 draft-ietf-pce-pcep-extension-for-pce-controller-08
Abstract Abstract
The Path Computation Element (PCE) is a core component of Software- The Path Computation Element (PCE) is a core component of Software-
Defined Networking (SDN) systems. It can compute optimal paths for Defined Networking (SDN) systems. It can compute optimal paths for
traffic across a network and can also update the paths to reflect traffic across a network and can also update the paths to reflect
changes in the network or traffic demands. changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths PCE was developed to derive paths for MPLS Label Switched Paths
(LSPs), which are supplied to the head end of the LSP using the Path (LSPs), which are supplied to the head end of the LSP using the Path
Computation Element Communication Protocol (PCEP). But SDN has a Computation Element Communication Protocol (PCEP). But SDN has a
broader applicability than signaled MPLS and GMPLS traffic-engineered broader applicability than signaled MPLS and GMPLS traffic-engineered
(TE) networks, and the PCE may be used to determine paths in a range (TE) networks, and the PCE may be used to determine paths in a range
of use cases. PCEP has been proposed as a control protocol for use of use cases. PCEP has been proposed as a control protocol for use
in these environments to allow the PCE to be fully enabled as a in these environments to allow the PCE to be fully enabled as a
central controller. central controller.
A PCE-based central controller (PCECC) can simplify the processing of A PCE-based Central Controller (PCECC) can simplify the processing of
a distributed control plane by blending it with elements of SDN and a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the LSP can be without necessarily completely replacing it. Thus, the LSP can be
calculated/setup/initiated and the label forwarding entries can also calculated/set up/initiated and the label forwarding entries can also
be downloaded through a centralized PCE server to each network be downloaded through a centralized PCE server to each network device
devices along the path while leveraging the existing PCE technologies along the path, while leveraging the existing PCE technologies as
as much as possible. much as possible.
This document specifies the procedures and PCEP extensions for using This document specifies the procedures and PCEP extensions for using
the PCE as the central controller. the PCE as the central controller.
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 5, 2021. This Internet-Draft will expire on May 5, 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
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. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5
4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6
5. Procedures for Using the PCE as the Central Controller 5. Procedures for Using the PCE as a Central Controller (PCECC) 6
(PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6
5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6
5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7 5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7
5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 7 5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 7
5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8
5.5.1. Basic PCECC LSP set up . . . . . . . . . . . . . . . 8 5.5.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 8
5.5.2. Central Controller Instructions . . . . . . . . . . . 12 5.5.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 12
5.5.2.1. Label Download CCI . . . . . . . . . . . . . . . 12 5.5.3. Central Controller Instructions . . . . . . . . . . . 14
5.5.2.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 12 5.5.3.1. Label Download CCI . . . . . . . . . . . . . . . 15
5.5.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 13 5.5.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 15
5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 15 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 16
5.5.5. Re-Delegation and Cleanup . . . . . . . . . . . . . . 17 5.5.5. Re-Delegation and Clean up . . . . . . . . . . . . . 19
5.5.6. Synchronization of Central Controllers Instructions . 17 5.5.6. Synchronization of Central Controllers Instructions . 19
5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 20
5.5.8. PCC Based Allocations . . . . . . . . . . . . . . . . 18 5.5.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 20
5.5.9. Binding Label . . . . . . . . . . . . . . . . . . . . 18 5.5.9. Binding Label . . . . . . . . . . . . . . . . . . . . 20
6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 19 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 19 6.1. The PCInitiate Message . . . . . . . . . . . . . . . . . 22
6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 21 6.2. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23
7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 22 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24
7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 25
7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 23 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 25
7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 26
7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 27
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 28
8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 26 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 29
10. Manageability Considerations . . . . . . . . . . . . . . . . 27 10. Manageability Considerations . . . . . . . . . . . . . . . . 30
10.1. Control of Function and Policy . . . . . . . . . . . . . 27 10.1. Control of Function and Policy . . . . . . . . . . . . . 30
10.2. Information and Data Models . . . . . . . . . . . . . . 27 10.2. Information and Data Models . . . . . . . . . . . . . . 30
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 27 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 30
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 27 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 30
10.5. Requirements On Other Protocols . . . . . . . . . . . . 27 10.5. Requirements On Other Protocols . . . . . . . . . . . . 30
10.6. Impact On Network Operations . . . . . . . . . . . . . . 28 10.6. Impact On Network Operations . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 31
11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 28 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 31
11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 28 11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 31
11.4. Path Setup Type Registry . . . . . . . . . . . . . . . . 29 11.4. Path Setup Type Registry . . . . . . . . . . . . . . . . 31
11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 29 11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 32
11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 29 11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 32
11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 29 11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The Path Computation Element (PCE) [RFC4655] was developed to offload The Path Computation Element (PCE) [RFC4655] was developed to offload
path computation function from routers in an MPLS traffic-engineered the path computation function from routers in an MPLS traffic-
network. Since then, the role and function of the PCE has grown to engineered network. Since then, the role and function of the PCE has
cover a number of other uses (such as GMPLS [RFC7025]) and to allow grown to cover a number of other uses (such as GMPLS [RFC7025]) and
delegated control [RFC8231] and PCE-initiated use of network to allow delegated control [RFC8231] and PCE-initiated use of network
resources [RFC8281]. resources [RFC8281].
According to [RFC7399], Software-Defined Networking (SDN) refers to a According to [RFC7399], Software-Defined Networking (SDN) refers to a
separation between the control elements and the forwarding components separation between the control elements and the forwarding components
so that software running in a centralized system, called a so that software running in a centralized system, called a
controller, can act to program the devices in the network to behave controller, can act to program the devices in the network to behave
in specific ways. A required element in an SDN architecture is a in specific ways. A required element in an SDN architecture is a
component that plans how the network resources will be used and how component that plans how the network resources will be used and how
the devices will be programmed. It is possible to view this the devices will be programmed. It is possible to view this
component as performing specific computations to place traffic flows component as performing specific computations to place traffic flows
skipping to change at page 4, line 36 skipping to change at page 4, line 36
[RFC8283] introduces the architecture for PCE as a central controller [RFC8283] introduces the architecture for PCE as a central controller
as an extension of the architecture described in [RFC4655] and as an extension of the architecture described in [RFC4655] and
assumes the continued use of PCEP as the protocol used between PCE assumes the continued use of PCEP as the protocol used between PCE
and PCC. [RFC8283] further examines the motivations and and PCC. [RFC8283] further examines the motivations and
applicability for PCEP as a Southbound Interface (SBI), and applicability for PCEP as a Southbound Interface (SBI), and
introduces the implications for the protocol. introduces the implications for the protocol.
[I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC
architecture. architecture.
A PCE-based central controller (PCECC) can simplify the processing of A PCE-based Central Controller (PCECC) can simplify the processing of
a distributed control plane by blending it with elements of SDN and a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the LSP can be without necessarily completely replacing it. Thus, the LSP can be
calculated/setup/initiated and the label forwarding entries can also calculated/setup/initiated and the label forwarding entries can also
be downloaded through a centralized PCE server to each network be downloaded through a centralized PCE server to each network
devices along the path while leveraging the existing PCE technologies devices along the path while leveraging the existing PCE technologies
as much as possible. as much as possible.
This document specifies the procedures and PCEP protocol extensions This document specifies the procedures and PCEP extensions for using
for using the PCE as the central controller for static LSPs, where the PCE as the central controller for static LSPs, where LSPs can be
LSPs can be provisioned as explicit label instructions at each hop on provisioned as explicit label instructions at each hop on the end-to-
the end-to-end path. Each router along the path must be told what end path. Each router along the path must be told what label-
label-forwarding instructions to program and what resources to forwarding instructions to program and what resources to reserve.
reserve. The PCE-based controller keeps a view of the network and The PCE-based controller keeps a view of the network and determines
determines the paths of the end-to-end LSPs, and the controller uses the paths of the end-to-end LSPs, and the controller uses PCEP to
PCEP to communicate with each router along the path of the end-to-end communicate with each router along the path of the end-to-end LSP.
LSP.
While this document is focused on the procedures for the static LSPs While this document is focused on the procedures for the static LSPs
(referred to as basic PCECC mode in Section 3), the mechanism and (referred to as basic PCECC mode in Section 3), the mechanisms and
protocol encoding are specified in such a way that, extensions for protocol encodings are specified in such a way that extensions for
other use cases is easy to achieve. For example, the extensions for other use cases are easy to achieve. For example, the extensions for
PCECC for Segment Routing (SR) are specified in PCECC for Segment Routing (SR) are specified in
[I-D.zhao-pce-pcep-extension-pce-controller-sr] and [I-D.zhao-pce-pcep-extension-pce-controller-sr] and
[I-D.dhody-pce-pcep-extension-pce-controller-srv6]. [I-D.dhody-pce-pcep-extension-pce-controller-srv6].
1.1. Requirements Language 1.1. Requirements Language
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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
similar to the existing stateful PCE mechanism. similar to the existing stateful PCE mechanism.
This document also allows a case where the label space is maintained This document also allows a case where the label space is maintained
by the PCC itself, and the labels are allocated by the PCC, in this by the PCC itself, and the labels are allocated by the PCC, in this
case, the PCE should request the allocation from PCC as described in case, the PCE should request the allocation from PCC as described in
Section 5.5.8. Section 5.5.8.
4. PCEP Requirements 4. PCEP Requirements
The following key requirements should be considered when designing The following key requirements should be considered when designing
the PCECC based solution: the PCECC-based solution:
1. PCEP speaker supporting this draft needs to have the capability 1. A PCEP speaker supporting this draft needs to have the capability
to advertise its PCECC capability to its peers. to advertise its PCECC capability to its peers.
2. PCEP speaker needs the means to identify PCECC based LSP in the 2. A PCEP speaker need means to identify PCECC-based LSP in the PCEP
PCEP messages. messages.
3. PCEP procedures need to allow for PCC based label allocations. 3. PCEP procedures need to allow for PCC-based label allocations.
4. PCEP procedures need to provide a means to update (or cleanup) 4. PCEP procedures need to provide a mean to update (or clean up)
the label-download entry to the PCC. the label-download entry to the PCC.
5. PCEP procedures need to provide a means to synchronize the labels 5. PCEP procedures need to provide a mean to synchronize the labels
between PCE and PCC via PCEP messages. between the PCE and the PCC via PCEP messages.
5. Procedures for Using the PCE as the Central Controller (PCECC) 5. Procedures for Using the PCE as a Central Controller (PCECC)
5.1. Stateful PCE Model 5.1. Stateful PCE Model
Active stateful PCE is described in [RFC8231]. PCE as a central Active stateful PCE is described in [RFC8231]. PCE as a central
controller (PCECC) reuses existing Active stateful PCE mechanism as controller (PCECC) reuses the existing active stateful PCE mechanism
much as possible to control the LSP. as much as possible to control LSPs.
5.2. New LSP Functions 5.2. New LSP Functions
Several new functions are required in PCEP to support PCECC. This Several new functions are required in PCEP to support PCECC. This
document extends the existing messages to support the new functions document extends the existing messages to support the new functions
required by PCECC: required by PCECC:
(PCInitiate): a PCEP message described in [RFC8281]. PCInitiate (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate
message is used to set up PCE-Initiated LSP based on PCECC message is used to set up PCE-Initiated LSP based on PCECC
mechanism. It is also extended for Central Controller mechanism. It is also extended for Central Controller
Instructions (CCI) (download or cleanup the Label forwarding Instructions (CCI) (download or clean up the Label forwarding
instructions in the context of this document) on all nodes along instructions in the context of this document) on all nodes along
the path. the path.
(PCRpt): a PCEP message described in [RFC8231]. PCRpt message is (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is
used to send PCECC LSP Reports. It is also extended to report the used to send PCECC LSP Reports. It is also extended to report the
set of Central Controller Instructions (CCI) (label forwarding set of Central Controller Instructions (CCI) (label forwarding
instructions in the context of this document) received from the instructions in the context of this document) received from the
PCE. See Section 5.5.6 for more details. PCE. See Section 5.5.6 for more details.
(PCUpd): a PCEP message described in [RFC8231]. PCUpd message is (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is
used to send PCECC LSP Update. used to send PCECC LSP Update.
The new functions defined in this document are mapped onto the PCEP The new functions defined in this document are mapped onto the PCEP
messages as shown in Table 1. messages as shown in Table 1.
Function Message Function Message
PCECC Capability advertisement Open PCECC Capability advertisement Open
Label entry Add PCInitiate Label entry Add PCInitiate
Label entry Cleanup PCInitiate Label entry Clean up PCInitiate
PCECC Initiated LSP PCInitiate PCECC Initiated LSP PCInitiate
PCECC LSP Update PCUpd PCECC LSP Update PCUpd
PCECC LSP State Report PCRpt PCECC LSP State Report PCRpt
PCECC LSP Delegation PCRpt PCECC LSP Delegation PCRpt
PCECC Label Report PCRpt PCECC Label Report PCRpt
Table 1: Functions mapped to the PCEP messages Table 1: Functions mapped to the PCEP messages
5.3. New PCEP Object 5.3. New PCEP Object
skipping to change at page 7, line 49 skipping to change at page 7, line 49
o PST = TBD1: Path is set up via PCECC mode. o PST = TBD1: Path is set up via PCECC mode.
A PCEP speaker MUST indicate its support of the function described in A PCEP speaker MUST indicate its support of the function described in
this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
object with this new PST included in the PST list. object with this new PST included in the PST list.
This document also defines the PCECC Capability sub-TLV This document also defines the PCECC Capability sub-TLV
Section 7.1.1. PCEP speakers use this sub-TLV to exchange Section 7.1.1. PCEP speakers use this sub-TLV to exchange
information about their PCECC capability. If a PCEP speaker includes information about their PCECC capability. If a PCEP speaker includes
PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then
it MUST also include the PCECC Capability sub-TLV inside the PATH- the receiving peer MUST also include the PCECC Capability sub-TLV
SETUP-TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP (with the L bit set to 1) inside the PATH-SETUP-TYPE-CAPABILITY TLV.
speaker MUST send a PCErr message with Error-Type 10 (Reception of an If the sub-TLV is absent or the L bit is not set to 1, then the
invalid object) and Error-Value TBD2 (Missing PCECC Capability sub- receiving PCEP speaker MUST send a PCErr message with Error-Type 10
TLV) and MUST then close the PCEP session. If a PCEP speaker (Reception of an invalid object) and Error-Value TBD2 (Missing PCECC
receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PCECC-CAPABILITY Capability sub-TLV) and MUST then close the PCEP session. If a PCEP
sub-TLV, but the PST list does not contain PST=TBD1, then the PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PCECC-
speaker MUST ignore the PCECC-CAPABILITY sub-TLV. CAPABILITY sub-TLV, but the PST list does not contain PST=TBD1, then
the PCEP speaker MUST ignore the PCECC-CAPABILITY sub-TLV.
The presence of the PST=TBD1 and PCECC Capability sub-TLV in a PCC's The presence of the PST=TBD1 and PCECC Capability sub-TLV (with the L
OPEN Object indicates that the PCC is willing to function as a PCECC bit set to 1, see Section 7.1.1) in a PCC's OPEN Object indicates
client. The presence of the PST=TBD1 and PCECC Capability sub-TLV in that the PCC is willing to function as a PCECC client for label
a PCE's OPEN message indicates that the PCE is interested in function download instructions. The presence of the PST=TBD1 and PCECC
as a PCECC server. Capability sub-TLV (with the L bit set to 1) in a PCE's OPEN message
indicates that the PCE is interested in function as a PCECC server
for label download instructions.
The PCEP protocol extensions for PCECC MUST NOT be used if one or The PCEP extensions for PCECC for label download MUST NOT be used if
both PCEP Speakers have not included the PST=TBD1 or the PCECC one or both PCEP Speakers have not included the PST=TBD1 or the PCECC
Capability sub-TLV in their respective OPEN message. If the PCEP Capability sub-TLV (with the L bit set to 1) in their respective OPEN
Speakers support the extensions of this draft but did not advertise message. If a PCEP speaker which supports the extensions of this
this capability attempts a PCECC operation then a PCErr message with draft but did not advertise this capability attempts a PCECC
Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted operation, then a PCErr message with Error-Type=19 (Invalid
PCECC operations when PCECC capability was not advertised) will be Operation) and Error-Value=TBD3 (Attempted PCECC operations when
generated and the PCEP session will be terminated. If a PCEP speaker PCECC capability was not advertised) MUST be generated by its peer
does not recognize the PCECC Capability sub-TLV, it will ignore the and the PCEP session will be terminated. If a PCEP speaker does not
sub-TLV in accordance with [RFC8408] and [RFC5440]. recognize the PCECC Capability sub-TLV, it will ignore the sub-TLV in
accordance with [RFC8408] and [RFC5440].
A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and A PCC or a PCE MUST include both the PCECC-CAPABILITY sub-TLV (with
STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) the L bit set to 1) and the STATEFUL-PCE-CAPABILITY TLV ([RFC8231])
in OPEN Object to support the extensions defined in this document. (with the I flag set [RFC8281]) in the OPEN Object to support the
If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY extensions defined in this document. If the PCECC-CAPABILITY sub-TLV
TLV is not advertised in OPEN Object, it MUST send a PCErr message is advertised and the STATEFUL-PCE-CAPABILITY TLV is not advertised
with Error-Type=19 (Invalid Operation) and Error-value=TBD4 (stateful in the OPEN Object, it MUST send a PCErr message with Error-Type=19
PCE capability was not advertised) and terminate the session. This (Invalid Operation) and Error-value=TBD4 (stateful PCE capability was
error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and not advertised) and terminate the session. This error is also
I flag in the STATEFUL-PCE-CAPABILITY TLV is not set. triggered if the PCECC-CAPABILITY sub-TLV is advertised and the I
flag in the STATEFUL-PCE-CAPABILITY TLV is not set.
5.5. LSP Operations 5.5. LSP Operations
The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE The PCEP messages pertaining to a PCECC MUST include PATH-SETUP-TYPE
TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is TLV [RFC8408] in the SRP object to clearly identify that PCECC LSP is
intended. intended.
5.5.1. Basic PCECC LSP set up 5.5.1. PCE-Initiated PCECC LSP
In order to set up an LSP based on the PCECC mechanism, a PCC MUST The LSP Instantiation operation is the same as defined in [RFC8281].
delegate the LSP by sending a PCRpt message with PST set for PCECC
(see Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the
LSP object.
An LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple In order to set up a PCE-Initiated LSP based on the PCECC mechanism,
a PCE sends PCInitiate message with Path Setup Type set for PCECC
(see Section 7.2) to the ingress PCC.
An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple
uniquely identifies the LSP in the network. The LSP object is uniquely identifies the LSP in the network. The LSP object is
included in the central controller instructions (label download) to included in the central controller instructions (label download
identify the PCECC LSP for this instruction. The PLSP-ID is the Section 7.3) to identify the PCECC LSP for this instruction. The
original identifier used by the ingress PCC, so the transit LSR could PLSP-ID is the original identifier used by the ingress PCC, so a
have multiple central controller instructions that have the same transit/egress LSR could have multiple central controller
PLSP-ID. The PLSP-ID in combination with the source (in LSP- instructions that have the same PLSP-ID. The PLSP-ID in combination
IDENTIFIER TLV) MUST be unique. The PLSP-ID is included for with the source (in LSP-IDENTIFIER TLV) MUST be unique. The PLSP-ID
maintainability reasons to ease debugging. As per [RFC8281], the LSP is included for maintainability reasons to ease debugging. As per
object could include SPEAKER-ENTITY-ID TLV to identify the PCE that [RFC8281], the LSP object could also include the SPEAKER-ENTITY-ID
initiated these instructions. Also, the CC-ID is unique in the PCEP TLV to identify the PCE that initiated these instructions. Also, the
session as described in Section 7.3. CC-ID is unique in the PCEP session as described in Section 7.3.
When a PCE receives a PCRpt message with D flag and PST Type set, it The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C
calculates the path and assigns labels along the path; and sets up (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message
the path by sending PCInitiate message to each node along the path of to the PCE. The PCC responds with a PCRpt message with the status
the LSP. The PCC generates a Path Computation State Report (PCRpt) set to "GOING-UP" and carrying the assigned PLSP-ID. When the PCE
and includes the central controller instruction (CCI) and the receives this PCRpt message with the PLSP-ID, it assigns labels along
identified LSP. The CC-ID uniquely identifies the central controller the path; and sets up the path by sending a PCInitiate message to
instruction within a PCEP session. The PCC further responds with the each node along the path of the LSP as per the PCECC technique. The
PCRpt messages including the CCI and LSP objects. CC-ID uniquely identifies the central controller instruction within a
PCEP session. Each PCC further responds with the PCRpt messages
including the central controller instruction (CCI) and the LSP
objects.
The Ingress node would receive one CCI object with O bit (out-label) Note that the label forwarding instructions (see Section 5.5.3) from
PCECC are sent after the initial PCInitiate and PCRpt message
exchange with the ingress PCC. This is done so that the PLSP-ID and
other LSP identifiers can be obtained from the ingress and can be
included in the label forwarding instruction in the next set of
PCInitiate messages.
The ingress node would receive one CCI object with O bit (out-label)
set. The transit node(s) would receive two CCI objects with the in- set. The transit node(s) would receive two CCI objects with the in-
label CCI without an O bit set and the out-label CCI with O bit set. label CCI without an O bit set and the out-label CCI with O bit set.
The egress node would receive one CCI object without O bit set. A The egress node would receive one CCI object without O bit set. A
node can determine its role based on the setting of the O bit in the node can determine its role based on the setting of the O bit in the
CCI object(s) and the LSP-IDENTIFIER TLV in the LSP object. CCI object(s) and the LSP-IDENTIFIER TLV in the LSP object.
The LSP deletion operation for PCE-Initiated PCECC LSP is the same as
defined in [RFC8281]. The PCE should further perform Label entry
clean up operation as described in Section 5.5.3.2 for the
corresponding LSP.
The PCE-Initiated PCECC LSP setup sequence is shown in Figure 1.
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP
|PCC +--------+ | | Initiate
|egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP
+--------+ | | (GOING-UP) |
| | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label
| | | | download
|------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI
| | | |
| |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label
| | | | download
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI
| | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label
| | | | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI
| | | |
| | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP
| | | (UP) | Update
| | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> |
| | | (UP) |
Figure 1: PCE-Initiated PCECC LSP
Once the label operations are completed, the PCE SHOULD send a PCUpd
message to the ingress PCC. The PCUpd message is as per [RFC8231].
The PCECC LSPs are considered to be 'up' by default (on receipt of
PCUpd message from PCE). The ingress MAY further choose to deploy a
data plane check mechanism and report the status back to the PCE via
a PCRpt message to make sure that the correct label instructions are
made along the path of the PCECC LSP (and it is ready to carry
traffic).
In the case where the label allocations are made by the PCC itself
(see Section 5.5.8), the PCE could request an allocation to be made
by the PCC, and then the PCC would send a PCRpt with the allocated
label encoded in the CC-ID object as shown in Figure 2 in the
configuration sequence from the egress towards the ingress along the
path.
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP
|PCC +--------+ | | Initiate
|egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP
+--------+ | | (GOING-UP) |
| | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label
| | | C=1 | download
|------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI
| | | Label=L1 |
| |<----- PCInitiate,PLSP-ID=2, ---------------| Labels
| | | CC-ID=Y1,C=1 | download
| | | CC-ID=Y2,C=0,L1 | CCI
| |----- PCRpt,PLSP-ID=2 ------------------->|
| | | CC-ID=Y1, Label=L2 |
| | | CC-ID=Y2 |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 -- | Label
| | | C=0,L2 | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI
| | | |
| | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1---| PCECC LSP
| | | (UP) | Update
- The O bit is set as before (and thus not included)
Figure 2: PCE-Initiated PCECC LSP (PCC allocation)
It should be noted that in this example, the request is made to the
egress node with the C bit set in the CCI object to indicate that the
label allocation needs to be done by the egress and the egress
responds with the allocated label to the PCE. The PCE further inform
the transit PCC without setting the C bit to 1 in the CCI object for
out-label but the C bit is set to 1 for in-label so the transit node
make the label allocation (for the in-label) and report to the PCE.
Similarly, the C bit is unset towards the ingress to complete all the
label allocation for the PCECC LSP.
5.5.2. PCC-Initiated PCECC LSP
In order to set up an LSP based on the PCECC mechanism where the LSP
is configured at the PCC, a PCC MUST delegate the LSP by sending a
PCRpt message with PST set for PCECC (see Section 7.2) and D
(Delegate) flag (see [RFC8231]) set in the LSP object.
When a PCE receives the initial PCRpt message with D flag and PST
Type set to TBD1, it SHOULD calculate the path and assigns labels
along the path; and sets up the path by sending a PCInitiate message
to each node along the path of the LSP as per the PCECC technique.
The CC-ID uniquely identifies the central controller instruction
within a PCEP session. Each PCC further responds with the PCRpt
messages including the central controller instruction (CCI) and the
LSP objects.
Once the central controller instructions (label operations) are Once the central controller instructions (label operations) are
completed, the PCE MUST send the PCUpd message to the Ingress PCC. completed, the PCE MUST send the PCUpd message to the ingress PCC.
Per [RFC8231], this PCUpd message should include the path information Per [RFC8231], this PCUpd message should include the path information
calculated by the PCE. calculated by the PCE.
Note that the PCECC LSPs MUST be delegated to a PCE at all times. Note that the PCECC LSPs MUST be delegated to a PCE at all times.
LSP deletion operation for PCECC LSP is the same as defined in The LSP deletion operation for PCECC LSPs is the same as defined in
[RFC8231]. If the PCE receives a PCRpt message for LSP deletion then [RFC8231]. If the PCE receives a PCRpt message for LSP deletion then
it does Label cleanup operation as described in Section 5.5.2.2 for it does label clean up operation as described in Section 5.5.3.2 for
the corresponding LSP. the corresponding LSP.
The Basic PCECC LSP setup sequence is as shown in Figure 1. The Basic PCECC LSP setup sequence is as shown in Figure 3.
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|Ingress| +-------+ |ingress| +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | transit| | |
+------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP
|PCC +--------+ | | |PCC +--------+ | |
|Egress | | | | |egress | | | |
+--------+ | | | +--------+ | | |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label
| | | L1,O=0 | download | | | L1,O=0 | download
|------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI
| | | | | | | |
| |<----- PCInitiate,PLSP-ID=1, ------------- | Labels | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels
| | | CC-ID=Y1,O=0,L2 | download | | | CC-ID=Y1,O=0,L2 | download
| | | CC-ID=Y2,O=1,L1 | CCI | | | CC-ID=Y2,O=1,L1 | CCI
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>|
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label
| | | L2,O=1 | download | | | L2,O=1 | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI
| | | | | | | |
| | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP
| | | | Update | | | | Update
| | | | | | | |
Figure 1: Basic PCECC LSP setup Figure 3: PCC-Initiated PCECC LSP
The PCECC LSPs are considered to be 'up' by default (on receipt of
PCUpd message from PCE). The Ingress MAY further choose to deploy a
data plane check mechanism and report the status back to the PCE via
a PCRpt message to make sure that the correct label instructions are
made along the path of the PCECC LSP (and it is ready to carry
traffic).
In the case where the label allocations are made by the PCC itself In the case where the label allocations are made by the PCC itself
(see Section 5.5.8), the PCE could request an allocation to be made (see Section 5.5.8), the PCE could request an allocation to be made
by the PCC, and where the PCC would send a PCRpt with the allocated by the PCC, and then the PCC would send a PCRpt with the allocated
label encoded in the CC-ID object as shown in Figure 2. label encoded in the CC-ID object as shown in Figure 4.
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|Ingress| +-------+ |ingress| +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | transit| | |
+------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP
|PCC +--------+ | | |PCC +--------+ | |
|Egress | | | | |egress | | | |
+--------+ | | | +--------+ | | |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label
| | | C=1 | download | | | C=1 | download
|------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI
| | | Label=L1 | | | | Label=L1 |
| |<----- PCInitiate,PLSP-ID=1, ------------- | Labels | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels
| | | CC-ID=Y1,C=1 | download | | | CC-ID=Y1,C=1 | download
| | | CC-ID=Y2,C=0,L1 | CCI | | | CC-ID=Y2,C=0,L1 | CCI
| |----- PCRpt,PLSP-ID=1 ------------------>| | |----- PCRpt,PLSP-ID=1 ------------------>|
skipping to change at page 11, line 36 skipping to change at page 14, line 36
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label
| | | C=0,L2 | download | | | C=0,L2 | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI
| | | | | | | |
| | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP
| | | | Update | | | | Update
| | | | | | | |
- The O bit is set as before (and thus not included) - The O bit is set as before (and thus not included)
Figure 2: Basic PCECC LSP setup (PCC allocation) Figure 4: PCC-Initiated PCECC LSP (PCC allocation)
It should be noted that in this example, the request is made to the In the case where the label allocations are made by the PCC itself
egress node with the C bit set in the CCI object to indicate that the (see Section 5.5.8), the procedure remains the same, with just an
label allocation needs to be done by the egress and the egress additional constraint on the configuration sequence.
responds with the allocated label to the PCE. The PCE would further
inform the transit PCC without setting the C bit in the CCI object
for out-label but the C-bit is set for in-label so the transit node
make the label allocation (for the in-label) and report to the PCE.
Similarly, the C bit is unset towards the ingress to complete all the
label allocation for the PCECC LSP.
5.5.2. Central Controller Instructions The rest of the PCC-Initiated PCECC LSP setup operations are the same
as those described in Section 5.5.1.
5.5.3. Central Controller Instructions
The new central controller instructions (CCI) for the label The new central controller instructions (CCI) for the label
operations in PCEP is done via the PCInitiate message, by defining a operations in PCEP is done via the PCInitiate message, by defining a
new PCEP Object for CCI operations. The local label range of each new PCEP Object for CCI operations. The local label range of each
PCC is assumed to be known at both the PCC and the PCE. PCC is assumed to be known by both the PCC and the PCE.
5.5.2.1. Label Download CCI 5.5.3.1. Label Download CCI
In order to set up an LSP based on PCECC, the PCE sends a PCInitiate In order to set up an LSP based on PCECC, the PCE sends a PCInitiate
message to each node along the path to download the Label instruction message to each node along the path to download the Label instruction
as described in Section 5.5.1. as described in Section 5.5.1 and Section 5.5.2.
The CCI object MUST be included, along with the LSP object in the The CCI object MUST be included, along with the LSP object in the
PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in the PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in the
LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP
object. object.
If a node (PCC) receives a PCInitiate message which includes a Label If a node (PCC) receives a PCInitiate message which includes a Label
to download as part of CCI, that is out of the range set aside for to download, as part of CCI, that is out of the range set aside for
the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC
failure) and Error-value=TBD6 (Label out of range) and MUST include failure) and Error-value=TBD6 (Label out of range) and MUST include
the SRP object to specify the error is for the corresponding label the SRP object to specify the error is for the corresponding label
update via PCInitiate message. If a PCC receives a PCInitiate update via PCInitiate message. If a PCC receives a PCInitiate
message but failed to download the Label entry, it MUST send a PCErr message but fails to download the Label entry, it MUST send a PCErr
message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7
(instruction failed) and MUST include the SRP object to specify the (instruction failed) and MUST include the SRP object to specify the
error is for the corresponding label update via PCInitiate message. error is for the corresponding label update via PCInitiate message.
A new PCEP object for central controller instructions (CCI) is A new PCEP object for central controller instructions (CCI) is
defined in Section 7.3. defined in Section 7.3.
5.5.2.2. Label Cleanup CCI 5.5.3.2. Label Clean up CCI
In order to delete an LSP based on PCECC, the PCE sends a central In order to delete an LSP based on PCECC, the PCE sends a central
controller instructions via a PCInitiate message to each node along controller instructions via a PCInitiate message to each node along
the path of the LSP to cleanup the Label forwarding instruction. the path of the LSP to clean up the Label forwarding instruction.
If the PCC receives a PCInitiate message but does not recognize the If the PCC receives a PCInitiate message but does not recognize the
label in the CCI, the PCC MUST generate a PCErr message with Error- label in the CCI, the PCC MUST generate a PCErr message with Error-
Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and
MUST include the SRP object to specify the error is for the MUST include the SRP object to specify the error is for the
corresponding label cleanup (via PCInitiate message). corresponding label clean up (via PCInitiate message).
The R flag in the SRP object defined in [RFC8281] specifies the The R flag in the SRP object defined in [RFC8281] specifies the
deletion of Label Entry in the PCInitiate message. deletion of Label Entry in the PCInitiate message.
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|Ingress| +-------+ |ingress| +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | transit| | |
+------| | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1,R=1-->| PCECC LSP +------| | | |
|PCC +--------+ | | remove |PCC +--------+ | |
|Egress | | | | |egress | | | |
+--------+ | | | +--------+ | | |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=2 ------------ | Label
| | | R=1 | cleanup | | | R=1 | clean up
|------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 -- | Label
| | | R=1 | cleanup | | | R=1 | clean up
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 -- | Label
| | | R=1 | cleanup | | | R=1 | clean up
| | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI
| | | | | | | |
| | |<--PCInitiate,PLSP-ID=2,PST=TBD1,R=1--| PCECC LSP
| | | | remove
Figure 3: Label Cleanup Figure 5: Label Cleanup
As per [RFC8281], following the removal of the Label forwarding As per [RFC8281], following the removal of the Label forwarding
instruction, the PCC MUST send a PCRpt message. The SRP object in instruction, the PCC MUST send a PCRpt message. The SRP object in
the PCRpt MUST include the SRP-ID-number from the PCInitiate message the PCRpt MUST include the SRP-ID-number from the PCInitiate message
that triggered the removal. The R flag in the SRP object MUST be that triggered the removal. The R flag in the SRP object MUST be
set. set.
In the case where the label allocation is made by the PCC itself (see In the case where the label allocation is made by the PCC itself (see
Section 5.5.8), the removal procedure remains the same. Section 5.5.8), the removal procedure remains the same, adding the
sequence constraint.
5.5.3. PCE Initiated PCECC LSP
The LSP Instantiation operation is the same as defined in [RFC8281].
In order to set up a PCE Initiated LSP based on the PCECC mechanism,
a PCE sends PCInitiate message with Path Setup Type set for PCECC
(see Section 7.2) to the Ingress PCC.
The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C
(Create) flag (see [RFC8281]) in the LSP object of PCRpt message.
The PCC responds with a PCRpt message with the status set to "GOING-
UP" and carrying the assigned PLSP-ID.
Note that the label forwarding instructions from PCECC are sent after
the initial PCInitiate and PCRpt exchange. This is done so that the
PLSP-ID and other LSP identifiers can be obtained from the ingress
and can be included in the label forwarding instruction in the next
PCInitiate message. The rest of the PCECC LSP setup operations are
the same as those described in Section 5.5.1.
The LSP deletion operation for PCE Initiated PCECC LSP is the same as
defined in [RFC8281]. The PCE should further perform Label entry
cleanup operation as described in Section 5.5.2.2 for the
corresponding LSP.
The PCE Initiated PCECC LSP setup sequence is shown in Figure 4.
+-------+ +-------+
|PCC | | PCE |
|Ingress| +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP
|PCC +--------+ | | Initiate
|Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP
+--------+ | | (GOING-UP) |
| | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label
| | | | download
|------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI
| | | |
| |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label
| | | | download
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI
| | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label
| | | | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI
| | | |
| | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP
| | | (UP) | Update
| | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> |
| | | (UP) |
Figure 4: PCE Initiated PCECC LSP
Once the label operations are completed, the PCE SHOULD send a PCUpd
message to the Ingress PCC. The PCUpd message is as per [RFC8231].
In the case where the label allocations are made by the PCC itself
(see Section 5.5.8), the procedure remains the same.
5.5.4. PCECC LSP Update 5.5.4. PCECC LSP Update
In case of a modification of a PCECC LSP with a new path, a PCE sends In case of a modification of a PCECC LSP with a new path, a PCE sends
a PCUpd message to the Ingress PCC. But to follow the make-before- a PCUpd message to the ingress PCC. But to follow the make-before-
break procedures, the PCECC first update new instructions based on break procedures, the PCECC first updates new instructions based on
the updated LSP and then update to ingress to switch traffic, before the updated LSP and then update to the ingress to switch traffic,
cleaning up the old instructions. A new CC-ID is used to identify before cleaning up the former instructions. A new CC-ID is used to
the updated instruction, the existing identifiers in the LSP object identify the updated instruction, the existing identifiers in the LSP
identify the existing LSP. Once new instructions are downloaded, the object identify the existing LSP. Once new instructions are
PCE further updates the new path at the ingress which triggers the downloaded, the PCE further updates the new path at the ingress which
traffic switch on the updated path. The Ingress PCC acknowledges triggers the traffic switch on the updated path. The ingress PCC
with a PCRpt message, on receipt of the PCRpt message, the PCE does acknowledges with a PCRpt message, on receipt of the PCRpt message,
cleanup operation for the old LSP as described in Section 5.5.2.2. the PCE does clean up operation for the former LSP as described in
Section 5.5.3.2.
The PCECC LSP Update sequence is shown in Figure 5. The PCECC LSP Update sequence is shown in Figure 6.
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|Ingress| +-------+ |ingress| +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | transit| | |
+------| | | | +------| | | |
|PCC +--------+ | | |PCC +--------+ | |
|Egress | | | | |egress | | | |
+--------+ | | | +--------+ | | |
| | | | New Path | | | | New Path
|<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP
| | | | trigger | | | | trigger
|------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label
| | | | download | | | | download
| |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label
| | | | download | | | | download
| | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI
| | | | | | | |
| | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC | | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC
| | | SRP=S | LSP Update | | | SRP=S | LSP Update
| | | | | | | |
| | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger | | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger
| | | (SRP=S) | Delete old | | | (SRP=S) | Delete
| | | | CCI | | | | former CCI
| | | | | | | |
|<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label
| | | R=1 | cleanup | | | R=1 | clean up
|------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label
| | | R=1 | cleanup | | | R=1 | clean up
| |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label
| | | R=1 | cleanup | | | R=1 | clean up
| | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI
| | | | | | | |
Figure 5: PCECC LSP Update Figure 6: PCECC LSP Update
The modified PCECC LSPs are considered to be 'up' by default. The The modified PCECC LSPs are considered to be 'up' by default. The
Ingress MAY further choose to deploy a data plane check mechanism and ingress MAY further choose to deploy a data plane check mechanism and
report the status back to the PCE via a PCRpt message. report the status back to the PCE via a PCRpt message.
In the case where the label allocations are made by the PCC itself In the case where the label allocations are made by the PCC itself
(see Section 5.5.8), the procedure remains the same. (see Section 5.5.8), the procedure remains the same.
5.5.5. Re-Delegation and Cleanup 5.5.5. Re-Delegation and Clean up
As described in [RFC8281], a new PCE can gain control over an As described in [RFC8281], a new PCE can gain control over an
orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain
control over the central controller instructions in the same way by control over the central controller instructions in the same way by
sending a PCInitiate message that includes the SRP, LSP, and CCI sending a PCInitiate message that includes the SRP, LSP, and CCI
objects and carries the CC-ID and PLSP-ID identifying the objects and carries the CC-ID and PLSP-ID identifying the instruction
instruction, it wants to take control of. that it wants to take control of.
Further, as described in [RFC8281], the State Timeout Interval timer Further, as described in [RFC8281], the State Timeout Interval timer
ensures that a PCE crash does not result in automatic and immediate ensures that a PCE crash does not result in automatic and immediate
disruption for the services using PCE-initiated LSPs. Similarly the disruption for the services using PCE-initiated LSPs. Similarly the
central controller instructions are not removed immediately upon PCE central controller instructions are not removed immediately upon PCE
failure. Instead, they are cleaned up on the expiration of this failure. Instead, they are cleaned up on the expiration of this
timer. This allows for network cleanup without manual intervention. timer. This allows for network clean up without manual intervention.
The PCC MUST support the removal of CCI as one of the behaviors The PCC MUST support the removal of CCI as one of the behaviors
applied on expiration of the State Timeout Interval timer. applied on expiration of the State Timeout Interval timer.
In case of PCC-initiated PCECC LSP, the control over the orphaned LSP
at the ingress PCC is taken over by the mechanism specified in
[RFC8741] to request delegation. The control over the central
controller instructions is described above using [RFC8281].
5.5.6. Synchronization of Central Controllers Instructions 5.5.6. Synchronization of Central Controllers Instructions
The purpose of Central Controllers Instructions synchronization The purpose of Central Controllers Instructions synchronization
(labels in the context of this document) is to make sure that the (labels in the context of this document) is to make sure that the
PCE's view of CCI (Labels) matches with the PCC's Label allocation. PCE's view of CCI (Labels) matches with the PCC's Label allocation.
This synchronization is performed as part of the LSP state This synchronization is performed as part of the LSP state
synchronization as described in [RFC8231] and [RFC8233]. synchronization as described in [RFC8231] and [RFC8232].
As per LSP State Synchronization [RFC8231], a PCC reports the state As per LSP State Synchronization [RFC8231], a PCC reports the state
of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE
would initiate any missing LSPs and/or remove any LSPs that are not would initiate any missing LSPs and/or remove any LSPs that are not
wanted. The same PCEP messages and procedures are also used for the wanted. The same PCEP messages and procedures are also used for the
Central Controllers Instructions synchronization. The PCRpt message Central Controllers Instructions synchronization. The PCRpt message
includes the CCI and the LSP object to report the label forwarding includes the CCI and the LSP object to report the label forwarding
instructions. The PCE would further remove any unwanted instructions instructions. The PCE would further remove any unwanted instructions
or initiate any missing instructions. or initiate any missing instructions.
5.5.7. PCECC LSP State Report 5.5.7. PCECC LSP State Report
As mentioned before, an Ingress PCC MAY choose to apply any OAM As mentioned before, an ingress PCC MAY choose to apply any OAM
mechanism to check the status of LSP in the Data plane and MAY mechanism to check the status of LSP in the Data plane and MAY
further send its status in a PCRpt message to the PCE. further send its status in a PCRpt message to the PCE.
5.5.8. PCC Based Allocations 5.5.8. PCC-Based Allocations
The PCE can request the PCC to allocate the label using the The PCE can request the PCC to allocate the label using the
PCInitiate message. The C flag in the CCI object is set to 1 to PCInitiate message. The C flag in the CCI object is set to 1 to
indicate that the allocation needs to be done by the PCC. The PCC indicate that the allocation needs to be done by the PCC. The PCC
would allocate the Label and would report to the PCE using the PCRpt SHOULD allocate the Label and SHOULD report to the PCE using the
message. PCRpt message.
If the value of the Label is 0 and the C flag is set, it indicates If the value of the Label is 0 and the C flag is set to 1, it
that the PCE is requesting the allocation to be done by the PCC. If indicates that the PCE is requesting the allocation to be done by the
the Label is 'n' and the C flag is set in the CCI object, it PCC. If the Label is 'n' and the C flag is set to 1 in the CCI
indicates that the PCE requests a specific value 'n' for the Label. object, it indicates that the PCE requests a specific value 'n' for
If the allocation is successful, the PCC should report via the PCRpt the Label. If the allocation is successful, the PCC MUST report via
message with the CCI object. Else, it MUST send a PCErr message with the PCRpt message with the CCI object. Else, it MUST send a PCErr
Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid message with Error-Type = TBD5 ("PCECC failure") and Error Value =
CCI"). If the value of the Label in the CCI object is valid, but the TBD9 ("Invalid CCI"). If the value of the Label in the CCI object is
PCC is unable to allocate it, it MUST send a PCErr message with valid, but the PCC is unable to allocate it, it MUST send a PCErr
Error-Type = TBD5 ("PCECC failure") and Error Value = TBD10 ("Unable message with Error-Type = TBD5 ("PCECC failure") and Error Value =
to allocate the specified CCI"). TBD10 ("Unable to allocate the specified CCI").
If the PCC wishes to withdraw or modify the previously assigned If the PCC wishes to withdraw or modify the previously assigned
label, it MUST send a PCRpt message without any Label or with the label, it MUST send a PCRpt message without any Label or with the
Label containing the new value respectively in the CCI object. The Label containing the new value respectively in the CCI object. The
PCE would further trigger the removal of the central controller PCE would further trigger the removal of the central controller
instruction as per this document. instruction as per this document.
5.5.9. Binding Label 5.5.9. Binding Label
As per [I-D.ietf-pce-binding-label-sid], when a stateful PCE is As per [I-D.ietf-pce-binding-label-sid], when a stateful PCE is
deployed for setting up TE paths, it may be desirable to report the deployed for setting up TE paths, it may be desirable to report the
binding label to the stateful PCE for the purpose of enforcing end- binding label to the stateful PCE for the purpose of enforcing end-
to-end TE. In the case of the PCECC, the binding label may be to-end TE. In the case of the PCECC, the binding label may be
allocated by the PCE itself as described in this section. This allocated by the PCE itself as described in this section. This
procedure is thus applicable for all path setup types including procedure is thus applicable for all path setup types including
PCECC. PCECC.
A P flag in the LSP object is introduced in A P flag in the LSP object is introduced in
[I-D.ietf-pce-sr-path-segment] to indicate the allocation needs to be [I-D.ietf-pce-sr-path-segment] to indicate the allocation needs to be
made by the PCE. This flag is used to indicate that the allocation made by the PCE. A PCC would set this bit to 1 (and carry the TE-
needs to be made by the PCE. A PCC would set this bit to 1 (and PATH-BINDING TLV [I-D.ietf-pce-binding-label-sid] in the LSP object)
carry the TE-PATH-BINDING TLV [I-D.ietf-pce-binding-label-sid] in the to request for allocation of the binding label by the PCE in the
LSP object) to request for allocation of the binding label by the PCE PCReq or PCRpt message. A PCE would also set this bit to 1 to
in the PCReq or PCRpt message. A PCE would also set this bit to 1 to
indicate that the binding label is allocated by PCE and encoded in indicate that the binding label is allocated by PCE and encoded in
the PCRep, PCUpd, or PCInitiate message (the TE-PATH-BINDING TLV is the PCRep, PCUpd, or PCInitiate message (the TE-PATH-BINDING TLV is
present in LSP object). Further, a PCE would set this bit to 0 to present in LSP object). Further, a PCE would set this bit to 0 to
indicate that the allocation is done by the PCC instead. indicate that the allocation is done by the PCC instead.
The ingress PCC could request the binding label to be allocated by The ingress PCC could request the binding label to be allocated by
the PCE via a PCRpt message as per [RFC8231]. The delegate flag the PCE via a PCRpt message as per [RFC8231]. The delegate flag
(D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST
be included with no Binding Value. The PCECC would allocate the be included with no Binding Value. The PCECC would allocate the
binding label and further respond to Ingress PCC with PCUpd message binding label and further respond to ingress PCC with PCUpd message
as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in an LSP as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in an LSP
object. The P flag in the LSP object would be set to 1 to indicate object. The P flag in the LSP object would be set to 1 to indicate
that the allocation is made by the PCE. that the allocation is made by the PCE.
The PCE could allocate the binding label on its own accord for a PCE- The PCE could allocate the binding label on its own accord for a PCE-
Initiated (or delegated LSP). The allocated binding label needs to Initiated (or delegated) LSP. The allocated binding label needs to
be informed to the PCC. The PCE would use the PCInitiate message be informed to the PCC. The PCE would use the PCInitiate message
[RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include
the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP
object would be set to 1 to indicate that the allocation is made by object would be set to 1 to indicate that the allocation is made by
the PCE. the PCE.
Before a PCE can allocate a binding label the PCECC capability MUST Before a PCE can allocate a binding label the PCECC capability MUST
be exchanged on the PCEP session. Note that the CCI object is not be exchanged on the PCEP session. Note that the CCI object is not
used for binding allocation; this is done to maintain consistency used for binding allocation; this is done to maintain consistency
with the rest of the binding label/SID procedures as per with the rest of the binding label/SID procedures as per
[I-D.ietf-pce-binding-label-sid]. [I-D.ietf-pce-binding-label-sid].
6. PCEP messages 6. PCEP Messages
As defined in [RFC5440], a PCEP message consists of a common header As defined in [RFC5440], a PCEP message consists of a common header
followed by a variable-length body made of a set of objects that can followed by a variable-length body made of a set of objects that can
be either mandatory or optional. An object is said to be mandatory be either mandatory or optional. An object is said to be mandatory
in a PCEP message when the object must be included for the message to in a PCEP message when the object must be included for the message to
be considered valid. For each PCEP message type, a set of rules is be considered valid. For each PCEP message type, a set of rules is
defined that specify the set of objects that the message can carry. defined that specify the set of objects that the message can carry.
An implementation MUST form the PCEP messages using the object An implementation MUST form the PCEP messages using the object
ordering specified in this document. ordering specified in this document.
LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. Backus-Naur Form (RBNF) encoding as specified in [RFC5511].
6.1. The PCInitiate message 6.1. The PCInitiate Message
The PCInitiate message [RFC8281] can be used to download or remove The PCInitiate message [RFC8281] can be used to download or remove
the labels, this document extends the message as shown below - the labels, this document extends the message as shown below -
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: Where:
<Common Header> is defined in [RFC5440] <Common Header> is defined in [RFC5440]
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>] [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= <PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>| (<PCE-initiated-lsp-instantiation>|
skipping to change at page 20, line 43 skipping to change at page 22, line 49
The SRP object is defined in [RFC8231] and if the SRP object is The SRP object is defined in [RFC8231] and if the SRP object is
missing, the receiving PCC MUST send a PCErr message with Error- missing, the receiving PCC MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=10 (SRP object type=6 (Mandatory Object missing) and Error-value=10 (SRP object
missing). The LSP object is defined in [RFC8231] and if the LSP missing). The LSP object is defined in [RFC8231] and if the LSP
object is missing, the receiving PCC MUST send a PCErr message with object is missing, the receiving PCC MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object
missing). The CCI object is defined in Section 7.3 and if the CCI missing). The CCI object is defined in Section 7.3 and if the CCI
object is missing, the receiving PCC MUST send a PCErr message with object is missing, the receiving PCC MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI
object missing). More than one CCI object MAY be included in the object missing). More than one CCI object MAY be included in the
PCInitiate message for the transit LSR. PCInitiate message for a transit LSR.
To cleanup, the SRP object must set the R (remove) bit and include To clean up entries, the R (remove) bit MUST be set in the SRP object
the LSP and the CCI object. to be encoded along with the LSP and the CCI object.
The CCI object received at the Ingress node MUST have the O bit (out- The CCI object received at the ingress node MUST have the O bit (out-
label) set. The CCI Object received at the egress MUST have the O label) set. The CCI Object received at the egress MUST have the O
bit unset. If this is not the case, PCC MUST send a PCErr message bit unset. If this is not the case, PCC MUST send a PCErr message
with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9
("Invalid CCI"). Other instances of the CCI object if present, MUST ("Invalid CCI"). Other instances of the CCI object if present, MUST
be ignored. be ignored.
At most two instances of CCI object would be included in the case of At most two instances of the CCI object can be included, in the case
transit LSR to encode both in-coming and out-going label forwarding of transit LSR to encode both in-coming and out-going label
instructions. Other instances MUST be ignored. If the transit LSR forwarding instructions. Other instances MUST be ignored for P2P
did not receive two CCI object with one of them having the O bit set LSP. If the transit LSR did not receive two CCI object with one of
and another with O bit unset, it MUST send a PCErr message with them having the O bit set and another with O bit unset, it MUST send
Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error
CCI"). Value = TBD9 ("Invalid CCI").
6.2. The PCRpt message Note that, on receipt of the PCInitiate message with CCI object, the
ingress, egress, or transit role of the PCC is identified via the
ingress and egress IP address encoded in the LSP-IDENTIFIERS TLV.
6.2. The PCRpt Message
The PCRpt message can be used to report the labels that were The PCRpt message can be used to report the labels that were
allocated by the PCE, to be used during the state synchronization allocated by the PCE, to be used during the state synchronization
phase. phase or as acknowledgemnt to PCInitiate message.
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= (<lsp-state-report>| <state-report> ::= (<lsp-state-report>|
<central-control-report>) <central-control-report>)
skipping to change at page 22, line 4 skipping to change at page 24, line 34
Where: Where:
<path> is as per [RFC8231] and the LSP and SRP object are <path> is as per [RFC8231] and the LSP and SRP object are
also defined in [RFC8231]. also defined in [RFC8231].
When PCRpt message is used to report the central controller When PCRpt message is used to report the central controller
instructions (labels), the LSP and CCI objects MUST be present. The instructions (labels), the LSP and CCI objects MUST be present. The
LSP object is defined in [RFC8231] and if the LSP object is missing, LSP object is defined in [RFC8231] and if the LSP object is missing,
the receiving PCE MUST send a PCErr message with Error-type=6 the receiving PCE MUST send a PCErr message with Error-type=6
(Mandatory Object missing) and Error-value=8 (LSP object missing). (Mandatory Object missing) and Error-value=8 (LSP object missing).
The CCI object is defined in Section 7.3 and if the CCI object is The CCI object is defined in Section 7.3 and if the CCI object is
missing, the receiving PCC MUST send a PCErr message with Error- missing, the receiving PCE MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object
missing). Two CCI objects can be included in the PCRpt message for missing). Two CCI objects can be included in the PCRpt message for a
the transit LSR. transit LSR.
7. PCEP Objects 7. PCEP Objects
The PCEP object defined in this document are compliant with the PCEP The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. object format defined in [RFC5440].
7.1. OPEN Object 7.1. OPEN Object
This document defines new optional TLVs for use in the OPEN Object. This document defines new optional TLVs for use in the OPEN Object.
7.1.1. PCECC Capability sub-TLV 7.1.1. PCECC Capability sub-TLV
The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN
Object for PCECC capability advertisement in PATH-SETUP-TYPE- Object for PCECC capability advertisement in PATH-SETUP-TYPE-
CAPABILITY TLV. Advertisement of the PCECC capability implies CAPABILITY TLV. Advertisement of the PCECC capability implies
support of LSPs that are set up through PCECC as per PCEP extensions support of LSPs that are set up through PCECC as per PCEP extensions
defined in this document. defined in this document.
Its format is shown in Figure 6. Its format is shown 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=TBD12 | Length=4 | | Type=TBD12 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: PCECC Capability sub-TLV Figure 7: PCECC Capability sub-TLV
The type of the TLV is TBD12 and it has a fixed length of 4 octets. The type of the TLV is TBD12 and it has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits). The value comprises a single field - Flags (32 bits). Currently, the
following flag bit is defined:
No flags are defined in this document. o L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates
that the PCEP speaker allows PCECC based central controller
instructions for label download. The bit MUST be set to 1 by both
a PCC and a PCE for the PCECC label download/report on a PCEP
session.
Unassigned bits MUST be set to 0 on transmission and MUST be ignored o Unassigned bits MUST be set to 0 on transmission and MUST be
on receipt. ignored on receipt.
7.2. PATH-SETUP-TYPE TLV 7.2. PATH-SETUP-TYPE TLV
The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document
defines a new PST value: defines a new PST value:
o PST = TBD1: Path is set up via PCECC mode. o PST = TBD1: Path is set up via PCECC mode.
On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE
TLV in SRP object indicates that this LSP was set up via a PCECC TLV in SRP object indicates that this LSP was set up via a PCECC-
based mechanism. based mechanism.
7.3. CCI Object 7.3. CCI Object
The Central Controller Instructions (CCI) Object is used by the PCE The Central Controller Instructions (CCI) Object is used by the PCE
to specify the forwarding instructions (Label information in the to specify the forwarding instructions (Label information in the
context of this document) to the PCC, and MAY be carried within context of this document) to the PCC, and MAY be carried within
PCInitiate or PCRpt message for label download. PCInitiate or PCRpt message for label download/report.
CCI Object-Class is TBD13. CCI Object-Class is TBD13.
CCI Object-Type is 1 for the MPLS Label. CCI Object-Type is 1 for the MPLS Label.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID | | CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|O| | Reserved1 | Flags |C|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Reserved | | Label | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV // // Optional TLV //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: CCI Object Figure 8: CCI Object
The fields in the CCI object are as follows: The fields in the CCI object are as follows:
CC-ID: A PCEP-specific identifier for the CCI information. A PCE CC-ID: A PCEP-specific identifier for the CCI information. A PCE
creates a CC-ID for each instruction, the value is unique within creates a CC-ID for each instruction, the value is unique within
the scope of the PCE and is constant for the lifetime of a PCEP the scope of the PCE and is constant for the lifetime of a PCEP
session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be
used. used.
Flags: is used to carry any additional information pertaining to the Reserved1 (16 bit): Set to zero while sending, ignored on receive.
CCI. Currently, the following flag bits are defined:
* O bit(Out-label) : If the bit is set, it specifies the label is Flags (16 bit): A field used to carry any additional information
the OUT label and it is mandatory to encode the next-hop pertaining to the CCI. Currently, the following flag bits are
information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or defined:
* O bit(Out-label) : If the bit is set to 1, it specifies the
label is the OUT label and it is mandatory to encode the next-
hop information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or
UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit
is not set, it specifies the label is the IN label and it is is not set, it specifies the label is the IN label and it is
optional to encode the local interface information (via optional to encode the local interface information (via
IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID-
ADDRESS TLV in the CCI object). ADDRESS TLV in the CCI object).
* C-Bit (PCC Allocation): If the bit is set to 1, it indicates * C Bit (PCC Allocation): If the bit is set to 1, it indicates
that the allocation needs to be done by the PCC for this that the allocation needs to be done by the PCC for this
central controller instruction. A PCE sets this bit to request central controller instruction. A PCE sets this bit to request
the PCC to make an allocation from its label space. A PCC the PCC to make an allocation from its label space. A PCC
would set this bit to indicate that it has allocated the CC-ID would set this bit to indicate that it has allocated the CC-ID
and report it to the PCE. and report it to the PCE.
* All unassigned bits MUST be set to zero at transmission and * All unassigned bits MUST be set to zero at transmission and
ignored at receipt. ignored at receipt.
Label (20-bit): The Label information. Label (20-bit): The Label information.
Reserved (12 bit): Set to zero while sending, ignored on receive. Reserved2 (12 bit): Set to zero while sending, ignored on receive.
7.3.1. Address TLVs 7.3.1. Address TLVs
This document defines the following TLVs for the CCI object to This document defines the following TLVs for the CCI object to
associate the next-hop information in the case of an outgoing label associate the next-hop information in the case of an outgoing label
and local interface information in the case of an incoming label. and local interface information in the case of an incoming label.
IPV4-ADDRESS TLV: IPV4-ADDRESS TLV:
0 1 2 3 0 1 2 3
skipping to change at page 25, line 39 skipping to change at page 28, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) // // Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID | | Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) // // Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID | | Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Address TLVs Figure 9: Address TLVs
The address TLVs are as follows: The address TLVs are as follows:
IPV4-ADDRESS TLV: an IPv4 address. IPV4-ADDRESS TLV: an IPv4 address.
IPV6-ADDRESS TLV: an IPv6 address. IPV6-ADDRESS TLV: an IPv6 address.
UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple.
LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address,
skipping to change at page 28, line 11 skipping to change at page 31, line 4
PCEP extensions defined in this document do not put new requirements PCEP extensions defined in this document do not put new requirements
on other protocols. on other protocols.
10.6. Impact On Network Operations 10.6. Impact On Network Operations
PCEP extensions defined in this document do not put new requirements PCEP extensions defined in this document do not put new requirements
on network operations. on network operations.
11. IANA Considerations 11. IANA Considerations
11.1. PCEP TLV Type Indicators 11.1. PCEP TLV Type Indicators
IANA is requested to allocate the following TLV Type Indicator values IANA is requested to allocate the following TLV Type Indicator values
within the "PCEP TLV Type Indicators" sub- registry of the PCEP within the "PCEP TLV Type Indicators" sub-registry of the PCEP
Numbers registry: Numbers registry:
Value Meaning Reference Value Meaning Reference
TBD14 IPV4-ADDRESS TLV This document TBD14 IPV4-ADDRESS TLV This document
TBD15 IPV6-ADDRESS TLV This document TBD15 IPV6-ADDRESS TLV This document
TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document
TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document
11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
[RFC8408] requested the creation of "PATH-SETUP- TYPE-CAPABILITY Sub- [RFC8408] requested the creation of "PATH-SETUP-TYPE-CAPABILITY Sub-
TLV Type Indicators" sub-registry. Further IANA is requested to TLV Type Indicators" sub-registry. Further IANA is requested to
allocate the following code-point: allocate the following code-point:
Value Meaning Reference Value Meaning Reference
TBD12 PCECC-CAPABILITY This document TBD12 PCECC-CAPABILITY This document
11.3. PCECC-CAPABILITY sub-TLV's Flag field 11.3. PCECC-CAPABILITY sub-TLV's Flag field
This document defines the PCECC-CAPABILITY sub-TLV and requests that This document defines the PCECC-CAPABILITY sub-TLV and requests that
IANA to create a new sub-registry to manage the value of the PCECC- IANA to create a new sub-registry to manage the value of the PCECC-
CAPABILITY sub-TLV's 32-bits Flag field. New values are to be CAPABILITY sub-TLV's 32-bits Flag field. New values are to be
assigned by Standards Action [RFC8126]. Each bit should be tracked assigned by Standards Action [RFC8126]. Each bit should be tracked
with the following qualities: with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
Currently, there are no allocations in this registry. Currently, there is one allocation in this registry.
Bit Name Reference Bit Name Reference
0-31 Unassigned This document 31 Label This document
0-30 Unassigned This document
11.4. Path Setup Type Registry 11.4. Path Setup Type Registry
[RFC8408] created a sub-registry within the "Path Computation Element [RFC8408] created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to allocate a new code point within this registry, IANA is requested to allocate a new code point within this registry,
as follows: as follows:
Value Description Reference Value Description Reference
TBD1 Traffic engineering path is This document TBD1 Traffic engineering path is This document
skipping to change at page 30, line 24 skipping to change at page 33, line 19
19 Invalid operation. 19 Invalid operation.
Error-value = TBD3 : Attempted PCECC Error-value = TBD3 : Attempted PCECC
operations when operations when
PCECC capability PCECC capability
was not advertised was not advertised
Error-value = TBD4 : Stateful PCE Error-value = TBD4 : Stateful PCE
capability was not capability was not
advertised advertised
Error-value = TBD8 : Unknown Label Error-value = TBD8 : Unknown Label
TBD5 PCECC failure. TBD5 PCECC failure.
Error-value = TBD6 : Label out of range. Error-value = TBD6 : Label out of range.
Error-value = TBD7 : Instruction failed. Error-value = TBD7 : Instruction failed.
Error-value = TBD9 : Invalid CCI. Error-value = TBD9 : Invalid CCI.
Error-value = TBD10 : Unable to allocate Error-value = TBD10 : Unable to allocate
the specified CCI. the specified CCI.
12. Acknowledgments 12. Acknowledgments
We would like to thank Robert Tao, Changjing Yan, Tieying Huang, We would like to thank Robert Tao, Changjing Yan, Tieying Huang,
Avantika, and Aijun Wang for their useful comments and suggestions. Avantika, and Aijun Wang for their useful comments and suggestions.
Thanks to Julien Meuric for shepherding this I-D and providing
valuable comments.
13. References 13. References
13.1. Normative References 13.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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>. 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[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,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/info/rfc8233>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[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>.
skipping to change at page 32, line 22 skipping to change at page 35, line 5
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE", Margaria, "Requirements for GMPLS Applications of PCE",
RFC 7025, DOI 10.17487/RFC7025, September 2013, RFC 7025, DOI 10.17487/RFC7025, September 2013,
<https://www.rfc-editor.org/info/rfc7025>. <https://www.rfc-editor.org/info/rfc7025>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>. <https://www.rfc-editor.org/info/rfc7491>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control", Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017, RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
[RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and
M. Negi, "Ability for a Stateful Path Computation Element
(PCE) to Request and Obtain Control of a Label Switched
Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020,
<https://www.rfc-editor.org/info/rfc8741>.
[I-D.ietf-teas-pcecc-use-cases] [I-D.ietf-teas-pcecc-use-cases]
Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang,
L., Zhou, C., Communications, T., Rachitskiy, A., and A. L., Zhou, C., Communications, T., Rachitskiy, A., and A.
Gulida, "The Use Cases for Path Computation Element (PCE) Gulida, "The Use Cases for Path Computation Element (PCE)
as a Central Controller (PCECC).", draft-ietf-teas-pcecc- as a Central Controller (PCECC).", draft-ietf-teas-pcecc-
use-cases-05 (work in progress), March 2020. use-cases-06 (work in progress), September 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-14 (work in progress), July 2020.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] [I-D.zhao-pce-pcep-extension-pce-controller-sr]
Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a Procedures and Protocol Extensions for Using PCE as a
skipping to change at page 33, line 27 skipping to change at page 36, line 34
[I-D.dhody-pce-pcep-extension-pce-controller-srv6] [I-D.dhody-pce-pcep-extension-pce-controller-srv6]
Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) for SRv6", draft-dhody-pce-pcep- Controller (PCECC) for SRv6", draft-dhody-pce-pcep-
extension-pce-controller-srv6-04 (work in progress), July extension-pce-controller-srv6-04 (work in progress), July
2020. 2020.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE
Controlled ID Space", draft-li-pce-controlled-id-space-06 Controlled ID Space", draft-li-pce-controlled-id-space-07
(work in progress), July 2020. (work in progress), October 2020.
[I-D.ietf-pce-binding-label-sid] [I-D.ietf-pce-binding-label-sid]
Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J.,
Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
in PCE-based Networks.", draft-ietf-pce-binding-label- in PCE-based Networks.", draft-ietf-pce-binding-label-
sid-03 (work in progress), June 2020. sid-03 (work in progress), June 2020.
[I-D.ietf-pce-sr-path-segment] [I-D.ietf-pce-sr-path-segment]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
skipping to change at page 35, line 27 skipping to change at page 38, line 27
Shuping Peng Shuping Peng
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
EMail: pengshuping@huawei.com EMail: pengshuping@huawei.com
Mahendra Singh Negi Mahendra Singh Negi
RtBrick India RtBrick Inc
N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 N-17L, 18th Cross Rd, HSR Layout
Bangalore, Karnataka 560102 Bangalore, Karnataka 560102
India India
EMail: mahend.ietf@gmail.com EMail: mahend.ietf@gmail.com
Quintin Zhao Quintin Zhao
Etheric Networks Etheric Networks
1009 S CLAREMONT ST 1009 S CLAREMONT ST
SAN MATEO, CA 94402 SAN MATEO, CA 94402
USA USA
 End of changes. 134 change blocks. 
381 lines changed or deleted 464 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/