Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks
draft-ietf-pce-pcep-stateful-pce-gmpls-17
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9504.
|
|
|---|---|---|---|
| Authors | Young Lee , Haomian Zheng , Oscar Gonzalez de Dios , Victor Lopez , Zafar Ali | ||
| Last updated | 2022-02-10 (Latest revision 2021-12-27) | ||
| Replaces | draft-zhang-pce-pcep-stateful-pce-gmpls, draft-ietf-pce-remote-initiated-gmpls-lsp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Waiting for WG Chair Go-Ahead | |
| Document shepherd | Dhruv Dhody | ||
| IESG | IESG state | Became RFC 9504 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | dd@dhruvdhody.com |
draft-ietf-pce-pcep-stateful-pce-gmpls-17
PCE Working Group Y. Lee
Internet-Draft Samsung
Intended status: Standards Track H. Zheng
Expires: August 10, 2022 Huawei Technologies
O. G. de Dios
Telefonica
Victor Lopez
Nokia
Z. Ali
Cisco Systems
February 10, 2022
Path Computation Element (PCE) Protocol Extensions for Stateful PCE
Usage in GMPLS-controlled Networks
draft-ietf-pce-pcep-stateful-pce-gmpls-17
Abstract
The Path Computation Element (PCE) facilitates Traffic Engineering
(TE) based path calculation in large, multi-domain, multi-region, or
multi-layer networks. The PCE communication Protocol (PCEP) has been
extended to support stateful PCE functions where the PCE retains
information about the paths already present in the network, but
those extensions are technology-agnostic. This memo 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 August 2022 [Page 1]
Internet-Draft Stateful PCEP for GMPLS February 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 August 10, 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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
Table of Contents .............................................. 2
1. Introduction ................................................ 3
2. Conventions used in this document ........................... 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 .................................... 6
5.3. LSP Delegation and Cleanup ............................. 7
5.4. LSP Operations ......................................... 7
6. Extension of Existing PCEP Messages ......................... 7
6.1. The PCRpt Message ...................................... 7
6.2. The PCUpd Message ...................................... 9
6.3. The PCInitiate Message ................................. 9
7. PCEP Object Extensions ..................................... 11
7.1. Existing Extensions used for Stateful GMPLS ........... 11
7.2. New Extensions ........................................ 11
7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV ....... 11
7.2.2. New LSP Exclusion Sub-object in the XRO .......... 12
7.2.3. SRP Extension .................................... 13
Lee & Zheng Expires August 2022 [Page 2]
Internet-Draft Stateful PCEP for GMPLS February 2022
8. Update to Error Handling .................................... 13
8.1. Error Handling in LSP Re-optimization .................. 13
8.2. Error Handling in Route Exclusion ...................... 13
8.3. Error Handling for generalized END-POINTS .............. 14
9. Implementation .............................................. 14
9.1. Huawei Technologies .................................... 14
10. IANA Considerations......................................... 15
10.1. New GMPLS-CAPABILITY .................................. 15
10.2. New Sub-object for the Exclude Route Object ........... 15
10.3. Flag Field for new XRO Sub-object ..................... 15
10.4. New "B" Flag in the SRP Object ........................ 16
10.5. New PCEP Error Codes .................................. 16
11. Manageability Considerations ............................... 16
11.1. Requirements on Other Protocols ....................... 17
12. Security Considerations .................................... 17
13. Acknowledgement ............................................ 17
14. References ................................................. 17
14.1. Normative References .................................. 17
14.2. Informative References ................................ 18
15. Contributors' Address ...................................... 19
Authors' Addresses ............................................. 21
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). Such a
PCE is usually referred as a stateless PCE. To request path
computation services to a PCE, [RFC5440] defines the PCE
communication Protocol (PCEP) for interaction between a Path
Computation Client (PCC) and a PCE, or between two PCEs. PCEP as
specified in [RFC5440] mainly focuses on MPLS networks and the PCEP
extensions needed for GMPLS-controlled networks are provided in
[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
capability of stateful PCEs, extensions to PCEP 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.
Lee & Zheng Expires August 2022 [Page 3]
Internet-Draft Stateful PCEP for GMPLS February 2022
[RFC8231] provides the fundamental extensions needed for stateful
PCE to support general functionality. 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., WSON, OTN, SONET/ SDH, etc. technologies).
This document focuses on the extensions that are necessary in order
for the deployment of stateful PCEs and the requirements for remote-
initiated LSPs in GMPLS-controlled networks. Section 3 provides
General context of Stateful PCE and PCEP for GMPLS are provided in
Section 3, and PCE initiation requirement for GMPLS is provided in
section 4. Protocol extensions are included in section 5, as a
solution to address such requirements.
2. 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.
3. General Context of Stateful PCE and PCEP for GMPLS
This section is built on the basis of Stateful PCE in [RFC8231] and
PCEP for GMPLS in [RFC8779].
The operation for Stateful PCE on LSPs can be divided into two types,
active stateful PCE and passive stateful PCE.
For active stateful PCE, a 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 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 convey
path computation instructions. GMPLS-technology specific Objects
and TLVs are defined in [RFC8779], so this document just points at
that work and only 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
Lee & Zheng Expires August 2022 [Page 4]
Internet-Draft Stateful PCEP for GMPLS February 2022
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. 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 remote-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]. This
document does not repeat 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 in section 2.1 of [RFC8779] and its extension in
this document MUST be advertised as well.
o LSP operations, including LSP update, delegation and state
synchronization/report are covered in [RFC8231]. This document
provides extensions for its application in GMPLS-controlled
networks.
o All the PCEP messages need to be capable of indicating GMPLS-
specific switching capabilities a per TE link basis. GMPLS LSP
creation/modification/deletion requires knowledge of LSP
switching capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) and
the generalized payload (G-PID) to be used according to
Lee & Zheng Expires August 2022 [Page 5]
Internet-Draft Stateful PCEP for GMPLS February 2022
[RFC3471], [RFC3473]. It also requires the specification of data
flow specific traffic parameters (also known as 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 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" in the PCEP TLV Type
Indicators. Another GMPLS-CAPABILITY TLV in the PCEP TLV Type
Indicators has been defined in [RFC8779]. According to [RFC8779],
IANA created a registry to manage the value of the GMPLS-CAPABILITY
TLV's Flag field. New bits, LSP-UPDATE-CAPABILITY (TBD1) and LSP-
INSTANTIATION-CAPABILITY (TBD2), are introduced as flags to indicate
the capability for LSP update and remote LSP initiation in GMPLS
networks.
5.2. LSP Synchronization
PCCs need to report the attributes of LSPs to the PCE to enable
stateful operation of a GMPLS network. 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 END-POINTS object is extended for GMPLS in [RFC8779]. The END-
POINTS object is carried in the PCRpt message as specified in
Lee & Zheng Expires August 2022 [Page 6]
Internet-Draft Stateful PCEP for GMPLS February 2022
[RFC8623]. The END-POINTS object type for GMPLS is included in the
PCRpt message as per the same.
The BANDWIDTH, LSPA, IRO and XRO objects are extended for GMPLS in
[RFC8779]. 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.
6. Extension of Existing PCEP Messages
This section describes how the PCEP messages are extended by using
Routing Backus-Naur Form (RBNF) [RFC5511] formats. Contents in this
section are for informative purpose.
6.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>]
Lee & Zheng Expires August 2022 [Page 7]
Internet-Draft Stateful PCEP for GMPLS February 2022
<LSP>
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]
Where:
<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]. GENERALIZED-BANDWIDTH object has been defined
in [RFC8779] to address the limitation of the BANDWIDTH object, with
supporting the following:
o Asymmetric bandwidth (different bandwidth in forward and reverse
direction), as described in [RFC6387].
o Technology specific GMPLS parameters (e.g., TSpec for SDH/SONET,
G.709, ATM, MEF, etc.).
<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.
The SRP object is OPTIONAL, and the usage is extended in the
section 7.2.3 of this document.
Lee & Zheng Expires August 2022 [Page 8]
Internet-Draft Stateful PCEP for GMPLS February 2022
6.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-
list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path>::= <intended-path><intended-attribute-list>
Where:
<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.
The SRP object is OPTIONAL, and the usage is extended in the
section 7.2.3 of this document.
6.3. The PCInitiate Message
According to [RFC8281], the PCInitiate Message is used allow
remote 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:
Lee & Zheng Expires August 2022 [Page 9]
Internet-Draft Stateful PCEP for GMPLS February 2022
<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>
The format of the PCInitiate message is unchanged from Section 5.1
of [RFC8281]. However, note the following:
o The END-POINTS object was been extended by [RFC8779] to
include a new object type called "Generalized Endpoint". A
PCInitiate message used to trigger a GMPLS LSP instantiation MUST
use that extension.
o A PCInitiate message sent by a PCE to a PCC to trigger a GMPLS
LSP instantiation MUST include the END-POINTS with Generalized
Endpoint object type (even though it is marked as optional in the
message definition.
o The END-POINTS object MUST contain a "label request" TLV per
[RFC8779]. The label request TLV is used to specify the switching
type, encoding type and G-PID of the LSP being instantiated by the
PCE.
o If unnumbered endpoint addresses are used for the LSP being
instantiated by the PCE, the unnumbered endpoint TLV [RFC8779]
MUST be use to specify the unnumbered endpoint addresses.
o The END-POINTS MAY contain other TLVs defined in [RFC8779].
Lee & Zheng Expires August 2022 [Page 10]
Internet-Draft Stateful PCEP for GMPLS February 2022
7. PCEP Object Extensions
7.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. Stateful PCEP messages MUST include the
END-POINTS with Generalized Endpoint object type, containing the
"label request" TLV.
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 ERO was not extended in [RFC8779], and not in this
document as well.
o SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of
[RFC8282] is applicable in Stateful PCEP messages for GMPLS networks.
7.2. New Extensions
7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV
In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from
the "PCEP TLV Type Indicators" sub-registry. The TLV is extended
with two flags to indicate the Stateful and remote initiate
capability.
S (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the
S flag indicates that the PCC allows modification of LSP parameters;
if set to 1 by a PCE, the S flag indicates that the PCE is capable
of updating 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.
Lee & Zheng Expires August 2022 [Page 11]
Internet-Draft Stateful PCEP for GMPLS February 2022
I (LSP-INSTANTIATION-CAPABILITY(TBD2) -- 1 bit): If set to 1 by a
PCC, the I flag indicates that the PCC allows instantiation of an
LSP by a PCE. If set to 1 by a PCE, the I flag indicates that the
PCE supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY
flag must be set by both the PCC and PCE in order to enable PCE-
initiated LSP instantiation.
7.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:
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 | Attributes | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X bit and Attribute fields are 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.
Flags: This field may be used to further specify the exclusion
constraint with regard to the LSP. Currently, no values 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].
This sub-object is OPTIONAL in the exclude route object (XRO) and
can be present multiple times. When a stateful PCE receives a PCReq
message carrying this sub-object, it MUST search for the identified
Lee & Zheng Expires August 2022 [Page 12]
Internet-Draft Stateful PCEP for GMPLS February 2022
LSP in its LSP-DB and then exclude from the new path computation all
resources used by the identified LSP.
7.2.3. SRP Extension
The format of the SRP object is defined in [RFC8231]. The object is
used in PCUpd and PCInitiate messages for GMPLS.
This document defines a new flag to be carried in the Flags field of
the SRP object. This flag indicates a bidirectional co-routed LSP
setup operation initiated by the PCE as follows:
o B (Bidirectional LSP -- 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.
The bit position is TBD4 as assigned by IANA.
8. 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-Type and Error-Value are
introduced.
8.1. 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 =
TBD5, Error value= TBD6). The PCE MAY suppress this error message
on a configurable threshold.
8.2. Error Handling in Route Exclusion
This sub-object in XRO defined in section 7.2.2 of this document is
OPTIONAL and can be present multiple times. When a stateful PCE
receives a PCReq message carrying this sub-object, it searches for
the identified LSP in its LSP-DB and then excludes from the new path
computation all resources used by the identified LSP. If the
stateful PCE cannot recognize one or more of the received LSP
identifiers, it SHOULD send an error message PCErr reporting "The
LSP state information for route exclusion purpose cannot be found"
Lee & Zheng Expires August 2022 [Page 13]
Internet-Draft Stateful PCEP for GMPLS February 2022
(Error-type = TBD5, Error-value = TBD7). Optionally, it may also
provide with the unrecognized identifier information to the
requesting PCC using the error reporting techniques described in
[RFC5440]. However, the PCE MAY suppress this error message on a
configurable threshold.
8.3. Error Handling for generalized END-POINTS
If the END-POINTS Object of type Generalized Endpoint is missing the
label request TLV, the PCC MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value= TBD8 (label
request TLV missing).
9. 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".
9.1. Huawei Technologies
o Organization: Huawei Technologies, Co. LTD
o Implementation: Huawei NCE-T
o Description: PCRpt, PCUpd and PCInitiate messages for GMPLS
Network
Lee & Zheng Expires August 2022 [Page 14]
Internet-Draft Stateful PCEP for GMPLS February 2022
o Maturity Level: Production
o Coverage: Full
o Contact: zhenghaomian@huawei.com
10. IANA Considerations
10.1. New GMPLS-CAPABILITY
[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC,
IANA created a registry to manage the value of the STATEFUL-PCE-
CAPABILITY TLV's Flag field. IANA has allocated a new bit in the
STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows:
Bit Description Reference
--- -------------------------------- -------------
TBD1 LSP-UPDATE-CAPABILITY (S) [This.I-D]
TBD2 LSP-INSTANTIATION-CAPABILITY (I) [This.I-D]
10.2. New Sub-object for the Exclude Route Object
IANA maintains the "PCEP Parameters" registry containing a
subregistry called "PCEP Objects". This registry has a subregistry
for the XRO (Exclude Route Object) listing the sub-objects that can
be carried in the XRO. IANA is requested to assign a further sub-
object that can be carried in the XRO as follows:
Value Description Reference
----------+------------------------------+-------------
TBD3 LSP Exclusion sub-object [This.I-D]
10.3. Flag Field for new XRO Sub-object
IANA has created a registry to manage the Flag field of the LSP
Exclusion sub-object in XRO object. 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]
Lee & Zheng Expires August 2022 [Page 15]
Internet-Draft Stateful PCEP for GMPLS February 2022
10.4. New "B" Flag in the SRP Object
IANA maintains a subregistry, named the "SRP Object Flag Field",
within the "Path Computation Element Protocol (PCEP) Numbers"
registry, to manage the Flag field of the SRP object.
IANA is requested to make an assignment from this registry as
follows:
Bit Description Reference
--- ---------------------------- ----------
TBD4 Bi-directional co-routed LSP [This.I-D]
10.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 Reference
TBD5 LSP state information missing [This.I-D]
Error-value TBD6: LSP state information unavailable [This.I-D]
for the LSP re-optimization
Error-value TBD7: LSP state information for route
exclusion purpose cannot be found [This.I-D]
This document defines the following new Error-Value:
Error-Type Error-Value Reference
6 Error-value TBD8: Label Request TLV
missing [This.I-D]
11. Manageability Considerations
The description and functionality specifications presented related
to stateful PCEs should also comply with the manageability
specifications covered in Section 8 of [RFC4655]. Furthermore, a
further list of manageability issues presented in [RFC8231] should
also be considered.
Lee & Zheng Expires August 2022 [Page 16]
Internet-Draft Stateful PCEP for GMPLS February 2022
11.1. Requirements on Other Protocols
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.
12. Security Considerations
This draft provides additional extensions to PCEP so as to
facilitate stateful PCE usage in GMPLS-controlled networks, on top
of [RFC8231]. The PCEP extensions to support GMPLS-controlled
networks should be considered under the same security as for MPLS
networks, as noted in [RFC7025]. Therefore, the security
considerations elaborated in [RFC5440] still apply to this draft.
Furthermore, [RFC8231] provides a detailed analysis of the
additional security issues incurred due to the new extensions and
possible solutions needed to support for the new stateful PCE
capabilities and they apply to this document as well.
13. Acknowledgement
We would like to thank Adrian Farrel, Cyril Margaria, George Swallow
and Jan Medved for the useful comments and discussions.
14. References
14.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.
Lee & Zheng Expires August 2022 [Page 17]
Internet-Draft Stateful PCEP for GMPLS February 2022
[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.
14.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.
[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.
Lee & Zheng Expires August 2022 [Page 18]
Internet-Draft Stateful PCEP for GMPLS February 2022
[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.
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 6387, September 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.
[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.
15. 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 August 2022 [Page 19]
Internet-Draft Stateful PCEP for GMPLS February 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
Lee & Zheng Expires August 2022 [Page 20]
Internet-Draft Stateful PCEP for GMPLS February 2022
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 August 2022 [Page 21]