rfc9504.original   rfc9504.txt 
PCE Working Group Y. Lee Internet Engineering Task Force (IETF) Y. Lee
Internet-Draft Samsung Request for Comments: 9504 Samsung
Intended status: Standards Track H. Zheng Category: Standards Track H. Zheng
Expires: 1 April 2024 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
V. Lopez V. Lopez
Nokia Nokia
Z. Ali Z. Ali
Cisco Cisco
29 September 2023 December 2023
Path Computation Element Communication Protocol (PCEP) Extensions for Path Computation Element Communication Protocol (PCEP) Extensions for
Stateful PCE Usage in GMPLS-controlled Networks Stateful PCE Usage in GMPLS-Controlled Networks
draft-ietf-pce-pcep-stateful-pce-gmpls-23
Abstract Abstract
The PCE communication Protocol (PCEP) has been extended to support The Path Computation Element Communication Protocol (PCEP) has been
stateful PCE functions where the Stateful PCE maintains information extended to support stateful PCE functions where the stateful PCE
about paths and resource usage within a network, but these extensions maintains information about paths and resource usage within a
do not cover all requirements for GMPLS networks. network; however, these extensions do not cover all requirements for
GMPLS networks.
This document provides the extensions required for PCEP so as to This document provides the extensions required for PCEP so as to
enable the usage of a stateful PCE capability in GMPLS-controlled enable the usage of a stateful PCE capability in GMPLS-controlled
networks. networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 1 April 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9504.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Conventions Used in this Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. General Context of Stateful PCE and PCEP for GMPLS . . . . . 4 3. General Context of Stateful PCE and PCEP for GMPLS
4. Main Requirements . . . . . . . . . . . . . . . . . . . . . . 5 4. Main Requirements
5. Overview of Stateful PCEP Extensions for GMPLS Networks . . . 6 5. Overview of Stateful PCEP Extensions for GMPLS Networks
5.1. Capability Advertisement for Stateful PCEP in GMPLS . . . 6 5.1. Capability Advertisement for Stateful PCEP in GMPLS
5.2. LSP Synchronization . . . . . . . . . . . . . . . . . . . 6 5.2. LSP Synchronization
5.3. LSP Delegation and Cleanup . . . . . . . . . . . . . . . 7 5.3. LSP Delegation and Cleanup
5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 5.4. LSP Operations
6. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 7 6. PCEP Object Extensions
6.1. Existing Extensions used for Stateful GMPLS . . . . . . . 7 6.1. Existing Extensions Used for Stateful GMPLS
6.2. New Extensions . . . . . . . . . . . . . . . . . . . . . 8 6.2. New Extensions
6.2.1. GMPLS-CAPABILITY TLV in OPEN Object . . . . . . . . . 8 6.2.1. GMPLS-CAPABILITY TLV in OPEN Object
6.2.2. New LSP Exclusion Sub-object in the XRO . . . . . . . 9 6.2.2. New LSP Exclusion Subobject in the XRO
6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP 6.2.3. New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object
Object . . . . . . . . . . . . . . . . . . . . . . . 11 7. Update to Error Handling
7. Update to Error Handling . . . . . . . . . . . . . . . . . . 11 7.1. Error Handling in PCEP Capabilities Advertisement
7.1. Error Handling in PCEP Capabilities Advertisement . . . . 11 7.2. Error Handling in LSP Reoptimization
7.2. Error Handling in LSP Re-optimization . . . . . . . . . . 12 7.3. Error Handling in Route Exclusion
7.3. Error Handling in Route Exclusion . . . . . . . . . . . . 12 7.4. Error Handling for the Generalized END-POINTS Object
7.4. Error Handling for generalized END-POINTS . . . . . . . . 13 8. IANA Considerations
8. Implementation . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. New Flags in the GMPLS-CAPABILITY TLV
8.1. Huawei Technologies . . . . . . . . . . . . . . . . . . . 14 8.2. New Subobject for the Exclude Route Object
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8.3. Flags Field for the LSP Exclusion Subobject
9.1. title=New Flags in GMPLS-CAPABILITY TLV . . . . . . . . . 14 8.4. New Flags in the LSP-EXTENDED-FLAGS TLV
9.2. New Sub-object for the Exclude Route Object . . . . . . . 14 8.5. New PCEP Error Codes
9.3. Flags Field for LSP exclusion Sub-object . . . . . . . . 15 9. Manageability Considerations
9.4. New Flags in the LSP-EXTENDED-FLAGS TLV . . . . . . . . . 15 9.1. Control of Function through Configuration and Policy
9.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . 16 9.2. Information and Data Models
10. Manageability Considerations . . . . . . . . . . . . . . . . 16 9.3. Liveness Detection and Monitoring
10.1. Control of Function through Configuration and Policy . . 17 9.4. Verifying Correct Operation
10.2. Information and Data Models . . . . . . . . . . . . . . 17 9.5. Requirements on Other Protocols and Functional Components
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 17 9.6. Impact on Network Operation
10.4. Verifying Correct Operation . . . . . . . . . . . . . . 18 10. Security Considerations
10.5. Requirements on Other Protocols and Functional 11. References
Components . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References
10.6. Impact on Network Operation . . . . . . . . . . . . . . 18 11.2. Informative References
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 Appendix A. PCEP Messages
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 A.1. The PCRpt Message
13. Nomative References . . . . . . . . . . . . . . . . . . . . . 18 A.2. The PCUpd Message
14. Informative References . . . . . . . . . . . . . . . . . . . 20 A.3. The PCInitiate Message
Appendix A. Contributors' Address . . . . . . . . . . . . . . . 22 Acknowledgements
Appendix B. PCEP Messages . . . . . . . . . . . . . . . . . . . 23 Contributors
B.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses
B.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25
B.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
[RFC4655] presents the architecture of a Path Computation Element [RFC4655] presents the architecture of a PCE-based model for
(PCE)-based model for computing Multiprotocol Label Switching (MPLS) computing Multiprotocol Label Switching (MPLS) and Generalized MPLS
and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To
(TE LSPs). To perform such a constrained computation, a PCE stores perform such a constrained computation, a PCE stores the network
the network topology (i.e., TE links and nodes) and resource topology (i.e., TE links and nodes) and resource information (i.e.,
information (i.e., TE attributes) in its TE Database (TED). A PCE TE attributes) in its TE Database (TED). A PCE that only maintains a
that only maintains TED is referred to as a stateless PCE. [RFC5440] TED is referred to as a "stateless PCE". [RFC5440] describes the
describes the Path Computation Element Communication Protocol (PCEP) Path Computation Element Communication Protocol (PCEP) for
for interaction between a Path Computation Client (PCC) and a PCE, or interaction between a Path Computation Client (PCC) and a PCE or
between two PCEs, enabling computation of TE LSPs. PCEP is further between two PCEs, enabling computation of TE LSPs. PCEP is further
extended to support GMPLS-controlled networks as per [RFC8779]. extended to support GMPLS-controlled networks as per [RFC8779].
Stateful PCEs are shown to be helpful in many application scenarios, Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in [RFC8051]. in both MPLS and GMPLS networks, as illustrated in [RFC8051].
Further discussion of concept of a stateful PCE can be found in Further discussion of the concept of a stateful PCE can be found in
[RFC7399]. In order for these applications to able to exploit the [RFC7399]. In order for these applications to be able to exploit the
capability of stateful PCEs, extensions to stateful PCEP for GMPLS capability of stateful PCEs, extensions to stateful PCEP for GMPLS
are required. are required.
[RFC8051] describes how a stateful PCE can be applicable to solve [RFC8051] describes how a stateful PCE can be applied to solve
various problems for MPLS-TE and GMPLS networks and the benefits it various problems for MPLS-TE and GMPLS networks and the benefits it
brings to such deployments. brings to such deployments.
[RFC8231] specifies a set of extensions to PCEP to enable stateful [RFC8231] specifies a set of extensions to PCEP to enable stateful
control of TE LSPs where they are configured on the PCC, and control control of TE LSPs where they are configured on the PCC and control
over them could be delegated to the PCE. Furthermore, [RFC8281] over them could be delegated to the PCE. Furthermore, [RFC8281]
describes the setup and teardown of PCE-initiated LSPs under the describes the setup and teardown of PCE-initiated LSPs under the
active stateful PCE model, without the need for local configuration active stateful PCE model, without the need for local configuration
on the PCC. However, both documents omit the specification for on the PCC. However, both documents omit the specification for
technology-specific objects/TLVs, and do not cover GMPLS-controlled technology-specific objects and TLVs, and they do not cover GMPLS-
networks (e.g., Wavelength Switched Optical Network (WSON), Optical controlled networks (e.g., Wavelength Switched Optical Network
Transport Network (OTN), Synchronous Optical Network (WSON), Optical Transport Network (OTN), Synchronous Optical Network
(SONET)/Synchronous Digital Hierarchy (SDH), etc. technologies). (SONET) / Synchronous Digital Hierarchy (SDH)).
This document focuses on the extensions that are necessary in order This document focuses on the extensions that are necessary in order
for the deployment of stateful PCEs and the requirements for PCE- for the deployment of stateful PCEs and the requirements for PCE-
initiated LSPs in GMPLS-controlled networks. Section 3 provides a initiated LSPs in GMPLS-controlled networks. Section 3 provides a
general context of the usage of Stateful PCE and PCEP for GMPLS. The general context of the usage of stateful PCEs and PCEP for GMPLS.
various requirements for stateful GMPLS, including PCE-initiation for The various requirements for stateful GMPLS, including PCE initiation
GMPLS LSPs, are provided in Section 4. An overview of the PCEP for GMPLS LSPs, are provided in Section 4. An overview of the PCEP
extensions is specified in Section 5, and a solution to address such extensions is specified in Section 5. A solution to address such
requirements with PCEP object extensions in Section 6. requirements with PCEP object extensions is specified in Section 6.
1.1. Conventions Used in this Document 1.1. Conventions Used in This Document
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
Terminology used in this document is the same as terminology used in Terminology used in this document is the same as terminology used in
[RFC5440], [RFC8231], [RFC8281], and [RFC8779]. [RFC5440], [RFC8231], [RFC8281], and [RFC8779].
3. General Context of Stateful PCE and PCEP for GMPLS 3. General Context of Stateful PCE and PCEP for GMPLS
This section is built on the basis of Stateful PCE specified in This section is built on the basis of stateful PCEs specified in
[RFC8231] and PCEP for GMPLS specified in [RFC8779]. [RFC8231] and PCEP for GMPLS specified in [RFC8779].
The operation for Stateful PCE on LSPs can be divided into two types, The operation of a stateful PCE on LSPs can be divided into two
active stateful PCE and passive stateful PCE as described in types: active stateful PCE and passive stateful PCE (as described in
[RFC8051]. [RFC8051]).
For active stateful PCE, a Path Computation Update Request (PCUpd) * For active stateful PCEs, a Path Computation Update Request
message is sent from PCE to PCC to update the LSP state for the LSPs (PCUpd) message is sent from the PCE to the PCC to update the LSP
delegated to the PCE. Any changes to the delegated LSPs generate a state for the LSPs delegated to the PCE. Any changes to the
Path Computation State Report (PCRpt) message from the PCC to PCE to delegated LSPs generate a Path Computation State Report (PCRpt)
convey the changes of the LSPs. Any modifications to the Objects/ message from the PCC to the PCE to convey the changes of the LSPs.
TLVs that are identified in this document to support GMPLS Any modifications to the objects and TLVs that are identified in
technology-specific attributes will be carried in the PCRpt and PCUpd this document to support GMPLS-specific attributes will be carried
messages. in the PCRpt and PCUpd messages.
For passive stateful PCEs, Path Computation Request (PCReq)/ Path * For passive stateful PCEs, Path Computation Request (PCReq) and
Computation Reply (PCRep) messages are used to request for path Path Computation Reply (PCRep) messages are used to request path
computation. GMPLS-technology specific Objects and TLVs are defined computation. GMPLS-specific objects and TLVs are defined in
in [RFC8779], this document builds on it and adds the stateful PCE [RFC8779], which this document builds on and adds the stateful PCE
aspects where applicable. Passive Stateful PCE makes use of PCRpt aspects where applicable. A passive stateful PCE makes use of
messages when reporting LSP State changes sent by PCCs to PCEs. Any PCRpt messages when reporting LSP state changes sent by PCCs to
modifications to the Objects/TLVs that are identified in this PCEs. Any modifications to the objects and TLVs that are
document to support GMPLS technology-specific attributes will be identified in this document to support GMPLS-specific attributes
carried in the PCRpt message. will be carried in the PCRpt message.
Furthermore, the LSP Initiation function of PCEP is defined in Furthermore, the LSP Initiation function of PCEP is defined in
[RFC8281] to allow the PCE to initiate LSP establishment after the [RFC8281] to allow the PCE to initiate LSP establishment after the
path is computed. An LSP Initiate Request (PCInitiate) message is path is computed. An LSP Initiate Request (PCInitiate) message is
used to trigger the end node to set up the LSP. Any modifications to used to trigger the end node to set up the LSP. Any modifications to
the Objects/TLVs that are identified in this document to support the objects and TLVs that are identified in this document to support
GMPLS technology-specific attributes will be carried in the GMPLS-specific attributes will be carried in the PCInitiate messages.
PCInitiate messages.
[RFC8779] defines GMPLS-technology specific Objects/TLVs in stateless [RFC8779] defines GMPLS-specific objects and TLVs in stateless PCEP;
PCEP, and this document makes use of these Objects/TLVs without this document makes use of these objects and TLVs without
modifications where applicable. Where these Objects/TLVs require modifications where applicable. Where these objects and TLVs require
modifications to incorporate stateful PCE, they are described in this modifications to incorporate stateful PCEs, they are described in
document. PCE-Initiated LSPs follow the principle specified in this document. PCE-initiated LSPs follow the principle specified in
[RFC8281], and the GMPLS-specific extensions are also included in [RFC8281], and the GMPLS-specific extensions are also included in
this document. this document.
4. Main Requirements 4. Main Requirements
This section notes the main functional requirements for PCEP This section notes the main functional requirements for PCEP
extensions to support stateful PCE for use in GMPLS-controlled extensions to support stateful PCEs for use in GMPLS-controlled
networks, based on the description in [RFC8051]. Many requirements networks, based on the description in [RFC8051]. Many requirements
are common across a variety of network types (e.g., MPLS-TE networks are common across a variety of network types (e.g., MPLS-TE networks
and GMPLS networks) and the protocol extensions to meet the and GMPLS networks) and the protocol extensions to meet the
requirements are already described in [RFC8231], such as LSP update, requirements are already described in [RFC8231] (such as LSP update,
delegation and state synchronization/report. Protection context delegation, and state synchronization/report). Protection context
information that describes the GMPLS requirement can also follow the information that describes the GMPLS requirement can also follow the
description in [RFC8745]. This document does not repeat the description in [RFC8745]. This document does not repeat the
description of those protocol extensions. This document presents description of those protocol extensions. This document presents
protocol extensions for a set of requirements which are specific to protocol extensions for a set of requirements that are specific to
the use of a stateful PCE in a GMPLS-controlled network. the use of a stateful PCE in a GMPLS-controlled network.
The requirements for GMPLS-specific stateful PCE are as follows: The requirements for GMPLS-specific stateful PCEs are as follows:
* Advertisement of the stateful PCE capability. This generic * Advertisement of the stateful PCE capability. This generic
requirement is covered in Section 5.4 of [RFC8231]. The GMPLS- requirement is covered in Section 5.4 of [RFC8231]. The GMPLS-
CAPABILITY TLV specified in section 2.1 of [RFC8779] and its CAPABILITY TLV specified in Section 2.1 of [RFC8779] and its
extension in this document needs to be advertised as well. extension in this document need to be advertised as well.
* All the PCEP messages need to be capable of indicating GMPLS- * All the PCEP messages need to be capable of indicating GMPLS-
specific switching capabilities. GMPLS LSP creation/modification/ specific switching capabilities. GMPLS LSP creation,
deletion requires knowledge of LSP switching capability (e.g., modification, and deletion require knowledge of LSP switching
Time-Division Multiplex Capable (TDM), Layer 2 Switch Capable capabilities (e.g., Time-Division Multiplex Capable (TDM), Layer 2
(L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.) and the Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.)
generalized payload (G-PID) to be used according to [RFC3471], and the Generalized Payload Identifier (G-PID) to be used
[RFC3473]. It also requires the specification of data flow according to [RFC3471] and [RFC3473]. It also requires that
specific traffic parameters (also known as Traffic Specification traffic parameters that are both data flow and technology specific
(Tspec)), which are technology specific. Such information would be defined. These traffic parameters are also known as "Traffic
need to be included in various PCEP messages. Specification" or "Tspec". Such information would need to be
included in various PCEP messages.
* In some technologies, path calculation is tightly coupled with * In some technologies, path calculation is tightly coupled with
label selection along the route. For example, path calculation in label selection along the route. For example, path calculation in
a Wavelength Division Multiplexing (WDM) network may include a Wavelength Division Multiplexing (WDM) network may include
lambda continuity and/or lambda feasibility constraints and hence lambda continuity and/or lambda feasibility constraints; hence, a
a path computed by the PCE is associated with a specific lambda path computed by the PCE is associated with a specific lambda
(label). Hence, in such networks, the label information needs to (label). Thus, in such networks, the label information needs to
be provided to a PCC in order for a PCE to initiate GMPLS LSPs be provided to a PCC in order for a PCE to initiate GMPLS LSPs
under the active stateful PCE model, i.e., explicit label control under the active stateful PCE model, i.e., Explicit Label Control
may be required. (ELC) may be required.
* Stateful PCEP messages also need to indicate the protection * Stateful PCEP messages also need to indicate the protection
context information for the LSP specified by GMPLS, as defined in context information for the LSP specified by GMPLS, as defined in
[RFC4872], [RFC4873]. [RFC4872] and [RFC4873].
5. Overview of Stateful PCEP Extensions for GMPLS Networks 5. Overview of Stateful PCEP Extensions for GMPLS Networks
5.1. Capability Advertisement for Stateful PCEP in GMPLS 5.1. Capability Advertisement for Stateful PCEP in GMPLS
Capability Advertisement has been specified in [RFC8231], and can be Capability advertisement is specified in [RFC8231]; it can be
achieved by using the "STATEFUL-PCE-CAPABILITY TLV" in the Open achieved by using the STATEFUL-PCE-CAPABILITY TLV in the Open
message. Another GMPLS-CAPABILITY TLV has been defined in [RFC8779]. message. Another GMPLS-CAPABILITY TLV is defined in [RFC8779]. A
A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV is subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV has
created by the IANA as requested by [RFC8779]. The following bits been created by IANA as requested by [RFC8779]. The following bits
are introduced by this document in the GMPLS-CAPABILITY TLV as flags are introduced by this document in the GMPLS-CAPABILITY TLV as flags
to indicate the capability for LSP report, update and initiation in to indicate the capability for LSP report, update, and initiation in
GMPLS networks: LSP-REPORT-CAPABILITY(TBDa), LSP-UPDATE-CAPABILITY GMPLS networks: LSP-REPORT-CAPABILITY (31), LSP-UPDATE-CAPABILITY
(TBD1), and LSP-INSTANTIATION-CAPABILITY (TBD2). (30), and LSP-INSTANTIATION-CAPABILITY (29).
5.2. LSP Synchronization 5.2. LSP Synchronization
After the session between the PCC and a stateful PCE is initialized, After the session between the PCC and a stateful PCE is initialized,
the PCE must learn the state of a PCC's LSPs (including its the PCE must learn the state of a PCC's LSPs (including its
attributes) before it can perform path computations or update LSP attributes) before it can perform path computations or update LSP
attributes in a PCC. This process is known as LSP state attributes in a PCC. This process is known as "LSP state
synchronization. The LSP attributes including bandwidth, associated synchronization". The LSP attributes, including bandwidth,
route, and protection information etc., are stored by the PCE in the associated route, and protection information etc., are stored by the
LSP database (LSP-DB). Note that, as described in [RFC8231], the LSP PCE in the LSP database (LSP-DB). Note that, as described in
state synchronization covers both the bulk reporting of LSPs at [RFC8231], the LSP state synchronization covers both the bulk
initialization as well the reporting of new or modified LSPs during reporting of LSPs at initialization as well as the reporting of new
normal operation. Incremental LSP-DB synchronization may be desired or modified LSPs during normal operation. Incremental LSP-DB
in a GMPLS-controlled network and it is specified in [RFC8232]. synchronization may be desired in a GMPLS-controlled network; it is
specified in [RFC8232].
The format of the PCRpt message is specified in [RFC8231] and The format of the PCRpt message is specified in [RFC8231] and
extended in [RFC8623] to include the END-POINTS object. The END- extended in [RFC8623] to include the END-POINTS object. The END-
POINTS object is extended for GMPLS in [RFC8779]. The END-POINTS POINTS object is extended for GMPLS in [RFC8779]. The END-POINTS
object can be carried in the PCRpt message as specified in [RFC8623]. object can be carried in the PCRpt message as specified in [RFC8623].
The END-POINTS object type for GMPLS is included in the PCRpt message The END-POINTS object type for GMPLS is included in the PCRpt message
as per the same. as per the same.
The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and The following objects are extended for GMPLS in [RFC8779] and are
Exclude Route Object (XRO) objects are extended for GMPLS in also used in the PCRpt in the same manner: BANDWIDTH, LSP Attributes
[RFC8779] and are also used in the PCRpt in the same manner. These (LSPA), Include Route Object (IRO), and Exclude Route Object (XRO).
objects are carried in the PCRpt message as specified in [RFC8231] These objects are carried in the PCRpt message as specified in
(as the attribute-list defined in Section 6.5 of [RFC5440] and [RFC8231] (as the attribute-list defined in Section 6.5 of [RFC5440]
extended by many other documents that define PCEP extensions for and extended by many other documents that define PCEP extensions for
specific scenarios). specific scenarios).
The SWITCH-LAYER object is defined in [RFC8282]. This object is The SWITCH-LAYER object is defined in [RFC8282]. This object is
carried in PCRpt message as specified in section 3.2 of [RFC8282]. carried in the PCRpt message as specified in Section 3.2 of
[RFC8282].
5.3. LSP Delegation and Cleanup 5.3. LSP Delegation and Cleanup
LSP delegation and cleanup procedure specified in [RFC8231] are The LSP delegation and cleanup procedure specified in [RFC8281] are
equally applicable to GMPLS LSPs and this document does not modify equally applicable to GMPLS LSPs and this document does not modify
the associated usage. the associated usage.
5.4. LSP Operations 5.4. LSP Operations
Both passive and active stateful PCE mechanisms in [RFC8231] are Both passive and active stateful PCE mechanisms in [RFC8231] are
applicable in GMPLS-controlled networks. Remote LSP Initiation in applicable in GMPLS-controlled networks. Remote LSP Initiation in
[RFC8281] is also applicable in GMPLS-controlled networks. [RFC8281] is also applicable in GMPLS-controlled networks.
6. PCEP Object Extensions 6. PCEP Object Extensions
6.1. Existing Extensions used for Stateful GMPLS 6.1. Existing Extensions Used for Stateful GMPLS
Existing extensions defined in [RFC8779] can be used in Stateful PCEP Existing extensions defined in [RFC8779] can be used in stateful PCEP
with no or slight changes for GMPLS network control, including the with no or slight changes for GMPLS network control, including the
following: following:
* END-POINTS: Generalized END-POINTS was specified in [RFC8779] to END-POINTS: The END-POINTS object was specified in [RFC8779] to
include GMPLS capabilities. All Stateful PCEP messages MUST include GMPLS capabilities. All stateful PCEP messages MUST
include the END-POINTS with Generalized Endpoint object type, include the END-POINTS object with Generalized Endpoint object
containing the LABEL-REQUEST TLV. Further note that: type, containing the LABEL-REQUEST TLV. Further note that:
- As per [RFC8779] for stateless GMPLS path computation, the * As per [RFC8779], for stateless GMPLS path computation, the
Generalized END-POINTS object may contain a LABEL-REQUEST and/ Generalized END-POINTS object may contain a LABEL-REQUEST and/
or LABEL-SET TLV. In this document, only the LABEL-REQUEST TLV or LABEL-SET TLV. In this document, only the LABEL-REQUEST TLV
is used to specify the switching type, encoding type and G-PID is used to specify the switching type, encoding type, and G-PID
of the LSP. of the LSP.
- If unnumbered endpoint addresses are used for the LSP, the * If unnumbered endpoint addresses are used for the LSP, the
UNNUMBERED-ENDPOINT TLV [RFC8779] MUST be used to specify the UNNUMBERED-ENDPOINT TLV [RFC8779] MUST be used to specify the
unnumbered endpoint addresses. unnumbered endpoint addresses.
- The Generalized END-POINTS MAY contain other TLVs defined in * The Generalized END-POINTS object MAY contain other TLVs
[RFC8779]. defined in [RFC8779].
* RP: RP object extension, together with the Routing Granularity RP: The Request Parameter (RP) object extension (together with the
(RG) flag defined in [RFC8779], are applicable in the Stateful Routing Granularity (RG) flag defined in [RFC8779]) is applicable
PCEP for GMPLS networks. in stateful PCEP for GMPLS networks.
* BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to BANDWIDTH: Generalized BANDWIDTH is specified in [RFC8779] to
represent GMPLS features, including asymmetric bandwidth and G-PID represent GMPLS features, including asymmetric bandwidth and G-PID
information. information.
* LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable in LSPA: LSPA Extensions in Section 2.8 of [RFC8779] are applicable in
Stateful PCEP for GMPLS networks. stateful PCEP for GMPLS networks.
* IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in IRO: IRO Extensions in Section 2.6 of [RFC8779] are applicable in
Stateful PCEP for GMPLS networks. stateful PCEP for GMPLS networks.
* XRO: XRO Extensions in Section 2.7 of [RFC8779] is applicable in XRO: XRO Extensions in Section 2.7 of [RFC8779] are applicable in
Stateful PCEP for GMPLS networks. A new flag is defined in stateful PCEP for GMPLS networks. A new flag is defined in
Section 6.2.3 of this document. Section 6.2.3 of this document.
* ERO: The Explicit Route Object (ERO) was not extended in ERO: The Explicit Route Object (ERO) is not extended in [RFC8779],
[RFC8779], nor is it in this document. nor is it in this document.
* SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of SWITCH-LAYER: The SWITCH-LAYER definition in Section 3.2 of
[RFC8282] is applicable in Stateful PCEP messages for GMPLS [RFC8282] is applicable in stateful PCEP messages for GMPLS
networks. networks.
6.2. New Extensions 6.2. New Extensions
6.2.1. GMPLS-CAPABILITY TLV in OPEN Object 6.2.1. GMPLS-CAPABILITY TLV in OPEN Object
In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from the In [RFC8779], IANA allocates value 45 (GMPLS-CAPABILITY) from the
"PCEP TLV Type Indicators" sub-registry. The specifcation add three "PCEP TLV Type Indicators" subregistry. This specification adds
flags to the flag field of this TLV to indicate the Report, Update, three flags to the Flag field of this TLV to indicate the Report,
and Initiation capabilities. Update, and Initiation capabilities.
R (LSP-REPORT-CAPABILITY(TBDa) -- 1 bit): if set to 1 by a PCC, the R R (LSP-REPORT-CAPABILITY (31) -- 1 bit):
flag indicates that the PCC is capable of reporting the current state If set to 1 by a PCC, the R flag indicates that the PCC is capable
of a GMPLS LSP, whenever there's a change to the parameters or of reporting the current state of a GMPLS LSP whenever there's a
operational status of the GMPLS LSP; if set to 1 by a PCE, the R Flag change to the parameters or operational status of the GMPLS LSP.
indicates that the PCE is interested in receiving GMPLS LSP State If set to 1 by a PCE, the R flag indicates that the PCE is
Reports whenever there is a parameter or operational status change to interested in receiving GMPLS LSP State Reports whenever there is
the LSP. The LSP-REPORT-CAPABILITY flag must be advertised by both a a parameter or operational status change to the LSP. The LSP-
PCC and a PCE for PCRpt messages to be allowed on a PCEP session for REPORT-CAPABILITY flag must be advertised by both a PCC and a PCE
GMPLS LSP. for PCRpt messages to be allowed on a PCEP session for GMPLS LSP.
U (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the U U (LSP-UPDATE-CAPABILITY (30) -- 1 bit):
flag indicates that the PCC allows modification of GMPLS LSP If set to 1 by a PCC, the U flag indicates that the PCC allows
parameters; if set to 1 by a PCE, the U flag indicates that the PCE modification of GMPLS LSP parameters. If set to 1 by a PCE, the U
is capable of updating GMPLS LSP parameters. The LSP-UPDATE- flag indicates that the PCE is capable of updating GMPLS LSP
CAPABILITY flag must be advertised by both a PCC and a PCE for PCUpd parameters. The LSP-UPDATE-CAPABILITY flag must be advertised by
messages to be allowed on a PCEP session for GMPLS LSP. both a PCC and a PCE for PCUpd messages to be allowed on a PCEP
session for GMPLS LSP.
I (LSP-INSTANTIATION-CAPABILITY(TBD2) -- 1 bit): If set to 1 by a I (LSP-INSTANTIATION-CAPABILITY (29) -- 1 bit):
PCC, the I flag indicates that the PCC allows instantiation of a If set to 1 by a PCC, the I flag indicates that the PCC allows
GMPLS LSP by a PCE. If set to 1 by a PCE, the I flag indicates that instantiation of a GMPLS LSP by a PCE. If set to 1 by a PCE, the
the PCE supports instantiating GMPLS LSPs. The LSP-INSTANTIATION- I flag indicates that the PCE supports instantiating GMPLS LSPs.
CAPABILITY flag must be set by both the PCC and PCE in order to The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC
enable PCE-initiated LSP instantiation. and PCE in order to enable PCE-initiated LSP instantiation.
6.2.2. New LSP Exclusion Sub-object in the XRO 6.2.2. New LSP Exclusion Subobject in the XRO
[RFC5521] defines a mechanism for a PCC to request or demand that [RFC5521] defines a mechanism for a PCC to request or demand that
specific nodes, links, or other network resources are excluded from specific nodes, links, or other network resources be excluded from
paths computed by a PCE. A PCC may wish to request the computation paths computed by a PCE. A PCC may wish to request the computation
of a path that avoids all links and nodes traversed by some other of a path that avoids all links and nodes traversed by some other
LSP. LSP.
To this end this document defines a new sub-object for use with route To this end, this document defines a new subobject for use with route
exclusion defined in [RFC5521]. The LSP exclusion sub-object is as exclusion defined in [RFC5521]. The LSP Exclusion subobject is as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Type (TBD3) | Length | Reserved | Flags | |X|Type (11) | Length | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: New LSP Exclusion Sub-object Format
X: Same as the X-bit defined in the XRO sub-objects in Section 2.1.1
of [RFC5521] where it says: "The X-bit indicates whether the
exclusion is mandatory or desired. 0 indicates that the resource
specified MUST be excluded from the path computed by the PCE. 1
indicates that the resource specified SHOULD be excluded from the
path computed by the PCE, but MAY be included subject to PCE policy
and the absence of a viable path that meets the other constraints and
excludes the resource.".
Type: Sub-object Type for an LSP exclusion sub-object. Value of Figure 1: New LSP Exclusion Subobject Format
TBD3. To be assigned by IANA.
Length: The Length contains the total length of the sub-object in X: This field is the same as the X-bit defined in the XRO subobjects
bytes, including the Type and Length fields. in Section 2.1.1 of [RFC5521] where it says:
Reserved: MUST be set to zero on transmission and ignored on receipt. The X-bit indicates whether the exclusion is mandatory or
desired. 0 indicates that the resource specified MUST be
excluded from the path computed by the PCE. 1 indicates that
the resource specified SHOULD be excluded from the path
computed by the PCE, but MAY be included subject to PCE policy
and the absence of a viable path that meets the other
constraints and excludes the resource.
Flags: This field may be used to further specify the exclusion Type: The subobject type for an LSP Exclusion subobject. Value of
constraint with regard to the LSP. Currently, no flags are defined. 11.
Symbolic Path Name: This is the identifier given to an LSP. Its Length: The Length contains the total length of the subobject in
syntax and semantics are identical to those of the Symbolic Path Name bytes, including the Type and Length fields.
field defined in Section 7.3.2 of [RFC8231] where it says: "symbolic
name for the LSP, unique in the PCC. It SHOULD be a string of
printable ASCII characters, without a NULL terminator." The Symbolic
Path Name in the LSP Exclusion Sub-object MUST only vary from being a
string of printable ASCII characters without a NULL terminator when
it is matching the value contained in another subobject. It is worth
noting that given that the Symbolic Path Name is unique in the
context of the headnode, only LSPs that share the same headnode/PCC
could be excluded.
This sub-object MAY be present multiple times in the exclude route Reserved: Reserved MUST be set to zero on transmission and ignored
object (XRO) to exclude resources from multiple LSPs. When a on receipt.
stateful PCE receives a PCReq message carrying this sub-object, it
MUST search for the identified LSP in its LSP-DB and then exclude
from the new path computation all resources used by the identified
LSP.
Note that this XRO Sub-object could also be used by non-GMPLS LSPs. Flags: This field may be used to further specify the exclusion
The description by usage of non-GMPLS LSPs is not in the scope of constraint with regard to the LSP. Currently, no flags are
this document. defined.
6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object Symbolic Path Name: This is the identifier given to an LSP. Its
syntax and semantics are identical to those of the Symbolic Path
Name field defined in Section 7.3.2 of [RFC8231] where it says:
"symbolic name for the LSP, unique in the PCC. It SHOULD be a
string of printable ASCII characters, without a NULL terminator."
The symbolic path name in the LSP Exclusion subobject MUST only
vary from being a string of printable ASCII characters without a
NULL terminator when it is matching the value contained in another
subobject. It is worth noting that given that the symbolic path
name is unique in the context of the headnode, only LSPs that
share the same headnode or PCC could be excluded.
The LSP Object is defined in Section 7.3 of [RFC8231], and the new This subobject MAY be present multiple times in the XRO to exclude
extended flags TLV is defined in [RFC9357]. This TLV is used in resources from multiple LSPs. When a stateful PCE receives a
PCUpd, PCRpt and PCInitiate messages for GMPLS, with the following PCReq message carrying this subobject, it MUST search for the
flags defined in this document. identified LSP in its LSP-DB and then exclude from the new path
computation all resources used by the identified LSP.
* G (GMPLS LSP(TBDb) -- 1 bit) : If set to 1, it indicates the LSP Note that this XRO subobject could also be used by non-GMPLS LSPs.
is a GMPLS LSP. The usage of the XRO subobject for any non-GMPLS LSPs is not in
the scope of this document.
* B (Bidirectional LSP(TBD4) -- 1 bit): If set to 0, it indicates a 6.2.3. New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object
request to create a uni-directional LSP. If set to 1, it
indicates a request to create a bidirectional co-routed LSP.
* RG (Routing Granularity(TBDc) -- 2 bits) : RG flag for GMPLS is The LSP object is defined in Section 7.3 of [RFC8231], and the new
also defined in the LSP-EXTENDED-FLAG TLV. The value are defined extended flags TLV is defined in [RFC9357]. This TLV is used in
as per [RFC8779]: PCUpd, PCRpt and PCInitiate messages for GMPLS, with the following
flags defined in this document:
00: reserved G (GMPLS LSP (0) -- 1 bit):
If set to 1, it indicates the LSP is a GMPLS LSP.
01: node B (Bidirectional LSP (1) -- 1 bit):
If set to 0, it indicates a request to create a unidirectional
LSP. If set to 1, it indicates a request to create a
bidirectional co-routed LSP.
10: link RG (Routing Granularity (2-3) -- 2 bits):
The RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG
TLV. The values are defined as per [RFC8779]:
11: label 00: reserved
01: node
10: link
11: label
7. Update to Error Handling 7. Update to Error Handling
A PCEP-ERROR object is used to report a PCEP error and is A PCEP-ERROR object is used to report a PCEP error and is
characterized by an Error-Type that specifies the type of error and characterized by an Error-Type that specifies the type of error and
an Error-value that provides additional information about the error. an Error-value that provides additional information about the error.
This section adds additional error handling procedures to those This section adds additional error handling procedures to those
specified in Section 3 of [RFC8779]. Please note that all error specified in Section 3 of [RFC8779]. Please note that all error
handling specified in Section 3 of [RFC8779] is applicable and MUST handling specified in Section 3 of [RFC8779] is applicable and MUST
be supported for a stateful PCE in GMPLS networks. be supported for a stateful PCE in GMPLS networks.
7.1. Error Handling in PCEP Capabilities Advertisement 7.1. Error Handling in PCEP Capabilities Advertisement
The PCEP extensions described in this document for stateful PCEs with The PCEP extensions described in this document for stateful PCEs with
GMPLS capability MUST NOT be used if the PCE has not advertised its GMPLS capabilities MUST NOT be used if the PCE has not advertised its
capabilities with GMPLS as per Section 6.2.1. capabilities with GMPLS as per Section 6.2.1.
If the PCC understands the U flag that indicates the stateful LSP- If the PCC understands the U flag that indicates the stateful LSP-
UPDATE-CAPABILITY, but did not advertise this capability, then upon UPDATE-CAPABILITY, but did not advertise this capability, then upon
receipt of a PCUpd message for GMPLS LSP from the PCE, it SHOULD receipt of a PCUpd message for GMPLS LSP from the PCE, it SHOULD
generate a PCErr with error-type 19 ("Invalid Operation"), error- generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value
value TBDx ("Attempted LSP Update Request for GMPLS if stateful PCE 25 ("Attempted LSP update request for GMPLS if stateful PCE
capability for GMPLS was not advertised"), and terminate the PCEP capability not advertised") and terminate the PCEP session. Such a
session. Such a PCC MAY decide to utilize the capability even though PCC MAY decide to utilize the capability even though it did not
it did not advertise support for it. advertise support for it.
If the PCE understands the R flag that indicates the stateful LSP- If the PCE understands the R flag that indicates the stateful LSP-
REPORT-CAPABILITY, but did not advertise this capability, then upon REPORT-CAPABILITY, but did not advertise this capability, then upon
receipt of a PCRpt message for GMPLS LSP from the PCC, it SHOULD receipt of a PCRpt message for GMPLS LSP from the PCC, it SHOULD
generate a PCErr with error-type 19 ("Invalid Operation"), error- generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value
value TBDy ("Attempted LSP Report Request for GMPLS if stateful PCE 26 ("Attempted LSP State Report for GMPLS if stateful PCE capability
capability for GMPLS was not advertised"), and terminate the PCEP not advertised") and terminate the PCEP session. Such a PCE MAY
session. Such a PCE MAY decide to utilize the capability even though decide to utilize the capability even though it did not advertise
it did not advertise support for it. support for it.
If the PCC understands the I flag that indicates LSP-INSTANTIATION- If the PCC understands the I flag that indicates LSP-INSTANTIATION-
CAPABILITY, but did not advertise this capability, then upon receipt CAPABILITY, but did not advertise this capability, then upon receipt
of a PCInitiate message for GMPLS LSP from the PCE, it SHOULD of a PCInitiate message for GMPLS LSP from the PCE, it SHOULD
generate a PCErr with error-type 19 ("Invalid Operation"), error- generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value
value TBDz ("Attempted LSP Instantiation Request for GMPLS if 27 ("Attempted LSP instantiation request for GMPLS if stateful PCE
stateful PCE instantiation capability for GMPLS was not advertised"), instantiation capability for not advertised") and terminate the PCEP
and terminate the PCEP session. Such a PCC MAY decide to utilize the session. Such a PCC MAY decide to utilize the capability even though
capability even though it did not advertise support for it. it did not advertise support for it.
7.2. Error Handling in LSP Re-optimization 7.2. Error Handling in LSP Reoptimization
A stateful PCE is expected to perform an LSP re-optimization when A stateful PCE is expected to perform an LSP reoptimization when
receiving a message with the R bit set in the RP object. If no LSP receiving a message with the R bit set in the RP object. If no LSP
state information is available to carry out re-optimization, the state information is available to carry out reoptimization, the
stateful PCE SHOULD report the error "LSP state information stateful PCE SHOULD report Error-Type 19 ("Invalid Operation") Error-
unavailable for the LSP re-optimization" (Error Type = 19, Error value 23 ("LSP state info unavailable for reoptimization"), although
value= TBD6), although such a PCE MAY consider the re-optimization to such a PCE MAY consider the reoptimization to have successfully
have successfully completed. Note that this error message could also completed. Note that this error message could also be used by non-
be used by non-GMPLS LSPs. GMPLS LSPs.
7.3. Error Handling in Route Exclusion 7.3. Error Handling in Route Exclusion
The LSP exclusion sub-object in XRO is defined in Section 6.2.2 of The LSP Exclusion subobject in XRO, as defined in Section 6.2.2 of
this document MAY be present multiple times. When a stateful PCE this document, MAY be present multiple times. When a stateful PCE
receives a PCEP message carrying this sub-object, it searches for the receives a PCEP message carrying this subobject, it searches for the
identified LSP in its LSP-DB and then excludes from the new path identified LSP in its LSP-DB. It then excludes from the new path
computation all the resources used by the identified LSP. If the computation all the resources used by the identified LSP. If the
stateful PCE cannot recognize the symbolic path name of the stateful PCE cannot recognize the symbolic path name of the
identified LSP, it SHOULD send an error message PCErr reporting identified LSP, it SHOULD send an error message PCErr reporting
Error-type = 19 ("Invalid Operation"), Error-value = TBD7 ("The LSP Error-Type 19 ("Invalid Operation") Error-value 24 ("LSP state info
state information for route exclusion purpose cannot be found"). for route exclusion not found"). Along with the unrecognized
Optionally, it MAY also provide with the unrecognized symbolic path symbolic path name, it MAY also provide information to the requesting
name information to the requesting PCC using the error reporting PCC using the error-reporting techniques described in [RFC5440]. An
techniques described in [RFC5440]. An implementation MAY choose to implementation MAY choose to ignore the requested exclusion when the
ignore the requested exclusion when the LSP cannot be found because LSP cannot be found because it could claim that it has avoided using
it could claim it that it has avoided using all resources associated all resources associated with an LSP that doesn't exist.
with an LSP that doesn't exist.
7.4. Error Handling for generalized END-POINTS 7.4. Error Handling for the Generalized END-POINTS Object
Note that the END-POINTS object in the Stateful PCEP messages was Note that the END-POINTS object in stateful PCEP messages was
introduced for P2MP [RFC8623]. Similarly, the END-POINTS object MUST introduced for Point-to-Multipoint (P2MP) [RFC8623]. Similarly, the
be carried for the GMPLS LSP. If the END-POINTS object is missing END-POINTS object MUST be carried for the GMPLS LSP. If the END-
and the GMPLS flag in LSP-EXTENDED-FLAG is set, the receiving PCE or POINTS object is missing and the GMPLS flag in LSP-EXTENDED-FLAG is
PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object set, the receiving PCE or PCC MUST send a PCErr message with Error-
missing") and Error-value=3 ("END-POINTS object missing") (defined in Type 6 ("Mandatory Object missing") and Error-value 3 ("END-POINTS
[RFC5440]). Similarly, if the END-POINTS object with the Generalized object missing") (defined in [RFC5440]). Similarly, if the END-
Endpoint object type is received but if the LSP-EXTENDED-FLAG TLV is POINTS object with the Generalized Endpoint object type is received
missing in the LSP object or if the G flag in the LSP-EXTENDED-FLAG but the LSP-EXTENDED-FLAG TLV is missing in the LSP object or the G
TLV is not set, the receiving PCE or PCC MUST send a PCErr message flag in the LSP-EXTENDED-FLAG TLV is not set, the receiving PCE or
with Error-type = 19 ("Invalid Operation"), Error-value = TBD9 ("Use PCC MUST send a PCErr message with Error-Type 19 ("Invalid
of Generalized Endpoint object type for non-GMPLS LSP"). Operation") Error-value 28 ("Use of the Generalized Endpoint object
type for non-GMPLS LSPs").
If the END-POINTS object with Generalized Endpoint Object Type is If the END-POINTS object with Generalized Endpoint object type is
missing the LABEL-REQUEST TLV, the receiving PCE or PCC MUST send a missing the LABEL-REQUEST TLV, the receiving PCE or PCC MUST send a
PCErr message with Error-type=6 ("Mandatory Object missing") and PCErr message with Error-Type 6 ("Mandatory Object missing") Error-
Error-value=TBD8 ("LABEL-REQUEST TLV missing"). value 20 ("LABEL-REQUEST TLV missing").
8. Implementation
[NOTE TO RFC EDITOR : This whole section and the reference to RFC
7942 is to be removed before publication as an RFC]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
8.1. Huawei Technologies
* Organization: Huawei Technologies, Co. LTD
* Implementation: Huawei NCE-T
* Description: PCRpt, PCUpd and PCInitiate messages for GMPLS
Network
* Maturity Level: Production 8. IANA Considerations
* Coverage: Full 8.1. New Flags in the GMPLS-CAPABILITY TLV
* Contact: zhenghaomian@huawei.com [RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA
created the "GMPLS-CAPABILITY TLV Flag Field" registry to manage the
values of the GMPLS-CAPABILITY TLV's Flag field. This document
registers new bits in this registry as follows:
9. IANA Considerations +=====+==================================+===========+
| Bit | Capability Description | Reference |
+=====+==================================+===========+
| 31 | LSP-REPORT-CAPABILITY (R) | RFC 9504 |
+-----+----------------------------------+-----------+
| 30 | LSP-UPDATE-CAPABILITY (U) | RFC 9504 |
+-----+----------------------------------+-----------+
| 29 | LSP-INSTANTIATION-CAPABILITY (I) | RFC 9504 |
+-----+----------------------------------+-----------+
9.1. title=New Flags in GMPLS-CAPABILITY TLV Table 1
[RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA 8.2. New Subobject for the Exclude Route Object
created a registry to manage the value of the GMPLS-CAPABILITY TLV's
Flag field. This document requests IANA to allocate new bits in the
GMPLS-CAPABILITY TLV Flag Field registry, as follows. IANA is
requested to make allocations starting from the least significant bit
(31).
Bit | Description | Reference IANA maintains the various XRO subobject types within the "XRO
-----+----------------------------------+------------ Subobjects" subregistry of the "Path Computation Element Protocol
TBDa | LSP-REPORT-CAPABILITY (R) | [This.I-D] (PCEP) Numbers" registry. IANA has allocated a codepoint for another
TBD1 | LSP-UPDATE-CAPABILITY (U) | [This.I-D] XRO subobject as follows:
TBD2 | LSP-INSTANTIATION-CAPABILITY (I) | [This.I-D]
9.2. New Sub-object for the Exclude Route Object +=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 11 | LSP | RFC 9504 |
+-------+-------------+-----------+
IANA maintains the various XRO Subobjects types within the "XRO Table 2
Subobjects" subregistry of the PCEP Numbers registry. IANA is
requested to allocate a codepoint for another XRO subobject as
follows:
Value | Description | Reference 8.3. Flags Field for the LSP Exclusion Subobject
--------+------------------------------+-------------
TBD3 | LSP | [This.I-D]
9.3. Flags Field for LSP exclusion Sub-object IANA has created a registry named "LSP Exclusion Subobject Flag
Field", within the "Path Computation Element Protocol (PCEP) Numbers"
group, to manage the Flag field of the LSP Exclusion subobject in the
XRO. No flag is currently defined for this Flag field in this
document.
IANA is requested to create a registry named "LSP Exclusion Sub- Codespace of the Flag field (LSP Exclusion Subobject)
Object Flag Field", within the "Path Computation Element Protocol
(PCEP) Numbers" group, to manage the Flag field of the LSP Exclusion
sub-object in the XRO. No Flag is currently defined for this flag
field in this document.
Codespace of the Flag field (LSP Exclusion sub-object) +=====+========================+===========+
| Bit | Capability Description | Reference |
+=====+========================+===========+
| 0-7 | Unassigned | RFC 9504 |
+-----+------------------------+-----------+
Bit | Description | Reference Table 3
------+-------------------+-------------
0-7 | Unassigned | [This.I-D]
New values are to be assigned by Standards Action [RFC8126]. Each New values are to be assigned by Standards Action [RFC8126]. Each
bit should be tracked with the following qualities: bit should be registered with the following entries:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Defining RFC * Reference to defining RFC
9.4. New Flags in the LSP-EXTENDED-FLAGS TLV 8.4. New Flags in the LSP-EXTENDED-FLAGS TLV
[I-D.ietf-pce-lsp-extended-flags] requested IANA to create a [RFC9357] requested IANA to create a subregistry, named the "LSP-
subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within the EXTENDED-FLAG TLV Flag Field", within the "Path Computation Element
"Path Computation Element Protocol (PCEP) Numbers" registry, to Protocol (PCEP) Numbers" registry, to manage the Flag field of the
manage the Flag field of the LSP-EXTENDED-FLAG TLV. LSP-EXTENDED-FLAG TLV.
IANA is requested to make assignments from this registry as follows: IANA has made assignments from this registry as follows:
Bit | Description | Reference +=====+=================================+===========+
------+----------------------------------+------------ | Bit | Capability Description | Reference |
TBDb | GMPLS LSP (G) | [This.I-D] +=====+=================================+===========+
TBD4 | Bi-directional co-routed LSP (B) | [This.I-D] | 0 | GMPLS LSP (G) | RFC 9504 |
TBDc* | Routing Granularity Flag (RG) | [This.I-D] +-----+---------------------------------+-----------+
| 1 | Bidirectional Co-routed LSP (B) | RFC 9504 |
+-----+---------------------------------+-----------+
| 2-3 | Routing Granularity (RG) | RFC 9504 |
+-----+---------------------------------+-----------+
* - 2 bits need to be allocated Table 4
9.5. New PCEP Error Codes 8.5. New PCEP Error Codes
IANA is requested to make the following allocation in the "PCEP-ERROR IANA has made the following allocations in the "PCEP-ERROR Object
Object Error Types and Values" registry. Error Types and Values" registry.
+===========+================+=========================+===========+ +============+===========+===========================+===========+
| Error-Type| Meaning | Error-value | Reference | | Error-Type | Meaning | Error-value | Reference |
+===========+================+=========================+===========+ +============+===========+===========================+===========+
| 6 | Mandatory |TBD8: LABEL-REQUEST TLV | This I-D | | 6 | Mandatory | 20: LABEL-REQUEST TLV | RFC 9504 |
| | Object missing |missing | | | | Object | missing | |
|-----------|----------------+-------------------------+-----------+ | | missing | | |
|19 | Invalid |TBD6: LSP state info | This I-D | +------------+-----------+---------------------------+-----------+
| | Operation |unavailable for the | | | 19 | Invalid | 23: LSP state info | RFC 9504 |
| | |Re-optimization | | | | Operation | unavailable for | |
| | +-------------------------+-----------+ | | | reoptimization | |
| | |TBD7: LSP state info for | This I-D | | | +---------------------------+-----------+
| | |route exclusion not found| | | | | 24: LSP state info for | RFC 9504 |
| | +-------------------------+-----------+ | | | route exclusion not found | |
| | |TBDx: Attempted LSP | This I-D | | | +---------------------------+-----------+
| | |Update Request for GMPLS | | | | | 25: Attempted LSP update | RFC 9504 |
| | |if stateful PCE | | | | | request for GMPLS if | |
| | |capability not advertised| | | | | stateful PCE capability | |
| | +-------------------------+-----------+ | | | not advertised | |
| | |TBDy: Attempted LSP State| This I-D | | | +---------------------------+-----------+
| | |Report for GMPLS if | | | | | 26: Attempted LSP State | RFC 9504 |
| | |stateful PCE capability | | | | | Report for GMPLS if | |
| | |not advertised | | | | | stateful PCE capability | |
| | +-------------------------+-----------+ | | | not advertised | |
| | |TBDz: Attempted LSP | This I-D | | | +---------------------------+-----------+
| | |Instantiation Request for| | | | | 27: Attempted LSP | RFC 9504 |
| | |GMPLS if stateful PCE | | | | | instantiation request for | |
| | |instantiation capability | | | | | GMPLS if stateful PCE | |
| | |not advertised | | | | | instantiation capability | |
| | +-------------------------+-----------+ | | | not advertised | |
| | |TBD9: use of Generalized | This I-D | | | +---------------------------+-----------+
| | |Endpoint object type for | | | | | 28: Use of the | RFC 9504 |
| | |non-GMPLS LSP | | | | | Generalized Endpoint | |
+-----------+----------------+-------------------------+-----------+ | | | object type for non-GMPLS | |
| | | LSPs | |
+------------+-----------+---------------------------+-----------+
10. Manageability Considerations Table 5
9. Manageability Considerations
General PCE management considerations are discussed in [RFC4655] and General PCE management considerations are discussed in [RFC4655] and
[RFC5440], and GMPLS specific PCEP management considerations are [RFC5440], and GMPLS-specific PCEP management considerations are
described in [RFC8779]. In this document the management described in [RFC8779]. In this document, the management
considerations for stateful PCEP extension in GMPLS are described. considerations for stateful PCEP extension in GMPLS are described.
This section follows the guidance of [RFC6123]. This section follows the guidance of [RFC6123].
10.1. Control of Function through Configuration and Policy 9.1. Control of Function through Configuration and Policy
In addition to the parameters already listed in Section 8.1 of In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuration of the [RFC5440], a PCEP implementation SHOULD allow configuration of the
following PCEP session parameters on a PCC, however, an following PCEP session parameters on a PCC. However, an
implementation MAY choose to make these features available on all implementation MAY choose to make these features available on all
PCEP sessions: PCEP sessions:
* The ability to send stateful PCEP messages for GMPLS LSPs. * The ability to send stateful PCEP messages for GMPLS LSPs.
* The ability to use path computation constraints (e.g., XRO). * The ability to use path computation constraints (e.g., XRO).
In addition to the parameters already listed in Section 8.1 of In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuration of the [RFC5440], a PCEP implementation SHOULD allow configuration of the
following PCEP session parameters on a PCE: following PCEP session parameters on a PCE:
* The ability to compute paths in a stateful manner in GMPLS * The ability to compute paths in a stateful manner in GMPLS
networks. networks.
* A set of GMPLS-specific constraints. * A set of GMPLS-specific constraints.
These parameters may be configured as default parameters for any PCEP These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or they may apply to a session the PCEP speaker participates in or they may apply to a
specific session with a given PCEP peer or a specific group of specific session with a given PCEP peer or a specific group of
sessions with a specific group of PCEP peers. sessions with a specific group of PCEP peers.
10.2. Information and Data Models 9.2. Information and Data Models
The YANG model in [I-D.ietf-pce-pcep-yang] can be used to configure The YANG module in [PCE-PCEP-YANG] can be used to configure and
and monitor PCEP states and messages. To make sure that the YANG monitor PCEP states and messages. To make sure that the YANG module
model is useful for the extensions as described in this document, it is useful for the extensions as described in this document, it would
would need to include advertised GMPLS stateful capabilities etc. A need to include advertised GMPLS stateful capabilities etc. A future
future version of [I-D.ietf-pce-pcep-yang] will include this. version of [PCE-PCEP-YANG] will include this.
As described in [I-D.ietf-teas-yang-path-computation], a YANG-based As described in [YANG-PATH-COMPUTATION], a YANG-based interface can
interface can be used in some cases to request GMPLS path be used in some cases to request GMPLS path computations, instead of
computations, instead of PCEP. Refer PCEP. Refer to [YANG-PATH-COMPUTATION] for details.
[I-D.ietf-teas-yang-path-computation] for details.
10.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
This document makes no change to the basic operation of PCEP, so This document makes no change to the basic operation of PCEP, so
there are no changes to the requirements for liveness detection and there are no changes to the requirements for liveness detection and
monitoring in [RFC4657] and Section 8.3 of [RFC5440]. monitoring in [RFC4657] and Section 8.3 of [RFC5440].
10.4. Verifying Correct Operation 9.4. Verifying Correct Operation
This document makes no change to the basic operations of PCEP and the This document makes no change to the basic operations of PCEP and the
considerations described in Section 8.4 of [RFC5440]. New errors considerations described in Section 8.4 of [RFC5440]. New errors
defined by this document should satisfy the requirement to log error defined by this document should satisfy the requirement to log error
events. events.
10.5. Requirements on Other Protocols and Functional Components 9.5. Requirements on Other Protocols and Functional Components
When the detailed route information is included for LSP state When the detailed route information is included for LSP state
synchronization (either at the initial stage or during LSP state synchronization (either at the initial stage or during the LSP State
report process), this requires the ingress node of an LSP to carry Report process), this requires the ingress node of an LSP to carry
the RRO object in order to enable the collection of such information. the Record Route Object (RRO) object in order to enable the
collection of such information.
10.6. Impact on Network Operation 9.6. Impact on Network Operation
The management considerations concerning the impact on network The management considerations concerning the impact on network
operations described in Section 4.6 of [RFC8779] apply here. operations described in Section 4.6 of [RFC8779] apply here.
11. Security Considerations 10. Security Considerations
The security considerations elaborated in [RFC5440] apply to this The security considerations elaborated in [RFC5440] apply to this
document. The PCEP extensions to support GMPLS-controlled networks document. The PCEP extensions to support GMPLS-controlled networks
should be considered under the same security as for MPLS networks, as should be considered under the same security as for MPLS networks, as
noted in [RFC7025]. So the PCEP extension to support GMPLS specified noted in [RFC7025]. Therefore, the PCEP extension to support GMPLS
in [RFC8779] is used as the foundation of this document and the specified in [RFC8779] is used as the foundation of this document;
security considerations in [RFC8779] should also be applicable to the security considerations in [RFC8779] should also be applicable to
this document. The secure transport of PCEP specified in [RFC8253] this document. The secure transport of PCEP specified in [RFC8253]
allows the usage of Transport Layer Security (TLS). The same can allows the usage of Transport Layer Security (TLS). The same can
also be used by the PCEP extension defined in this document. also be used by the PCEP extension defined in this document.
This document provides additional extensions to PCEP so as to This document provides additional extensions to PCEP so as to
facilitate stateful PCE usage in GMPLS-controlled networks, on top of facilitate stateful PCE usage in GMPLS-controlled networks, on top of
[RFC8231] and [RFC8281]. Security issues caused by the extension in [RFC8231] and [RFC8281]. Security issues caused by the extension in
[RFC8231] and [RFC8281] are not altered by the additions in this [RFC8231] and [RFC8281] are not altered by the additions in this
document. The security considerations in [RFC8231] and [RFC8281], document. The security considerations in [RFC8231] and [RFC8281],
including both issues and solutions, apply to this document as well. including both issues and solutions, apply to this document as well.
12. Acknowledgement 11. References
We would like to thank Adrian Farrel, Cyril Margaria, George Swallow,
Jan Medved, Sue Hares, and John Scudder for the useful comments and
discussions.
Thanks to Dhruv Dhody for Shepherding this document and providing
useful comments.
13. Nomative References 11.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
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <https://www.rfc-editor.org/info/rfc5521>. 2009, <https://www.rfc-editor.org/info/rfc5521>.
[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
skipping to change at page 20, line 5 skipping to change at line 862
Zhang, Ed., "Path Computation Element Communication Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779, Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020, DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/info/rfc8779>. <https://www.rfc-editor.org/info/rfc8779>.
[RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag [RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag
Extension for Stateful PCE", RFC 9357, Extension for Stateful PCE", RFC 9357,
DOI 10.17487/RFC9357, February 2023, DOI 10.17487/RFC9357, February 2023,
<https://www.rfc-editor.org/info/rfc9357>. <https://www.rfc-editor.org/info/rfc9357>.
14. Informative References 11.2. Informative References
[I-D.ietf-pce-lsp-extended-flags]
Xiong, Q., "Label Switched Path (LSP) Object Flag
Extension for Stateful PCE", Work in Progress, Internet-
Draft, draft-ietf-pce-lsp-extended-flags-09, 23 October
2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-lsp-extended-flags-09>.
[I-D.ietf-pce-pcep-yang] [PCE-PCEP-YANG]
Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura, Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
"A YANG Data Model for Path Computation Element Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress, Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-22, 11 September Internet-Draft, draft-ietf-pce-pcep-yang-22, 11 September
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-yang-22>. pce-pcep-yang-22>.
[I-D.ietf-teas-yang-path-computation]
Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y.
Shi, "A YANG Data Model for requesting path computation",
Work in Progress, Internet-Draft, draft-ietf-teas-yang-
path-computation-21, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-path-computation-21>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003, RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>. <https://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
skipping to change at page 21, line 15 skipping to change at line 903
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>. <https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>. May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123, Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011, DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>. <https://www.rfc-editor.org/info/rfc6123>.
[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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[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>.
skipping to change at page 22, line 30 skipping to change at line 953
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/info/rfc8623>. <https://www.rfc-editor.org/info/rfc8623>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE", Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020, RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>. <https://www.rfc-editor.org/info/rfc8745>.
Appendix A. Contributors' Address [YANG-PATH-COMPUTATION]
Xian Zhang Busi, I., Ed., Belotti, S., Ed., de Dios, O. G., Sharma,
Huawei Technologies A., and Y. Shi, "A YANG Data Model for requesting path
Email: zhang.xian@huawei.com computation", Work in Progress, Internet-Draft, draft-
ietf-teas-yang-path-computation-21, 7 July 2023,
Dhruv Dhody <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
Huawei Technology yang-path-computation-21>.
India
Email: dhruv.ietf@gmail.com
Yi Lin
Huawei Technologies
Email: yi.lin@huawei.com
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Email: ramon.casellas@cttc.es
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
Robert Varga
Pantheon Technologies
Email: nite@hq.sk
Appendix B. PCEP Messages Appendix A. PCEP Messages
This section uses the Routing Backus-Naur Form (RBNF) [RFC5511] to This section uses the Routing Backus-Naur Form (RBNF) [RFC5511] to
illustrate the PCEP messages. The RBNF in this section is reproduced illustrate the PCEP messages. The RBNF in this section is reproduced
for informative purposes. It is also expanded to show the GMPLS for informative purposes. It is also expanded to show the GMPLS-
specific objects. specific objects.
B.1. The PCRpt Message A.1. The PCRpt Message
According to [RFC8231], the PCRpt Message is used to report the According to [RFC8231], the PCRpt message is used to report the
current state of an LSP. This document extends the message in current state of an LSP. This document extends the message in
reporting the status of LSPs with GMPLS characteristics. reporting the status of LSPs with GMPLS characteristics.
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<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> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<path> <path>
Where: Where:
<path> ::= <intended-path> <path> ::= <intended-path>
[<actual-attribute-list><actual-path>] [<actual-attribute-list><actual-path>]
<intended-attribute-list> <intended-attribute-list>
<actual-attribute-list> ::=[<BANDWIDTH>] <actual-attribute-list> ::=[<BANDWIDTH>]
[<metric-list>] [<metric-list>]
Where: Where:
* The END-POINTS object MUST be carried in a PCRpt message when the * The END-POINTS object MUST be carried in a PCRpt message when the
G flag is set in the LSP-EXTENDED-FLAG TLV in the LSP object for a G flag is set in the LSP-EXTENDED-FLAG TLV in the LSP object for a
GMPLS LSP. GMPLS LSP.
* <intended-path> is represented by the ERO object defined in * <intended-path> is represented by the ERO object defined in
Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit Section 7.9 of [RFC5440] and augmented in [RFC8779] with ELC.
label control (ELC) and Path Keys.
* <actual-attribute-list> consists of the actual computed and * <actual-attribute-list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists> objects signaled values of the <BANDWIDTH> and <metric-lists> objects
defined in [RFC5440]. defined in [RFC5440].
* <actual-path> is represented by the RRO object defined in * <actual-path> is represented by the RRO object defined in
Section 7.10 of [RFC5440]. Section 7.10 of [RFC5440].
* <intended-attribute-list> is the attribute-list defined in * <intended-attribute-list> is the attribute-list defined in
Section 6.5 of [RFC5440] and extended by many other documents that Section 6.5 of [RFC5440] and extended by many other documents that
define PCEP extensions for specific scenarios as shown below: define PCEP extensions for specific scenarios as shown below:
<attribute-list> ::= [<of-list>] <attribute-list> ::= [<of-list>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>][<XRO>] [<IRO>][<XRO>]
[<INTER-LAYER>] [<INTER-LAYER>]
[<SWITCH-LAYER>] [<SWITCH-LAYER>]
[<REQ-ADAP-CAP>] [<REQ-ADAP-CAP>]
[<SERVER-INDICATION>] [<SERVER-INDICATION>]
B.2. The PCUpd Message A.2. The PCUpd Message
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<path> <path>
Where: Where:
<path> ::= <intended-path><intended-attribute-list> <path> ::= <intended-path><intended-attribute-list>
Where: Where:
* The END-POINTS object MUST be carried in a PCUpd message for the * The END-POINTS object MUST be carried in a PCUpd message for the
GMPLS LSP. GMPLS LSP.
* <intended-path> is represented by the ERO object defined in * <intended-path> is represented by the ERO object defined in
Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit Section 7.9 of [RFC5440], augmented in [RFC8779] with ELC.
label control (ELC) and Path Keys.
* <intended-attribute-list> is the attribute-list defined in * <intended-attribute-list> is the attribute-list defined in
[RFC5440] and extended by many other documents that define PCEP [RFC5440] and extended by many other documents that define PCEP
extensions for specific scenarios and as shown for PCRpt above. extensions for specific scenarios and as shown for PCRpt above.
B.3. The PCInitiate Message A.3. The PCInitiate Message
According to [RFC8281], the PCInitiate Message is used allow LSP According to [RFC8281], the PCInitiate message is used allow LSP
Initiation. This document extends the message in initiating LSPs Initiation. This document extends the message in initiating LSPs
with GMPLS characteristics. The format of a PCInitiate message is as with GMPLS characteristics. The format of a PCInitiate message is as
follows: follows:
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: Where:
<Common Header> is defined in <xref target="RFC5440" />. <Common Header> is defined in <xref target="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-instantiation>| <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>) <PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP> <PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<ERO> <ERO>
[<attribute-list>] [<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP> <PCE-initiated-lsp-deletion> ::= <SRP>
<LSP> <LSP>
The format of the PCInitiate message is unchanged from Section 5.1 of The format of the PCInitiate message is unchanged from Section 5.1 of
[RFC8281]. All fields are similar to the PCRpt and the PCUpd [RFC8281]. All fields are similar to the PCRpt and the PCUpd
message. messages.
Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria, George Swallow,
Jan Medved, Sue Hares, and John Scudder for the useful comments and
discussions.
Thanks to Dhruv Dhody for Shepherding this document and providing
useful comments.
Contributors
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technology
India
Email: dhruv.ietf@gmail.com
Yi Lin
Huawei Technologies
Email: yi.lin@huawei.com
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
08860 Barcelona Castelldefels
Spain
Email: ramon.casellas@cttc.es
Siva Sivabalan
Cisco Systems
Email: msiva@cisco.com
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
Robert Varga
Pantheon Technologies
Email: nite@hq.sk
Authors' Addresses Authors' Addresses
Young Lee Young Lee
Samsung Samsung
Email: younglee.tx@gmail.com Email: younglee.tx@gmail.com
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Telefonica
Email: oscar.gonzalezdedios@telefonica.com Email: oscar.gonzalezdedios@telefonica.com
Victor Lopez Victor Lopez
Nokia Nokia
 End of changes. 157 change blocks. 
621 lines changed or deleted 591 lines changed or added

This html diff was produced by rfcdiff 1.48.