PCE Working Group Y. Lee
Internet-Draft Samsung
Intended status: Standards Track H. Zheng
Expires: December 17, 2022 Huawei Technologies
O. G. de Dios
Telefonica
Victor Lopez
Nokia
Z. Ali
Cisco Systems
June 17, 2022
Path Computation Element Communication Protocol (PCEP) Extensions for
Stateful PCE Usage in GMPLS-controlled Networks
draft-ietf-pce-pcep-stateful-pce-gmpls-19
Abstract
The PCE communication Protocol (PCEP) has been extended to support
stateful PCE functions where the Stateful PCE maintains information
about paths and resource usage within a network, but these
extensions do not cover all requirements for GMPLS networks.
This document provides extensions required for PCEP so as to enable
the usage of a stateful PCE capability in GMPLS-controlled networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. The list of current Internet-Drafts is at
https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
Lee & Zheng, et al Expires December 2022 [Page 1]
Internet-Draft Stateful PCEP for GMPLS June 2022
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
Table of Contents .............................................. 2
1. Introduction ................................................ 3
1.1. Conventions used in this document ...................... 4
2. Terminology ................................................. 4
3. General Context of Stateful PCE and PCEP for GMPLS .......... 4
4. Main Requirements ........................................... 5
5. Overview of Stateful PCEP Extensions for GMPLS Networks ..... 6
5.1. Capability Advertisement for Stateful PCEP in GMPLS .... 6
5.2. LSP Synchronization .................................... 7
5.3. LSP Delegation and Cleanup ............................. 7
5.4. LSP Operations ......................................... 7
6. PCEP Object Extensions ...................................... 8
6.1. Existing Extensions used for Stateful GMPLS ............ 8
6.2. New Extensions ......................................... 9
6.2.1. GMPLS-CAPABILITY TLV in OPEN Object ............... 9
6.2.2. New LSP Exclusion Sub-object in the XRO ........... 9
6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object10
7. Update to Error Handling ................................... 11
7.1. Error Handling in PCEP Capabilities Advertisement ..... 11
7.2. Error Handling in LSP Re-optimization ................. 12
Lee & Zheng Expires December 2022 [Page 2]
Internet-Draft Stateful PCEP for GMPLS June 2022
7.3. Error Handling in Route Exclusion ..................... 12
7.4. Error Handling for generalized END-POINTS ............. 12
8. Implementation ............................................. 13
8.1. Huawei Technologies ................................... 13
9. IANA Considerations ........................................ 14
9.1. New Flags in GMPLS-CAPABILITY TLV ..................... 14
9.2. New Sub-object for the Exclude Route Object ........... 14
9.3. Flags Field for LSP exclusion Sub-object .............. 14
9.4. New Flags in the LSP-EXTENDED-FLAGS TLV .............. 14
9.5. New PCEP Error Codes .................................. 15
10. Manageability Considerations ............................. 16
10.1. Control of Function through Configuration and Policy . 16
10.2. Information and Data Models .......................... 16
10.3. Liveness Detection and Monitoring .................... 17
10.4. Verifying Correct Operation .......................... 17
10.5. Requirements on Other Protocols and Functional Components17
10.6. Impact on Network Operation .......................... 17
11. Security Considerations ................................... 17
12. Acknowledgement ........................................... 18
13. References ................................................ 18
13.1. Normative References ................................. 18
13.2. Informative References ............................... 19
14. Contributors' Address ..................................... 20
Appendix A: PCEP Messages ..................................... 21
A.1 The PCRpt Message ..................................... 21
A.2 The PCUpd Message ...................................... 22
A.3 The PCInitiate Message ................................. 23
Authors' Addresses ............................................ 24
1. Introduction
[RFC4655] presents the architecture of a Path Computation Element
(PCE)-based model for computing Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering Label Switched
Paths (TE LSPs). To perform such a constrained computation, a PCE
stores the network topology (i.e., TE links and nodes) and resource
information (i.e., TE attributes) in its TE Database (TED). A PCE
that only maintains TED is referred to as a stateless PCE. [RFC5440]
describes the Path Computation Element Communication Protocol (PCEP)
for interaction between a Path Computation Client (PCC) and a PCE,
or between two PCEs, enabling computation of TE LSPs. PCEP is
further extended to support GMPLS-controlled networks as per
[RFC8779].
Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in [RFC8051].
Further discussion of concept of a stateful PCE can be found in
[RFC7399]. In order for these applications to able to exploit the
Lee & Zheng Expires December 2022 [Page 3]
Internet-Draft Stateful PCEP for GMPLS June 2022
capability of stateful PCEs, extensions to stateful PCEP for GMPLS
are required.
[RFC8051] describes how a stateful PCE can be applicable to solve
various problems for MPLS-TE and GMPLS networks and the benefits it
brings to such deployments.
[RFC8231] specifies a set of extensions to PCEP to enable stateful
control of TE LSPs where they are configured on the PCC, and control
over them could be delegated to the PCE. Furthermore, [RFC8281]
describes the setup and teardown of PCE-initiated LSPs under the
active stateful PCE model, without the need for local configuration
on the PCC. However, both the documents left out the specification
for technology-specific objects/TLVs, and do not cover the GMPLS
networks (e.g., Wavelength Switched Optical Network (WSON), Optical
Transport Network (OTN), Synchronous Optical Network
(SONET)/Synchronous Digital Hierarchy (SDH), etc. technologies).
This document focuses on the extensions that are necessary in order
for the deployment of stateful PCEs and the requirements for PCE-
initiated LSPs in GMPLS-controlled networks. Section 3 provides a
general context of the usage of Stateful PCE and PCEP for GMPLS.
The various requirements for stateful GMPLS including PCE-initiation
for GMPLS LSPs is provided in Section 4. An overview of the PCEP
extensions are specified in Section 5, as a solution to address such
requirements with PCEP object extensions in Section 6.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Terminology used in this document is the same as terminology used in
[RFC5440], [RFC8231], [RFC8281], and [RFC8779]
3. General Context of Stateful PCE and PCEP for GMPLS
This section is built on the basis of Stateful PCE specified in
[RFC8231] and PCEP for GMPLS specified in [RFC8779].
Lee & Zheng Expires December 2022 [Page 4]
Internet-Draft Stateful PCEP for GMPLS June 2022
The operation for Stateful PCE on LSPs can be divided into two types,
active stateful PCE and passive stateful PCE as described in
[RFC8051].
For active stateful PCE, a Path Computation Update Request (PCUpd)
message is sent from PCE to PCC to update the LSP state for the LSP
delegated to the PCE. Any changes to the delegated LSPs generate a
Path Computation State Report (PCRpt) message from the PCC to PCE to
convey the changes of the LSP. Any modifications to the Objects/TLVs
that are identified in this document to support GMPLS technology-
specific attributes will be carried in the PCRpt and PCUpd messages.
For passive stateful PCEs, PCReq/PCRep messages are used to request
for path computation. GMPLS-technology specific Objects and TLVs
are defined in [RFC8779], this document builds on it and adds the
stateful PCE aspects where applicable. Passive Stateful PCE makes
use of PCRpt messages when reporting LSP State changes sent by PCC
to PCEs. Any modifications to the Objects/TLVs that are identified
in this document to support GMPLS technology-specific attributes
will be carried in the PCRpt message.
Furthermore, the LSP Initiation function of PCEP is defined in
[RFC8281] to allow the PCE to initiate LSP establishment after the
path is computed. An LSP Initiate Request (PCInitiate) messages are
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
GMPLS technology-specific attributes will be carried in the
PCInitiate messages.
[RFC8779] defines GMPLS-technology specific Objects/TLVs in
stateless PCEP, and this document makes use of these Objects/TLVs
without modifications where applicable. Where these Objects/TLVs
require modifications to incorporate stateful PCE, they are
described in this document. The PCE-Initiated LSP would follow the
principle specified in [RFC8281], and GMPLS-specific extensions are
also included in this document.
4. Main Requirements
This section notes the main functional requirements for PCEP
extensions to support stateful PCE for use in GMPLS-controlled
networks, based on the description in [RFC8051]. Many
requirements are common across a variety of network types (e.g.,
MPLS-TE networks and GMPLS networks) and the protocol extensions to
meet the requirements are already described in [RFC8231], such as
LSP update, delegation and state synchronization/report. Protection
context information that describes the GMPLS requirement can also
follow the description in [RFC8745]. This document does not repeat
Lee & Zheng Expires December 2022 [Page 5]
Internet-Draft Stateful PCEP for GMPLS June 2022
the description of those protocol extensions. This document
presents protocol extensions for a set of requirements which are
specific to the use of a stateful PCE in a GMPLS-controlled network.
The requirements for GMPLS-specific stateful PCE are as follows:
o Advertisement of the stateful PCE capability. This generic
requirement is covered in Section 5.4 of [RFC8231]. The GMPLS-
CAPABILITY TLV specified in section 2.1 of [RFC8779] and its
extension in this document needs to be advertised as well.
o All the PCEP messages need to be capable of indicating GMPLS-
specific switching capabilities. GMPLS LSP
creation/modification/deletion requires knowledge of LSP
switching capability (e.g., Time-Division Multiplex Capable
(TDM), Layer 2 Switch Capable (L2SC), OTN-TDM, Lambda Switch
Capable (LSC), etc.) and the generalized payload (G-PID) to be
used according to [RFC3471], [RFC3473]. It also requires the
specification of data flow specific traffic parameters (also
known as Traffic Specification (Tspec)), which are technology
specific. Such information would need to be included in various
PCEP messages.
o In some technologies, path calculation is tightly coupled with
label selection along the route. For example, path calculation
in a Wavelength Division Multiplexing (WDM) network may include
lambda continuity and/or lambda feasibility constraints and
hence a path computed by the PCE is associated with a specific
lambda (label). Hence, in such networks, the label information
needs to 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 may be required.
o Stateful PCEP messages also need to indicate the protection
context information for the LSP specified by GMPLS, as defined
in [RFC4872], [RFC4873].
5. Overview of Stateful PCEP Extensions for GMPLS Networks
5.1. Capability Advertisement for Stateful PCEP in GMPLS
Capability Advertisement has been specified in [RFC8231], and can be
achieved by using the "STATEFUL-PCE-CAPABILITY TLV" in the Open
message. Another GMPLS-CAPABILITY TLV has been defined in [RFC8779].
A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV
is created by the IANA as requested by [RFC8779]. New bits, LSP-
REPORT-CAPABILITY(TBDa), LSP-UPDATE-CAPABILITY (TBD1), and LSP-
INSTANTIATION-CAPABILITY (TBD2), are introduced in the GMPLS-
Lee & Zheng Expires December 2022 [Page 6]
Internet-Draft Stateful PCEP for GMPLS June 2022
CAPABILITY TLV as flags to indicate the capability for LSP report,
update and initiation in GMPLS networks.
5.2. LSP Synchronization
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
attributes) before it can perform path computations or update LSP
attributes in a PCC. This process is known as LSP state
synchronization. The LSP attributes including bandwidth, associated
route, and protection information etc., are stored by the PCE in the
LSP database (LSP-DB). Note that, as described in [RFC8231], the
LSP state synchronization covers both the bulk reporting of LSPs at
initialization as well the reporting of new or modified LSPs during
normal operation. Incremental LSP-DB synchronization may be desired
in a GMPLS-controlled network and it is specified in [RFC8232].
The format of the PCRpt message is specified in [RFC8231] and
extended in [RFC8623] to include the END-POINTS object. The END-
POINTS object is extended for GMPLS in [RFC8779]. The END-POINTS
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 as per the same.
The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and
Exclude Route Object (XRO) objects are extended for GMPLS in
[RFC8779] and are also used in the PCRpt in the same manner. These
objects are carried in the PCRpt message as specified in [RFC8231]
(as the attribute-list defined in Section 6.5 of [RFC5440] and
extended by many other documents that define PCEP extensions for
specific scenarios).
The SWITCH-LAYER object is defined in [RFC8282]. This object is
carried in PCRpt message as specified in section 3.2 of [RFC8282].
5.3. LSP Delegation and Cleanup
LSP delegation and cleanup procedure specified in [RFC8231] are
equally applicable to GMPLS LSPs and this document does not modify
the associated usage.
5.4. LSP Operations
Both passive and active stateful PCE mechanisms in [RFC8231] are
applicable in GMPLS-controlled networks. Remote LSP Initiation in
[RFC8281] is also applicable in GMPLS-controlled networks.
Lee & Zheng Expires December 2022 [Page 7]
Internet-Draft Stateful PCEP for GMPLS June 2022
6. PCEP Object Extensions
6.1. Existing Extensions used for Stateful GMPLS
Existing extensions defined in [RFC8779] can be used in the Stateful
PCEP with no changes or slightly changes for GMPLS network control,
including the following:
o END-POINTS: Generalized END-POINTS was specified in [RFC8779] to
include GMPLS capabilities. All Stateful PCEP messages MUST include
the END-POINTS with Generalized Endpoint object type, containing the
LABEL-REQUEST TLV. Further note that
o As per [RFC8779] for stateless GMPLS path computation, the
Generalized END-POINTS object may contain a LABEL-REQUEST TLV
and/or LABEL-SET. In this document, only the LABEL-REQUEST TLV is
used to specify the switching type, encoding type and G-PID of the
LSP.
o If unnumbered endpoint addresses are used for the LSP, the
UNNUMBERED-ENDPOINT TLV [RFC8779] MUST be use to specify the
unnumbered endpoint addresses.
o The Generalized END-POINTS MAY contain other TLVs defined in
[RFC8779].
o RP: RP object extension, together with the Routing Granularity
(RG) flag defined in [RFC8779], are applicable in the Stateful PCEP
for GMPLS networks.
o BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to
represent GMPLS features, including asymmetric bandwidth and G-PID
information.
o LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable
in Stateful PCEP for GMPLS networks.
o IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in
Stateful PCEP for GMPLS networks.
o XRO: XRO Extensions in Section 2.7 of [RFC8779] is applicable in
Stateful PCEP for GMPLS networks. A new flag is defined in section
7.2.2 of this document.
o ERO: The Explicit Route Object (ERO) was not extended in
[RFC8779], and not in this document as well.
Lee & Zheng Expires December 2022 [Page 8]
Internet-Draft Stateful PCEP for GMPLS June 2022
o SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of
[RFC8282] is applicable in Stateful PCEP messages for GMPLS networks.
6.2. New Extensions
6.2.1. GMPLS-CAPABILITY TLV in OPEN Object
In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from
the "PCEP TLV Type Indicators" sub-registry. The TLV is extended
with three flags to indicate the Report, Update, and Initiation
capabilities.
R (LSP-REPORT-CAPABILITY(TBDa) -- 1 bit): if set to 1 by a PCC, the
R flag indicates that the PCC is capable of reporting the current
state of an GMPLS LSP, whenever there's a change to the parameters
or operational status of the GMPLS LSP; if set to 1 by a PCE, the R
Flag indicates that the PCE is interested in receiving GMPLS LSP
State Reports whenever there is a parameter or operational status
change to the LSP. The LSP-REPORT-CAPABILITY flag must be
advertised by both a PCC and a PCE 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 flag indicates that the PCC allows modification of GMPLS LSP
parameters; if set to 1 by a PCE, the U flag indicates that the PCE
is capable of updating GMPLS LSP parameters. The LSP-UPDATE-
CAPABILITY flag must be advertised by 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
PCC, the I flag indicates that the PCC allows instantiation of a
GMPLS LSP by a PCE. If set to 1 by a PCE, the I flag indicates that
the PCE supports instantiating GMPLS LSPs. The LSP-INSTANTIATION-
CAPABILITY flag must be set by both the PCC and PCE in order to
enable PCE-initiated LSP instantiation.
6.2.2. New LSP Exclusion Sub-object in the XRO
[RFC5521] defines a mechanism for a PCC to request or demand that
specific nodes, links, or other network resources are excluded from
paths computed by a PCE. A PCC may wish to request the computation
of a path that avoids all link and nodes traversed by some other LSP.
To this end this document defines a new sub-object for use with
route exclusion defined in [RFC5521]. The LSP exclusion sub-object
is as follows:
Lee & Zheng Expires December 2022 [Page 9]
Internet-Draft Stateful PCEP for GMPLS June 2022
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Type (TBD3) | Length | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X bit is defined in [RFC5521].
Type: Sub-object Type for an LSP exclusion sub-object. Value of
TBD3. To be assigned by IANA.
Length: The Length contains the total length of the sub-object in
bytes, including the Type and Length fields.
Reserved: MUST be set to zero on transmission and ignored on
receipt.
Flags: This field may be used to further specify the exclusion
constraint with regard to the LSP. Currently, no flags are defined.
Symbolic Path Name: This is the identifier given to an LSP and is
unique in the context of the PCC address as defined in [RFC8231].
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
object (XRO) to exclude resources from multiple LSPs. When a
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.
6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object
The LSP Object is defined in Section 7.3 of [RFC8231], and the new
extended flags TLV is defined in [I-D.ietf-pce-lsp-extended-flags].
This TLV is used in PCUpd, PCRpt and PCInitiate messages for GMPLS,
with the following flags defined in this document.
o G (GMPLS LSP(TBDb) -- 1 bit) : If set to 1, it indicates the LSP
is a GMPLS LSP.
Lee & Zheng Expires December 2022 [Page 10]
Internet-Draft Stateful PCEP for GMPLS June 2022
o B (Bidirectional LSP(TBD4) -- 1 bit): If set to 0, it indicates
a request to create a uni-directional LSP. If set to 1, it
indicates a request to create a bidirectional co-routed LSP.
o RG (Routing Granularity(TBDc) -- 2 bits) : RG flag for GMPLS is
also defined in the LSP-EXTENDED-FLAG TLV The value are defined as
per [RFC8779]:
00: reserved
01: node
10: link
11: label
7. Update to Error Handling
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
an Error-value that provides additional information about the error.
In this document the following error handling procedures are
introduced. All the error handling specified in section 3 of
[RFC8779] is applicable and MUST be supported for stateful PCE in
GMPLS networks.
7.1. Error Handling in PCEP Capabilities Advertisement
The PCEP extensions described in this document for stateful PCEs
with GMPLS capability MUST NOT be used if the PCE has not advertised
its stateful capability with GMPLS as per Section 5.2. If the PCC
supports the extensions as per this document (understands the U flag
that indicates the stateful LSP-UPDATE-CAPABILITY) but did not
advertise this capability, then upon receipt of a PCUpd message for
GMPLS LSP from the PCE, it SHOULD generate a PCErr with error-type
19 ("Invalid Operation"), error-value TBDx ("Attempted LSP Update
Request for GMPLS if stateful PCE capability for GMPLS was not
advertised"), and terminate the PCEP session.
If the PCE supports the extensions as per this document (understands
the R flag that indicates the stateful LSP-REPORT-CAPABILITY) but
did not advertise this capability, then upon receipt of a PCRpt
message for GMPLS LSP from the PCC, it SHOULD generate a PCErr with
error-type 19 ("Invalid Operation"), error-value TBDy ("Attempted
LSP Report Request for GMPLS if stateful PCE capability for GMPLS
was not advertised"), and terminate the PCEP session.
The PCEP extensions described in this document for PCC or PCE with
the PCE-Initiation capability for GMPLS LSPs MUST NOT be used if the
PCC or PCE has not advertised its stateful capability with
Instantiation and GMPLS-CAPABILITY as per [RFC8779]. If the PCC
Lee & Zheng Expires December 2022 [Page 11]
Internet-Draft Stateful PCEP for GMPLS June 2022
supports the extensions as per this document (understands the I flag
that indicates LSP-INSTANTIATION-CAPABILITY) but did not advertise
this capability, then upon receipt of a PCInitiate message for GMPLS
LSP from the PCE, it SHOULD generate a PCErr with error-type 19
("Invalid Operation"), error-value TBDz ("Attempted LSP
Instantiation Request for GMPLS if stateful PCE instantiation
capability for GMPLS was not advertised"), and terminate the PCEP
session.
7.2. Error Handling in LSP Re-optimization
A stateful PCE performs the re-optimization when the R bit is set in
RP object. If no LSP state information is available to carry out re-
optimization, the stateful PCE SHOULD report the error "LSP state
information unavailable for the LSP re-optimization" (Error Type =
19, Error value= TBD6). Note that this error message could also be
used by non-GMPLS LSPs. The PCE MAY suppress this error message by
a configurable threshold.
7.3. Error Handling in Route Exclusion
The LSP exclusion sub-object in XRO is defined in section 6.2.2 of
this document MAY be present multiple times. When a stateful PCE
receives a PCEP message carrying this sub-object, it searches for
the identified LSP in its LSP-DB and then excludes from the new path
computation all the resources used by the identified LSP. If the
stateful PCE cannot recognize symbolic path name of the identified
LSP, it SHOULD send an error message PCErr reporting Error-type = 19
("Invalid Operation"), Error-value = TBD7 ("The LSP state
information for route exclusion purpose cannot be found").
Optionally, it may also provide with the unrecognized symbolic path
name information to the requesting PCC using the error reporting
techniques described in [RFC5440]. However, the PCE MAY suppress
this error message by a configurable threshold.
7.4. Error Handling for generalized END-POINTS
Note that the ENDPOINT object in the Stateful PCEP messages was
introduced for P2MP [RFC8623]. Similarly, the END-POINTS object MUST
be carried for the GMPLS LSP. If the END-POINTS object is missing
and the GMPLS flag in LSP-EXTENDED-FLAG is set, the receiving PCE or
PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object
missing") and Error-value=3 ("END-POINTS object missing") (defined
in [RFC5440]). Similarly, if the END-POINTS object with the
Lee & Zheng Expires December 2022 [Page 12]
Internet-Draft Stateful PCEP for GMPLS June 2022
Generalized Endpoint object type is received but if the LSP-
EXTENDED-FLAG TLV is missing in the LSP object or if the G flag in
the LSP-EXTENDED-FLAG TLV is not set, the receiving PCE or PCC would
send a PCErr message with Error-type = 19 ("Invalid Operation"),
Error-value = TBD9 ("Use of Generalized Endpoint object type for
non-GMPLS LSP").
If the ENDPOINT object with Generalized Endpoint Object Type is
missing the LABEL-REQUEST TLV, the receiving PCE or PCC MUST send a
PCErr message with Error-type=6 ("Mandatory Object missing") and
Error-value=TBD8 ("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
o Organization: Huawei Technologies, Co. LTD
o Implementation: Huawei NCE-T
o Description: PCRpt, PCUpd and PCInitiate messages for GMPLS
Network
o Maturity Level: Production
o Coverage: Full
o Contact: zhenghaomian@huawei.com
Lee & Zheng Expires December 2022 [Page 13]
Internet-Draft Stateful PCEP for GMPLS June 2022
9. IANA Considerations
9.1. New Flags in GMPLS-CAPABILITY TLV
[RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA
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:
Bit Description Reference
--- -------------------------------- -------------
TBDa LSP-REPORT-CAPABILITY (R) [This.I-D]
TBD1 LSP-UPDATE-CAPABILITY (U) [This.I-D]
TBD2 LSP-INSTANTIATION-CAPABILITY (I) [This.I-D]
9.2. New Sub-object for the Exclude Route Object
IANA maintains the various XRO Subobjects types within the "XRO
Subobjects" subregistry of the PCEP Numbers registry. IANA is
requested to allocate a codepoint for another XRO subobject as
follows:
Value Description Reference
----------+------------------------------+-------------
TBD3 LSP [This.I-D]
9.3. Flags Field for LSP exclusion Sub-object
IANA is requested to create a registry 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 Description Reference
0-7 Unassigned [This.I-D]
New values are to be assigned by Standards Action [RFC8126].
Each bit should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
9.4. New Flags in the LSP-EXTENDED-FLAGS TLV
[I-D.ietf-pce-lsp-extended-flags] requested IANA to create a
subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within
Lee & Zheng Expires December 2022 [Page 14]
Internet-Draft Stateful PCEP for GMPLS June 2022
the "Path Computation Element Protocol (PCEP) Numbers" registry, to
manage the Flag field of the LSP-EXTENDED-FLAG TLV.
IANA is requested to make following assignment from this registry as
follows:
Bit Description Reference
--- ---------------------------- ----------
TBDb GMPLS LSP (G) [This.I-D]
TBD4 Bi-directional co-routed LSP (B) [This.I-D]
TBDc* Routing Granularity Flag (RG) [This.I-D]
* - 2 bits needs to be allocated
9.5. New PCEP Error Codes
IANA is requested to make the following allocation in the "PCEP-
ERROR Object Error Types and Values" registry.
+===========+================+=========================+===========+
| Error-Type| Meaning | Error-value | Reference |
+===========+================+=========================+===========+
| 6 | Mandatory | TBD8: LABEL-REQUEST TLV | This I-D |
| | Object missing | missing | |
|-----------|----------------+-------------------------+-----------+
|19 | Invalid | TBD6: LSP state info | This I-D |
| | Operation | unavailable for the | |
| | | Re-optimization | |
| | +-------------------------+-----------+
| | |TBD7: LSP state info for | This I-D |
| | |route exclusion not found| |
| | +-------------------------+-----------+
| | | TBDx: Attempted LSP | This I-D |
| | | Update Request for GMPLS| |
| | | if stateful PCE | |
| | |capability not advertised| |
| | +-------------------------+-----------+
| | |TBDy: Attempted LSP State| This I-D |
| | |Report for GMPLS if | |
| | |stateful PCE capability | |
| | |not advertised | |
| | +-------------------------+-----------+
| | |TBDz: Attempted LSP | This I-D |
| | |Instantiation Request for| |
| | |GMPLS if stateful PCE | |
| | |instantiation capability | |
| | |not advertised | |
| | +-------------------------+-----------+
Lee & Zheng Expires December 2022 [Page 15]
Internet-Draft Stateful PCEP for GMPLS June 2022
| | | TBD9: use of Generalized| This I-D |
| | | Endpoint object type for| |
| | | non-GMPLS LSP | |
+-----------+----------------+-------------------------+-----------+
10. Manageability Considerations
General PCE management considerations are discussed in [RFC4655] and
[RFC5440], and GMPLS specific PCEP management considerations are
described in [RFC8779]. In this document the management
considerations for stateful PCEP extension in GMPLS are described.
This section follows the guidance of [RFC6123].
10.1. Control of Function through Configuration and Policy
In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuration of the
following PCEP session parameters on a PCC:
* The ability to send stateful PCEP messages for GMPLS LSPs.
* The ability to use path computation constraints (e.g, XRO).
In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuration of the
following PCEP session parameters on a PCE:
* The ability to compute path in a stateful manner in GMPLS
networks.
* A set of GMPLS-specific constraint.
These parameters may be configured as default parameters for any
PCEP session the PCEP speaker participates in, or they may apply to
a specific session with a given PCEP peer or a specific group of
sessions with a specific group of PCEP peers.
10.2. Information and Data Models
The PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to
include advertised GMPLS stateful capabilities and the extended
objects specified in this document.
Lee & Zheng Expires December 2022 [Page 16]
Internet-Draft Stateful PCEP for GMPLS June 2022
10.3. Liveness Detection and Monitoring
This document makes no change to the basic operation of PCEP, so
there are no changes to the requirements for liveness detection and
monitoring in [RFC4657] and [RFC5440], Section 8.3.
10.4. Verifying Correct Operation
This document makes no change to the basic operations of PCEP and
the considerations described in [RFC5440], Section 8.4. New errors
defined by this document should satisfy the requirement to log error
events.
10.5. Requirements on Other Protocols and Functional Components
When the detailed route information is included for LSP state
synchronization (either at the initial stage or during LSP state
report process), this requires the ingress node of an LSP carry the
RRO object in order to enable the collection of such information.
10.6. Impact on Network Operation
This document makes no change to the basic operations of PCEP and
the considerations described in [RFC5440], Section 8.6. In addition
to the limit on the rate of messages sent by a PCEP speaker, a limit
MAY be placed on the size of the PCEP messages.
11. Security Considerations
The security considerations elaborated in [RFC5440] apply to this
document. The PCEP extensions to support GMPLS-controlled networks
should be considered under the same security as for MPLS networks,
as noted in [RFC7025]. So the PCEP extension to support GMPLS
specified in [RFC8779] is used as the foundation of this document
and the security considerations in [RFC8779] should also be
applicable to this document. The secure transport of PCEP specified
in [RFC8253] allows the usage of Transport Layer Security (TLS).
The same can also be used by the PCEP extension defined in this
document.
This draft provides additional extensions to PCEP so as to
facilitate stateful PCE usage in GMPLS-controlled networks, on top
of [RFC8231] and [RFC8281]. Additional security issues incurred due
to the new extensions in [RFC8231] and [RFC8281] and possible
solutions are needed to support for the new stateful PCE
capabilities. The security considerations in [RFC8231] and [RFC8281],
including both issues and solutions, apply to this document as well.
Lee & Zheng Expires December 2022 [Page 17]
Internet-Draft Stateful PCEP for GMPLS June 2022
12. Acknowledgement
We would like to thank Adrian Farrel, Cyril Margaria, George Swallow
and Jan Medved for the useful comments and discussions.
Thanks to Dhruv Dhody for Shepherding this document and providing
useful comments.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009.
[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", RFC 8174, May 2017.
[RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, September 2017.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., "PCEPS:
Usage of TLS to Provide a Secure Transport for the Path
Computation Element Communication Protocol (PCEP)", RFC
8253, October 2017.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, December 2017.
[RFC8779] Margaria, C., Gonzalez de Dios, O., Zhang, F., "Path
Computation Element Communication Protocol (PCEP)
extensions for GMPLS", RFC 8779, July 2020.
[I-D.ietf-pce-lsp-extended-flags] Xiong, Q., "LSP Object Flag
Extension of Stateful PCE", Work in progress.
Lee & Zheng Expires December 2022 [Page 18]
Internet-Draft Stateful PCEP for GMPLS June 2022
13.2. Informative References
[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., Minei, I., et al, "Applicability of Stateful
Path Computation Element (PCE) ", RFC 8051, January 2017.
[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,
September 2017.
[RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions
to the Path Computation Element communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering",
RFC 8282, December 2017.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Requirements",
RFC 4657, September 2006.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC5511, April 2005.
Lee & Zheng Expires December 2022 [Page 19]
Internet-Draft Stateful PCEP for GMPLS June 2022
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
February 2011,
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE",
RFC 7025, September 2013,
[RFC7399] Farrel, A., King, D., "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, October 2014.
[RFC8126] Cotton M., Leiba, B., Narten, T., "Guidelines for Writing
an IANA Considerations Section in RFCs ", June, 2017.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., Beeram, V., "Stateful
Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)" June 2019.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
Negi, M., "Path Computation Element Communication Protocol
(PCEP) Extensions for Associating Working and Protection
Label Switched Paths (LSPs) with Stateful PCE", March 2020.
[I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V.,
Tantsura, J., "A YANG Data Model for Path Computation
Element Communications Protocol (PCEP)", Work in progress.
14. Contributors' Address
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
Lee & Zheng Expires December 2022 [Page 20]
Internet-Draft Stateful PCEP for GMPLS June 2022
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 A: PCEP Messages
This section uses the Routing Backus-Naur Form (RBNF) [RFC5511] to
illustrate the PCEP messages. The RBNF in this section is reproduced
for informative purposes. It is also expanded to show the GMPLS
specific objects.
A.1 The PCRpt Message
According to [RFC8231], the PCRpt Message is used to report the
current state of an LSP. This document extends the message in
reporting the status of LSPs with GMPLS characteristics.
The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<END-POINTS>]
Lee & Zheng Expires December 2022 [Page 21]
Internet-Draft Stateful PCEP for GMPLS June 2022
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]
Where:
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
GMPLS LSP.
<intended-path> is represented by the ERO object defined in
Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label
control (ELC) and Path Keys.
<actual-attribute-list> consists of the actual computed and
signaled values of the <BANDWIDTH> and <metric-lists> objects
defined in [RFC5440].
<actual-path> is represented by the RRO object defined in
Section 7.10 of [RFC5440].
<intended-attribute-list> is the attribute-list defined in
Section 6.5 of [RFC5440] and extended by many other documents that
define PCEP extensions for specific scenarios as shown below:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>][<XRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
A.2 The PCUpd Message
The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>[<update-request-
Lee & Zheng Expires December 2022 [Page 22]
Internet-Draft Stateful PCEP for GMPLS June 2022
list>]
<update-request> ::= <SRP>
<LSP>
[<END-POINTS>]
<path>
Where:
<path>::= <intended-path><intended-attribute-list>
Where:
The END-POINTS object MUST be carried in a PCUpd message for the
GMPLS LSP.
<intended-path> is represented by the ERO object defined in
Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label
control (ELC) and Path Keys.
<intended-attribute-list> is the attribute-list defined in
[RFC5440] and extended by many other documents that define PCEP
extensions for specific scenarios and as shown for PCRpt above.
A.3 The PCInitiate Message
According to [RFC8281], the PCInitiate Message is used allow LSP
Initiation. This document extends the message in initiating LSPs
with GMPLS characteristics. The format of a PCInitiate message is
as follows:
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<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-
instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Lee & Zheng Expires December 2022 [Page 23]
Internet-Draft Stateful PCEP for GMPLS June 2022
The format of the PCInitiate message is unchanged from Section 5.1
of [RFC8281]. All fields are similar to the PCRpt and the PCUpd
message.
Authors' Addresses
Young Lee
Samsung
Email: younglee.tx@gmail.com
Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan, Guangdong 523808
China
Email: zhenghaomian@huawei.com
Oscar Gonzalez de Dios
Telefonica
Phone: +34 913374013
Email: oscar.gonzalezdedios@telefonica.com
Victor Lopez
Nokia
Email: victor.lopez@nokia.com
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Lee & Zheng Expires December 2022 [Page 24]
