Diff: rfc9504.original.xml

	rfc9504.original.xml	rfc9504.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [


		<!-- draft submitted in xml v3 -->

		<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
	]>	]>


	<?rfc toc="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<?rfc tocompact="yes"?>	-ietf-pce-pcep-stateful-pce-gmpls-23" number="9504" submissionType="IETF" catego
	<?rfc tocdepth="3"?>	ry="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true
	<?rfc tocindent="yes"?>	" tocDepth="3" symRefs="true" sortRefs="true" version="3">
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-pce-pcep-stateful-pce-gmpls-23" category="std" obsoletes="" updates="" sub
	missionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" s
	ortRefs="true" version="3">

	<front>	<front>


	<title abbrev="Stateful PCEP for GMPLS">Path Computation Element Communicati	<title abbrev="Stateful PCEP for GMPLS">Path Computation Element Communicati
	on Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-controlled Network	on Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Network
	s</title>	s</title>
		<seriesInfo name="RFC" value="9504"/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-stateful-pce-gm
	pls-23"/>

	<author fullname="Young Lee" initials="Y." surname="Lee">	<author fullname="Young Lee" initials="Y." surname="Lee">
	<organization>Samsung</organization>	<organization>Samsung</organization>
	<address>	<address>
	<email>younglee.tx@gmail.com</email>	<email>younglee.tx@gmail.com</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Haomian Zheng" initials="H." surname="Zheng">	<author fullname="Haomian Zheng" initials="H." surname="Zheng">
	<organization>Huawei Technologies</organization>	<organization>Huawei Technologies</organization>
	<address>	<address>

	skipping to change at line 58 ¶	skipping to change at line 52 ¶
	<email>victor.lopez@nokia.com</email>	<email>victor.lopez@nokia.com</email>
	</address>	</address>
	</author>	</author>

	<author fullname="Zafar Ali" initials="Z." surname="Ali">	<author fullname="Zafar Ali" initials="Z." surname="Ali">
	<organization>Cisco</organization>	<organization>Cisco</organization>
	<address>	<address>
	<email>zali@cisco.com</email>	<email>zali@cisco.com</email>
	</address>	</address>
	</author>	</author>

		<date year="2023" month="December"/>
	<date month="" year="2023"/>	<area>rtg</area>
		<workgroup>pce</workgroup>
	<area>Routing Area</area>

	<workgroup>PCE Working Group</workgroup>

	<keyword>Stateful PCE</keyword>	<keyword>Stateful PCE</keyword>
	<keyword>GMPLS</keyword>	<keyword>GMPLS</keyword>
	<keyword>PCE-initiated LSP</keyword>	<keyword>PCE-initiated LSP</keyword>

	<abstract>	<abstract>

	<t>The PCE communication Protocol (PCEP) has been extended to support stat	<t>The Path Computation Element Communication Protocol (PCEP) has been ext
	eful PCE	ended to support stateful PCE
	functions where the Stateful PCE maintains information about paths and	functions where the stateful PCE maintains information about paths and
	resource	resource
	usage within a network, but these extensions do not cover all requireme	usage within a network; however, these extensions do not cover all requ
	nts for	irements for
	GMPLS networks.</t>	GMPLS networks.</t>

	<t>This document provides the extensions required for PCEP so as to enable the usage	<t>This document provides the extensions required for PCEP so as to enable the usage
	of a stateful PCE capability in GMPLS-controlled networks.</t>	of a stateful PCE capability in GMPLS-controlled networks.</t>

	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="intro">	<section anchor="intro">
	<name>Introduction</name>	<name>Introduction</name>


	<t><xref target="RFC4655" /> presents the architecture of a Path Computati	<t><xref target="RFC4655" /> presents the architecture of a PCE-based mode
	on Element	l for computing Multiprotocol Label Switching (MPLS) and Generalized
	(PCE)-based model for computing Multiprotocol Label Switching (MPLS) and G
	eneralized
	MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perfo rm such a	MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perfo rm such a
	constrained computation, a PCE stores the network topology (i.e., TE links and nodes)	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	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. <xref target="RFC54 40" />	only maintains a TED is referred to as a "stateless PCE". <xref target="R FC5440" />
	describes the Path Computation Element Communication Protocol (PCEP) for i nteraction	describes the Path Computation Element Communication Protocol (PCEP) for i nteraction

	between a Path Computation Client (PCC) and a PCE, or between two PCEs, en abling	between a Path Computation Client (PCC) and a PCE or between two PCEs, ena bling
	computation of TE LSPs. PCEP is further extended to support GMPLS-control led networks	computation of TE LSPs. PCEP is further extended to support GMPLS-control led networks
	as per <xref target="RFC8779" />.</t>	as per <xref target="RFC8779" />.</t>

	<t>Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS	<t>Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS
	and GMPLS networks, as illustrated in <xref target="RFC8051" />. Further discussion	and GMPLS networks, as illustrated in <xref target="RFC8051" />. Further discussion

	of concept of a stateful PCE can be found in <xref target="RFC7399" />. I	of the concept of a stateful PCE can be found in <xref target="RFC7399" />
	n order for	. In order for
	these applications to able to exploit the capability of stateful PCEs, ext	these applications to be able to exploit the capability of stateful PCEs,
	ensions to	extensions to
	stateful PCEP for GMPLS are required.</t>	stateful PCEP for GMPLS are required.</t>


	<t><xref target="RFC8051" /> describes how a stateful PCE can be applicabl e to solve	<t><xref target="RFC8051" /> describes how a stateful PCE can be applied t o solve
	various problems for MPLS-TE and GMPLS networks and the benefits it brings to such	various problems for MPLS-TE and GMPLS networks and the benefits it brings to such
	deployments.</t>	deployments.</t>

	<t><xref target="RFC8231" /> specifies a set of extensions to PCEP to enab le stateful	<t><xref target="RFC8231" /> specifies a set of extensions to PCEP to enab le stateful

	control of TE LSPs where they are configured on the PCC, and control over them could	control of TE LSPs where they are configured on the PCC and control over t hem could
	be delegated to the PCE. Furthermore, <xref target="RFC8281" /> describes the setup	be delegated to the PCE. Furthermore, <xref target="RFC8281" /> describes the setup
	and teardown of PCE-initiated LSPs under the active stateful PCE model, wi thout the	and teardown of PCE-initiated LSPs under the active stateful PCE model, wi thout the
	need for local configuration on the PCC. However, both documents omit the specification	need for local configuration on the PCC. However, both documents omit the specification

	for technology-specific objects/TLVs, and do not cover GMPLS-controlled ne tworks (e.g.,	for technology-specific objects and TLVs, and they do not cover GMPLS-cont rolled networks (e.g.,
	Wavelength Switched Optical Network (WSON), Optical Transport Network (OTN ), Synchronous	Wavelength Switched Optical Network (WSON), Optical Transport Network (OTN ), Synchronous

	Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), etc. technolo gies).</t>	Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)).</t>

	<t>This document focuses on the extensions that are necessary in order for the deployment	<t>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-cont rolled networks.	of stateful PCEs and the requirements for PCE-initiated LSPs in GMPLS-cont rolled networks.

	<xref target="context" /> provides a general context of the usage of State	<xref target="context" /> provides a general context of the usage of state
	ful PCE and PCEP for GMPLS.	ful PCEs and PCEP for GMPLS.
	The various requirements for stateful GMPLS, including PCE-initiation for	The various requirements for stateful GMPLS, including PCE initiation for
	GMPLS LSPs,	GMPLS LSPs,
	are provided in <xref target="reqs" />. An overview of the PCEP extensions	are provided in <xref target="reqs" />. An overview of the PCEP extensions
	is specified in <xref target="overview" />,	is specified in <xref target="overview" />.
	and a solution to address such requirements with PCEP object extensions in	A solution to address such requirements with PCEP object extensions is spe
	<xref target="objs" />.</t>	cified in <xref target="objs" />.</t>

	<section anchor="conventions">	<section anchor="conventions">

	<name>Conventions Used in this Document</name>	<name>Conventions Used in This Document</name>
		<t>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"SHOULD",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" i	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	n this document	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	are to be interpreted as described in BCP 14 <xref target="RFC2119" />	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	<xref target="RFC8174" />	be interpreted as
	when, and only when, they appear in all capitals, as shown here.</t>	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>

	</section>	</section>

	</section>	</section>

	<section anchor="terms">	<section anchor="terms">
	<name>Terminology</name>	<name>Terminology</name>

	<t>Terminology used in this document is the same as terminology used in <x ref target="RFC5440" />,	<t>Terminology used in this document is the same as terminology used in <x ref target="RFC5440" />,
	<xref target="RFC8231" />, <xref target="RFC8281" />, and <xref target="RF C8779" />.</t>	<xref target="RFC8231" />, <xref target="RFC8281" />, and <xref target="RF C8779" />.</t>

	</section>	</section>

	<section anchor="context">	<section anchor="context">
	<name>General Context of Stateful PCE and PCEP for GMPLS</name>	<name>General Context of Stateful PCE and PCEP for GMPLS</name>


	<t>This section is built on the basis of Stateful PCE specified in <xref t arget="RFC8231" /> and PCEP	<t>This section is built on the basis of stateful PCEs specified in <xref target="RFC8231" /> and PCEP
	for GMPLS specified in <xref target="RFC8779" />.</t>	for GMPLS specified in <xref target="RFC8779" />.</t>


	<t>The operation for Stateful PCE on LSPs can be divided into two types, a	<t>The operation of a stateful PCE on LSPs can be divided into two types:
	ctive stateful PCE and	active stateful PCE and
	passive stateful PCE as described in <xref target="RFC8051" />.</t>	passive stateful PCE (as described in <xref target="RFC8051" />).</t>
		<ul>
	<t>For active stateful PCE, a Path Computation Update Request (PCUpd) mes	<li>For active stateful PCEs, a Path Computation Update Request (PCUpd) m
	sage is sent from PCE to	essage is sent from the PCE to
	PCC to update the LSP state for the LSPs delegated to the PCE. Any changes	the PCC to update the LSP state for the LSPs delegated to the PCE. Any cha
	to the delegated LSPs	nges to the delegated LSPs
	generate a Path Computation State Report (PCRpt) message from the PCC to P	generate a Path Computation State Report (PCRpt) message from the PCC to t
	CE to convey the changes	he PCE to convey the changes
	of the LSPs. Any modifications to the Objects/TLVs that are identified in	of the LSPs. Any modifications to the objects and TLVs that are identified
	this document to support	in this document to support
	GMPLS technology-specific attributes will be carried in the PCRpt and PCUp	GMPLS-specific attributes will be carried in the PCRpt and PCUpd messages.
	d messages.</t>	</li>


	<t>For passive stateful PCEs, Path Computation Request (PCReq)/ Path Compu	<li>For passive stateful PCEs, Path Computation Request (PCReq) and Path C
	tation Reply (PCRep)	omputation Reply (PCRep)
	messages are used to request for path computation. GMPLS-technology specif	messages are used to request path computation. GMPLS-specific objects and
	ic Objects and TLVs are	TLVs are
	defined in <xref target="RFC8779" />, this document builds on it and adds	defined in <xref target="RFC8779" />, which this document builds on and ad
	the stateful PCE aspects	ds the stateful PCE aspects
	where applicable. Passive Stateful PCE makes use of PCRpt messages when re	where applicable. A passive stateful PCE makes use of PCRpt messages when
	porting LSP State changes	reporting LSP state changes
	sent by PCCs to PCEs. Any modifications to the Objects/TLVs that are iden	sent by PCCs to PCEs. Any modifications to the objects and TLVs that are
	tified in this document	identified in this document
	to support GMPLS technology-specific attributes will be carried in the PCR	to support GMPLS-specific attributes will be carried in the PCRpt message.
	pt message.</t>	</li></ul>

	<t>Furthermore, the LSP Initiation function of PCEP is defined in <xref ta rget="RFC8281" /> to allow	<t>Furthermore, the LSP Initiation function of PCEP is defined in <xref ta rget="RFC8281" /> to allow
	the PCE to initiate LSP establishment after the path is computed. An LSP I nitiate Request (PCInitiate)	the PCE to initiate LSP establishment after the path is computed. An LSP I nitiate Request (PCInitiate)

	message is used to trigger the end node to set up the LSP. Any modificatio	message is used to trigger the end node to set up the LSP. Any modificatio
	ns to the Objects/TLVs that	ns to the objects and TLVs that
	are identified in this document to support GMPLS technology-specific attri	are identified in this document to support GMPLS-specific attributes will
	butes will be carried in the	be carried in the
	PCInitiate messages.</t>	PCInitiate messages.</t>


	<t><xref target="RFC8779" /> defines GMPLS-technology specific Objects/TLV	<t><xref target="RFC8779" /> defines GMPLS-specific objects and TLVs in st
	s in stateless PCEP, and this	ateless PCEP; this
	document makes use of these Objects/TLVs without modifications where appli	document makes use of these objects and TLVs without modifications where a
	cable. Where these Objects/TLVs	pplicable. Where these objects and TLVs
	require modifications to incorporate stateful PCE, they are described in t	require modifications to incorporate stateful PCEs, they are described in
	his document. PCE-Initiated	this document. PCE-initiated
	LSPs follow the principle specified in <xref target="RFC8281" />, and the GMPLS-specific extensions are	LSPs follow the principle specified in <xref target="RFC8281" />, and the GMPLS-specific extensions are
	also included in this document.</t>	also included in this document.</t>

	</section>	</section>

	<section anchor="reqs">	<section anchor="reqs">
	<name>Main Requirements</name>	<name>Main Requirements</name>


	<t>This section notes the main functional requirements for PCEP extensions to support stateful PCE for	<t>This section notes the main functional requirements for PCEP extensions to support stateful PCEs for
	use in GMPLS-controlled networks, based on the description in <xref target ="RFC8051" />. Many	use in GMPLS-controlled networks, based on the description in <xref target ="RFC8051" />. Many
	requirements are common across a variety of network types (e.g., MPLS-TE n etworks and GMPLS networks)	requirements are common across a variety of network types (e.g., MPLS-TE n etworks and GMPLS networks)

	and the protocol extensions to meet the requirements are already described	and the protocol extensions to meet the requirements are already described
	in <xref target="RFC8231" />,	in <xref target="RFC8231" />
	such as LSP update, delegation and state synchronization/report. Protecti	(such as LSP update, delegation, and state synchronization/report). Prote
	on context information that	ction context information that
	describes the GMPLS requirement can also follow the description in <xref t arget="RFC8745" />. This	describes the GMPLS requirement can also follow the description in <xref t arget="RFC8745" />. This
	document does not repeat the description of those protocol extensions. Th is document presents protocol	document does not repeat the description of those protocol extensions. Th is document presents protocol

	extensions for a set of requirements which are specific to the use of a st ateful PCE in a GMPLS-controlled	extensions for a set of requirements that are specific to the use of a sta teful PCE in a GMPLS-controlled
	network.</t>	network.</t>


	<t>The requirements for GMPLS-specific stateful PCE are as follows:</t>	<t>The requirements for GMPLS-specific stateful PCEs are as follows:</t>

	<ul>


	<li>Advertisement of the stateful PCE capability. This generic requi	<ul spacing="normal">
	rement is covered in	<li>Advertisement of the stateful PCE capability. This generic
	Section 5.4 of <xref target="RFC8231" />. The GMPLS-CAPABILITY TLV sp	requirement is covered in <xref target="RFC8231" sectionFormat="of"
	ecified in section 2.1 of	section="5.4"/>. The GMPLS-CAPABILITY TLV specified in <xref
	<xref target="RFC8779" /> and its extension in this document needs to	target="RFC8779" sectionFormat="of" section="2.1"/> and its
	be advertised as well. </li>	extension in this document need to be advertised as well. </li>


	<li>All the PCEP messages need to be capable of indicating GMPLS-spec	<li>All the PCEP messages need to be capable of indicating
	ific switching capabilities.	GMPLS-specific switching capabilities. GMPLS LSP
	GMPLS LSP creation/modification/deletion requires knowledge of LSP sw	creation, modification, and deletion require knowledge of LSP switchi
	itching capability (e.g.,	ng
	Time-Division Multiplex Capable (TDM), Layer 2 Switch Capable (L2SC),	capabilities (e.g., Time-Division Multiplex Capable (TDM), Layer 2
	OTN-TDM, Lambda Switch	Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.)
	Capable (LSC), etc.) and the generalized payload (G-PID) to be used a	and the Generalized Payload Identifier (G-PID) to be used according t
	ccording to	o <xref
	<xref target="RFC3471" />, <xref target="RFC3473" />. It also require	target="RFC3471" /> and <xref target="RFC3473" />. It also requires
	s the specification of	that traffic parameters that are both data flow and technology specific be defin
	data flow specific traffic parameters (also known as Traffic Specific	ed. These traffic parameters are also known as "Traffic Specification" or "Tspec
	ation (Tspec)), which	". Such information would need to be included in various
	are technology specific. Such information would need to be included i	PCEP messages.</li>
	n various PCEP messages.</li>


	<li>In some technologies, path calculation is tightly coupled with la	<li>In some technologies, path calculation is tightly coupled with
	bel selection along the route.	label selection along the route. For example, path calculation in
	For example, path calculation in a Wavelength Division Multiplexing (	a Wavelength Division Multiplexing (WDM) network may include lambda
	WDM) network may include lambda	continuity and/or lambda feasibility constraints; hence, a path
	continuity and/or lambda feasibility constraints and hence a path com	computed by the PCE is associated with a specific lambda (label).
	puted by the PCE is associated	Thus, in such networks, the label information needs to be provided
	with a specific lambda (label). Hence, in such networks, the label i	to a PCC in order for a PCE to initiate GMPLS LSPs under the active
	nformation needs to be provided	stateful PCE model, i.e., Explicit Label Control (ELC) may be
	to a PCC in order for a PCE to initiate GMPLS LSPs under the active s	required.</li>
	tateful PCE model, i.e.,
	explicit label control may be required.</li>


	<li>Stateful PCEP messages also need to indicate the protection conte	<li>Stateful PCEP messages also need to indicate the protection
	xt information for the LSP	context information for the LSP specified by GMPLS, as defined in
	specified by GMPLS, as defined in <xref target="RFC4872" />, <xref ta	<xref target="RFC4872" /> and <xref target="RFC4873" />.</li>
	rget="RFC4873" />.</li>

	</ul>	</ul>

	</section>	</section>

	<section anchor="overview">	<section anchor="overview">
	<name>Overview of Stateful PCEP Extensions for GMPLS Networks</name>	<name>Overview of Stateful PCEP Extensions for GMPLS Networks</name>

	<section anchor="capadv">	<section anchor="capadv">
	<name>Capability Advertisement for Stateful PCEP in GMPLS</name>	<name>Capability Advertisement for Stateful PCEP in GMPLS</name>


	<t>Capability Advertisement has been specified in <xref target="RFC8231"	<t>Capability advertisement is specified in <xref target="RFC8231" />; i
	/>, and can be achieved by using	t can be achieved by using
	the "STATEFUL-PCE-CAPABILITY TLV" in the Open message. Another GMPLS-CAP	the STATEFUL-PCE-CAPABILITY TLV in the Open message. Another GMPLS-CAPAB
	ABILITY TLV has been defined in	ILITY TLV is defined in
	<xref target="RFC8779" />. A subregistry to manage the Flag field of th	<xref target="RFC8779" />. A subregistry to manage the Flag field of th
	e GMPLS-CAPABILITY TLV is created	e GMPLS-CAPABILITY TLV has been created by IANA as requested by <xref target="RF
	by the IANA as requested by <xref target="RFC8779" />. The following bi	C8779" />. The following bits are introduced by this document
	ts are introduced by this document	in the GMPLS-CAPABILITY TLV as flags to indicate the capability for LSP
	in the GMPLS-CAPABILITY TLV as flags to indicate the capability for LSP	report, update, and initiation in
	report, update and initiation in	GMPLS networks: LSP-REPORT-CAPABILITY (31), LSP-UPDATE-CAPABILITY (30),
	GMPLS networks: LSP-REPORT-CAPABILITY(TBDa), LSP-UPDATE-CAPABILITY (TBD1	and LSP-INSTANTIATION-CAPABILITY (29). </t>
	), and LSP-INSTANTIATION-CAPABILITY
	(TBD2). </t>

	</section>	</section>

	<section anchor="lspsync">	<section anchor="lspsync">
	<name>LSP Synchronization</name>	<name>LSP Synchronization</name>

	<t>After the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a	<t>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 computa tions or update LSP attributes in	PCC's LSPs (including its attributes) before it can perform path computa tions or update LSP attributes in

	a PCC. This process is known as LSP state synchronization. The LSP attr ibutes including bandwidth,	a PCC. This process is known as "LSP state synchronization". The LSP at tributes, including bandwidth,
	associated route, and protection information etc., are stored by the PCE in the LSP database (LSP-DB).	associated route, and protection information etc., are stored by the PCE in the LSP database (LSP-DB).
	Note that, as described in <xref target="RFC8231" />, the LSP state sync hronization covers both the bulk	Note that, as described in <xref target="RFC8231" />, the LSP state sync hronization covers both the bulk

	reporting of LSPs at initialization as well the reporting of new or modi	reporting of LSPs at initialization as well as the reporting of new or m
	fied LSPs during normal operation.	odified LSPs during normal operation.
	Incremental LSP-DB synchronization may be desired in a GMPLS-controlled	Incremental LSP-DB synchronization may be desired in a GMPLS-controlled
	network and it is specified in	network; it is specified in
	<xref target="RFC8232" />.</t>	<xref target="RFC8232" />.</t>

	<t>The format of the PCRpt message is specified in <xref target="RFC8231 " /> and extended in	<t>The format of the PCRpt message is specified in <xref target="RFC8231 " /> and extended in
	<xref target="RFC8623" /> to include the END-POINTS object. The END-POIN TS object is extended for	<xref target="RFC8623" /> to include the END-POINTS object. The END-POIN TS object is extended for
	GMPLS in <xref target="RFC8779" />. The END-POINTS object can be carried in the PCRpt message as	GMPLS in <xref target="RFC8779" />. The END-POINTS object can be carried in the PCRpt message as
	specified in <xref target="RFC8623" />. The END-POINTS object type for G MPLS is included in the PCRpt	specified in <xref target="RFC8623" />. The END-POINTS object type for G MPLS is included in the PCRpt
	message as per the same. </t>	message as per the same. </t>


	<t>The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and	<t>The following objects are extended for GMPLS in <xref
	Exclude Route Object (XRO)	target="RFC8779" /> and are also used in the PCRpt in the same
	objects are extended for GMPLS in <xref target="RFC8779" /> and are also	manner: BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO), an
	used in the PCRpt in the same	d Exclude Route Object (XRO). These objects are carried in the PCRpt message as
	manner. These objects are carried in the PCRpt message as specified in <	specified in
	xref target="RFC8231" /> (as the	<xref target="RFC8231" /> (as the attribute-list defined in <xref
	attribute-list defined in Section 6.5 of <xref target="RFC5440" /> and	target="RFC5440" sectionFormat="of" section="6.5"/> and extended by
	extended by many other documents	many other documents that define PCEP extensions for specific
	that define PCEP extensions for specific scenarios). </t>	scenarios). </t>


	<t>The SWITCH-LAYER object is defined in <xref target="RFC8282" />. This	<t>The SWITCH-LAYER object is defined in <xref target="RFC8282"
	object is carried in PCRpt	/>. This object is carried in the PCRpt message as specified in <xref
	message as specified in section 3.2 of <xref target="RFC8282" />.</t>	target="RFC8282" sectionFormat="of" section="3.2"/>.</t>

	</section>	</section>

	<section anchor="delnclean">	<section anchor="delnclean">
	<name>LSP Delegation and Cleanup</name>	<name>LSP Delegation and Cleanup</name>


	<t>LSP delegation and cleanup procedure specified in <xref target="RFC82 31" /> are equally applicable	<t>The LSP delegation and cleanup procedure specified in <xref target="R FC8281" /> are equally applicable
	to GMPLS LSPs and this document does not modify the associated usage.</t >	to GMPLS LSPs and this document does not modify the associated usage.</t >

	</section>	</section>

	<section anchor="lspops">	<section anchor="lspops">
	<name>LSP Operations</name>	<name>LSP Operations</name>

	<t>Both passive and active stateful PCE mechanisms in <xref target="RFC8 231" /> are applicable in	<t>Both passive and active stateful PCE mechanisms in <xref target="RFC8 231" /> are applicable in
	GMPLS-controlled networks. Remote LSP Initiation in <xref target="RFC828 1" /> is also applicable in	GMPLS-controlled networks. Remote LSP Initiation in <xref target="RFC828 1" /> is also applicable in
	GMPLS-controlled networks.</t>	GMPLS-controlled networks.</t>

	</section>	</section>

	</section>	</section>

	<section anchor="objs">	<section anchor="objs">
	<name>PCEP Object Extensions</name>	<name>PCEP Object Extensions</name>

	<section anchor="exist">	<section anchor="exist">

	<name>Existing Extensions used for Stateful GMPLS</name>	<name>Existing Extensions Used for Stateful GMPLS</name>


	<t>Existing extensions defined in <xref target="RFC8779" /> can be used in Stateful PCEP with no	<t>Existing extensions defined in <xref target="RFC8779" /> can be used in stateful PCEP with no
	or slight changes for GMPLS network control, including the following: </ t>	or slight changes for GMPLS network control, including the following: </ t>


	<ul>	<dl spacing="normal" newline="false">
		<dt>END-POINTS:</dt>
	<li>END-POINTS: Generalized END-POINTS was specified in <xref target="	<dd><t>The END-POINTS object was specified in <xref target="RFC8779"
	RFC8779" /> to include	/> to include GMPLS capabilities. All stateful PCEP messages
	GMPLS capabilities. All Stateful PCEP messages MUST include the END-PO	<bcp14>MUST</bcp14> include the END-POINTS object with Generalized Endp
	INTS with Generalized	oint
	Endpoint object type, containing the LABEL-REQUEST TLV. Further note	object type, containing the LABEL-REQUEST TLV. Further note
	that:</li>	that:</t>
		<ul spacing="normal">
	<li><ul>	<li>As per <xref target="RFC8779" />, for stateless GMPLS path
		computation, the Generalized END-POINTS object may contain a
	<li>As per <xref target="RFC8779" /> for stateless GMPLS path comput	LABEL-REQUEST and/or LABEL-SET TLV. In this document, only the
	ation, the Generalized	LABEL-REQUEST TLV is used to specify the switching type, encoding
	END-POINTS object may contain a LABEL-REQUEST and/or LABEL-SET TLV.	type, and G-PID of the LSP. </li>
	In this document, only	<li>If unnumbered endpoint addresses are used for the LSP, the
	the LABEL-REQUEST TLV is used to specify the switching type, encodin	UNNUMBERED-ENDPOINT TLV <xref target="RFC8779" />
	g type and G-PID of the	<bcp14>MUST</bcp14> be used to specify the unnumbered endpoint
	LSP. </li>	addresses.</li>
		<li>The Generalized END-POINTS object <bcp14>MAY</bcp14> contain oth
	<li>If unnumbered endpoint addresses are used for the LSP, the UNNUM	er
	BERED-ENDPOINT TLV	TLVs defined in <xref target="RFC8779" />.</li>
	<xref target="RFC8779" /> MUST be used to specify the unnumbered end	</ul></dd>
	point addresses.</li>	<dt>RP:</dt>
		<dd>The Request Parameter (RP) object extension (together with the Routing Gra
	<li>The Generalized END-POINTS MAY contain other TLVs defined in <xr	nularity (RG)
	ef target="RFC8779" />.</li>	flag defined in <xref target="RFC8779" />) is applicable in
		stateful PCEP for GMPLS networks. </dd>
	</ul></li>	<dt>BANDWIDTH:</dt>
		<dd>Generalized BANDWIDTH is specified in <xref target="RFC8779" />
	<li>RP: RP object extension, together with the Routing Granularity (RG	to represent GMPLS features, including asymmetric bandwidth and
	) flag defined in	G-PID information. </dd>
	<xref target="RFC8779" />, are applicable in the Stateful PCEP for GMP	<dt>LSPA:</dt>
	LS networks. </li>	<dd>LSPA Extensions in <xref target="RFC8779" sectionFormat="of"
		section="2.8"/> are applicable in stateful PCEP for GMPLS
	<li>BANDWIDTH: Generalized BANDWIDTH was specified in <xref target="RF	networks. </dd>
	C8779" /> to represent	<dt>IRO:</dt>
	GMPLS features, including asymmetric bandwidth and G-PID information.	<dd>IRO Extensions in <xref target="RFC8779" sectionFormat="of"
	</li>	section="2.6"/> are applicable in stateful PCEP for GMPLS
		networks.</dd>
	<li>LSPA: LSPA Extensions in Section 2.8 of <xref target="RFC8779" />	<dt>XRO:</dt>
	is applicable in Stateful	<dd>XRO Extensions in <xref target="RFC8779" sectionFormat="of"
	PCEP for GMPLS networks. </li>	section="2.7"/> are applicable in stateful PCEP for GMPLS networks. A
		new flag is defined in <xref target="flags" /> of this
	<li>IRO: IRO Extensions in Section 2.6 of <xref target="RFC8779" /> is	document.</dd>
	applicable in Stateful	<dt>ERO:</dt>
	PCEP for GMPLS networks.</li>	<dd>The Explicit Route Object (ERO) is not extended in <xref
		target="RFC8779" />, nor is it in this document.</dd>
	<li>XRO: XRO Extensions in Section 2.7 of <xref target="RFC8779" /> is	<dt>SWITCH-LAYER:</dt>
	applicable in Stateful	<dd>The SWITCH-LAYER definition in <xref target="RFC8282"
	PCEP for GMPLS networks. A new flag is defined in <xref target="flags"	sectionFormat="of" section="3.2"/> is applicable in stateful PCEP
	/> of this document. </li>	messages for GMPLS networks.</dd>
		</dl>
	<li>ERO: The Explicit Route Object (ERO) was not extended in <xref tar
	get="RFC8779" />, nor is
	it in this document. </li>

	<li>SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of <xref t
	arget="RFC8282" /> is
	applicable in Stateful PCEP messages for GMPLS networks.</li>

	</ul>

	</section>	</section>

	<section anchor="new">	<section anchor="new">
	<name>New Extensions</name>	<name>New Extensions</name>

	<section anchor="captlv">	<section anchor="captlv">
	<name>GMPLS-CAPABILITY TLV in OPEN Object</name>	<name>GMPLS-CAPABILITY TLV in OPEN Object</name>


	<t>In <xref target="RFC8779" />, IANA has allocated value 45 (GMPLS-CA	<t>In <xref target="RFC8779" />, IANA allocates value 45
	PABILITY) from the	(GMPLS-CAPABILITY) from the "PCEP TLV Type Indicators" subregistry.
	"PCEP TLV Type Indicators" sub-registry. The specifcation add three f	This specification adds three flags to the Flag field of this TLV to
	lags to the flag field of this TLV to indicate	indicate the Report, Update, and Initiation capabilities.</t>
	the Report, Update, and Initiation capabilities.</t>	<dl newline="true" spacing="normal">
		<dt>R (LSP-REPORT-CAPABILITY (31) -- 1 bit):</dt>
	<t>R (LSP-REPORT-CAPABILITY(TBDa) -- 1 bit): if set to 1 by a PCC, the	<dd>If set to 1 by a PCC, the R flag indicates that the PCC is
	R flag indicates that	capable of reporting the current state of a GMPLS LSP whenever
	the PCC is capable of reporting the current state of a GMPLS LSP, when	there's a change to the parameters or operational status of the
	ever there's a change	GMPLS LSP. If set to 1 by a PCE, the R flag indicates that the PCE
	to the parameters or operational status of the GMPLS LSP; if set to 1	is interested in receiving GMPLS LSP State Reports whenever there
	by a PCE, the R Flag	is a parameter or operational status change to the LSP. The
	indicates that the PCE is interested in receiving GMPLS LSP State Repo	LSP-REPORT-CAPABILITY flag must be advertised by both a PCC and a
	rts whenever there is	PCE for PCRpt messages to be allowed on a PCEP session for GMPLS
	a parameter or operational status change to the LSP. The LSP-REPORT-C	LSP.</dd>
	APABILITY flag must be	<dt>U (LSP-UPDATE-CAPABILITY (30) -- 1 bit):</dt>
	advertised by both a PCC and a PCE for PCRpt messages to be allowed on	<dd>If set to 1 by a PCC, the U flag indicates that the PCC allows
	a PCEP session for	modification of GMPLS LSP parameters. If set to 1 by a PCE, the U
	GMPLS LSP.</t>	flag indicates that the PCE is capable of updating GMPLS LSP
		parameters. The LSP-UPDATE-CAPABILITY flag must be advertised by
	<t>U (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the	both a PCC and a PCE for PCUpd messages to be allowed on a PCEP
	U flag indicates that	session for GMPLS LSP.</dd>
	the PCC allows modification of GMPLS LSP parameters; if set to 1 by a	<dt>I (LSP-INSTANTIATION-CAPABILITY (29) -- 1 bit):</dt>
	PCE, the U flag indicates	<dd>If set to 1 by a PCC, the I flag indicates that the PCC allows
	that the PCE is capable of updating GMPLS LSP parameters. The LSP-UPD	instantiation of a GMPLS LSP by a PCE. If set to 1 by a PCE, the
	ATE-CAPABILITY flag must	I flag indicates that the PCE supports instantiating GMPLS LSPs.
	be advertised by both a PCC and a PCE for PCUpd messages to be allowed	The LSP-INSTANTIATION-CAPABILITY flag must be set by both the PCC
	on a PCEP session for	and PCE in order to enable PCE-initiated LSP
	GMPLS LSP.</t>	instantiation.</dd></dl>

	<t>I (LSP-INSTANTIATION-CAPABILITY(TBD2) -- 1 bit): If set to 1 by a P
	CC, 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-INS
	TANTIATION-CAPABILITY
	flag must be set by both the PCC and PCE in order to enable PCE-initia
	ted LSP instantiation.</t>

	</section>	</section>

	<section anchor="exclusion">	<section anchor="exclusion">

	<name>New LSP Exclusion Sub-object in the XRO</name>	<name>New LSP Exclusion Subobject in the XRO</name>

	<t><xref target="RFC5521" /> defines a mechanism for a PCC to request or demand that	<t><xref target="RFC5521" /> defines a mechanism for a PCC to request or demand that

	specific nodes, links, or other network resources are excluded from pa ths computed by	specific nodes, links, or other network resources be excluded from pat hs computed by
	a PCE. A PCC may wish to request the computation of a path that avoid s all links and	a PCE. A PCC may wish to request the computation of a path that avoid s all links and
	nodes traversed by some other LSP.</t>	nodes traversed by some other LSP.</t>


	<t>To this end this document defines a new sub-object for use with rou	<t>To this end, this document defines a new subobject for use with rou
	te exclusion defined	te exclusion defined
	in <xref target="RFC5521" />. The LSP exclusion sub-object is as foll	in <xref target="RFC5521" />. The LSP Exclusion subobject is as follo
	ows:</t>	ws:</t>

	<figure anchor="lspexcl-fig" title="New LSP Exclusion Sub-object Forma
	t">
	<artwork>
	<![CDATA[
	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 //
	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]>
	</artwork>
	</figure>

	<t>X: Same as the X-bit defined in the XRO sub-objects in Section 2.1.
	1 of
	<xref target="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.". </t>

	<t>Type: Sub-object Type for an LSP exclusion sub-object. Value of TBD
	3. To be assigned by IANA. </t>


	<t>Length: The Length contains the total length of the sub-object in b	<figure anchor="lspexcl-fig" title="New LSP Exclusion Subobject Format">
	ytes, including the	<artwork><![CDATA[
	Type and Length fields. </t>	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 (11) \| Length \| Reserved \| Flags \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| \|
		// Symbolic Path Name //
		\| \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		]]></artwork>
		</figure>


	<t>Reserved: MUST be set to zero on transmission and ignored on receip	<dl newline="false" spacing="normal">
	t.</t>	<dt>X:</dt>
		<dd><t>This field is the same as the X-bit defined in the XRO subobjects
		in <xref
		target="RFC5521" sectionFormat="of" section="2.1.1"/> where it says:</t>


	<t>Flags: This field may be used to further specify the exclusion cons	<!--Begin DNE - direct quote blockquote not available in dd tags yet (see https:
	traint with regard	//github.com/ietf-tools/xml2rfc/issues/570. -->
	to the LSP. Currently, no flags are defined.</t>	<t indent="3">The X-bit indicates whether the exclusion is mandatory or d
		esired. 0
		indicates that the resource specified <bcp14>MUST</bcp14> be excluded
		from the path computed by the PCE. 1 indicates that the resource
		specified <bcp14>SHOULD</bcp14> be excluded from the path computed by
		the PCE, but <bcp14>MAY</bcp14> be included subject to PCE policy and
		the absence of a viable path that meets the other constraints and
		excludes the resource.</t></dd>


	<t>Symbolic Path Name: This is the identifier given to an LSP. Its syn	<!--End DNE-->
	tax and semantics
	are identical to those of the Symbolic Path Name field defined in Sect
	ion 7.3.2 of
	<xref target="RFC8231" /> where it says: "symbolic name for the LSP, u
	nique in the PCC.
	It SHOULD be a string of printable ASCII characters, without a NULL te
	rminator." 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 matchi
	ng 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/PC
	C could be excluded.</t>


	<t>This sub-object MAY be present multiple times in the exclude route	<dt>Type:</dt>
	object (XRO) to exclude	<dd>The subobject type for an LSP Exclusion subobject. Value of 11.</dd>
	resources from multiple LSPs. When a stateful PCE receives a PCReq me	<dt>Length:</dt>
	ssage carrying this	<dd>The Length contains the total length of the subobject in bytes,
	sub-object, it MUST search for the identified LSP in its LSP-DB and th	including the Type and Length fields.</dd>
	en exclude from the	<dt>Reserved:</dt>
	new path computation all resources used by the identified LSP.</t>	<dd>Reserved <bcp14>MUST</bcp14> be set to zero on transmission and ignor
		ed on
		receipt.</dd>
		<dt>Flags:</dt>
		<dd>This field may be used to further specify the exclusion constraint
		with regard to the LSP. Currently, no flags are defined.</dd>
		<dt>Symbolic Path Name:</dt>
		<dd><t>This is the identifier given to an LSP. Its syntax and
		semantics are identical to those of the Symbolic Path Name field
		defined in <xref target="RFC8231" sectionFormat="of" section="7.3.2"/>
		where it says: "symbolic name for the LSP, unique in the PCC. It
		<bcp14>SHOULD</bcp14> be a string of printable ASCII characters,
		without a NULL terminator." The symbolic path name in the LSP
		Exclusion subobject <bcp14>MUST</bcp14> 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.</t>
		<t>This subobject <bcp14>MAY</bcp14> be present multiple times in the
		XRO to exclude resources from multiple LSPs.
		When a stateful PCE receives a PCReq message carrying this subobject,
		it <bcp14>MUST</bcp14> search for the identified LSP in its LSP-DB and
		then exclude from the new path computation all resources used by the
		identified LSP.</t>


	<t>Note that this XRO Sub-object could also be used by non-GMPLS LSPs.	<t>Note that this XRO subobject could also be used by non-GMPLS LSPs.
	The description by	The usage of the XRO subobject for any non-GMPLS LSPs is not in the scop
	usage of non-GMPLS LSPs is not in the scope of this document. </t>	e of this document. </t>
		</dd>
		</dl>

	</section>	</section>

	<section anchor="flags">	<section anchor="flags">

	<name>New flags in the LSP-EXTENDED-FLAG TLV in LSP Object</name>	<name>New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object</name>

	<t>The LSP Object is defined in Section 7.3 of <xref target="RFC8231"
	/>, and the new extended
	flags TLV is defined in <xref target="RFC9357" />. This TLV is used i
	n PCUpd, PCRpt and
	PCInitiate messages for GMPLS, with the following flags defined in thi
	s document.</t>

	<ul>

	<li>G (GMPLS LSP(TBDb) -- 1 bit) : If set to 1, it indicates the LS
	P is a GMPLS LSP.</li>

	<li>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.</li>


	<li>RG (Routing Granularity(TBDc) -- 2 bits) : RG flag for GMPLS is	<t>The LSP object is defined in <xref target="RFC8231"
	also defined in the	sectionFormat="of" section="7.3"/>, and the new extended flags TLV
	LSP-EXTENDED-FLAG TLV. The value are defined as per <xref target="RF	is defined in <xref target="RFC9357" />. This TLV is used in PCUpd,
	C8779" />:</li>	PCRpt and PCInitiate messages for GMPLS, with the following flags
		defined in this document:</t>


	</ul>	<dl spacing="normal" newline="true">
		<dt>G (GMPLS LSP (0) -- 1 bit):</dt>
		<dd>If set to 1, it indicates the LSP is a GMPLS LSP.</dd>
		<dt>B (Bidirectional LSP (1) -- 1 bit):</dt>
		<dd>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.</dd>


	<t>00: reserved</t>	<dt>RG (Routing Granularity (2-3) -- 2 bits):</dt>
	<t>01: node</t>	<dd><t>The RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG
	<t>10: link</t>	TLV. The values are defined as per <xref target="RFC8779" />:</t>
	<t>11: label</t>	<dl spacing="compact">
		<dt>00:</dt>
		<dd>reserved</dd>
		<dt>01:</dt>
		<dd>node</dd>
		<dt>10:</dt>
		<dd>link</dd>
		<dt>11:</dt>
		<dd>label</dd>
		</dl>
		</dd>
		</dl>

	</section>	</section>

	</section>	</section>

	</section>	</section>

	<section anchor="errors">	<section anchor="errors">
	<name>Update to Error Handling</name>	<name>Update to Error Handling</name>


	<t>A PCEP-ERROR object is used to report a PCEP error and is characterized	<t>A PCEP-ERROR object is used to report a PCEP error and is
	by an Error-Type	characterized by an Error-Type that specifies the type of error and an
	that specifies the type of error and an Error-value that provides addition	Error-value that provides additional information about the error. This
	al information	section adds additional error handling procedures to those specified in
	about the error. This section adds additional error handling procedures t	<xref target="RFC8779" sectionFormat="of" section="3"/>. Please note
	o those specified	that all error handling specified in <xref target="RFC8779"
	in Section 3 of <xref target="RFC8779" />. Please note that all error han	sectionFormat="of" section="3"/> is applicable and <bcp14>MUST</bcp14>
	dling specified in	be supported for a stateful PCE in GMPLS networks.</t>
	Section 3 of <xref target="RFC8779" /> is applicable and MUST be supported
	for a stateful PCE
	in GMPLS networks.</t>

	<section anchor="errcap">	<section anchor="errcap">
	<name>Error Handling in PCEP Capabilities Advertisement</name>	<name>Error Handling in PCEP Capabilities Advertisement</name>


	<t>The PCEP extensions described in this document for stateful PCEs with	<t>The PCEP extensions described in this document for stateful PCEs with
	GMPLS capability	GMPLS capabilities
	MUST NOT be used if the PCE has not advertised its capabilities with GMP	<bcp14>MUST NOT</bcp14> be used if the PCE has not advertised its capabi
	LS as per <xref target="captlv" />.</t>	lities with GMPLS as per <xref target="captlv" />.</t>

	<t>If the PCC understands the U flag that indicates the stateful LSP-UPD ATE-CAPABILITY, but did	<t>If the PCC understands the U flag that indicates the stateful LSP-UPD ATE-CAPABILITY, but did
	not advertise this capability, then upon receipt of a PCUpd message for GMPLS LSP from the PCE,	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"), err	it <bcp14>SHOULD</bcp14>
	or-value TBDx ("Attempted	generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value 25
	LSP Update Request for GMPLS if stateful PCE capability for GMPLS was no	("Attempted LSP update request for GMPLS if stateful PCE capability not advertis
	t advertised"), and terminate	ed") and terminate
	the PCEP session. Such a PCC MAY decide to utilize the capability even t	the PCEP session. Such a PCC <bcp14>MAY</bcp14> decide to utilize the ca
	hough it did not advertise	pability even though it did not advertise
	support for it. </t>	support for it. </t>

	<t>If the PCE understands the R flag that indicates the stateful LSP-REP ORT-CAPABILITY, but did not	<t>If the PCE understands the R flag that indicates the stateful LSP-REP ORT-CAPABILITY, but did not

	advertise this capability, then upon receipt of a PCRpt message for GMPL	advertise this capability, then upon receipt of a PCRpt message for GMPL
	S LSP from the PCC, it SHOULD	S LSP from the PCC, it <bcp14>SHOULD</bcp14>
	generate a PCErr with error-type 19 ("Invalid Operation"), error-value T	generate a PCErr with Error-Type 19 ("Invalid Operation") Error-value 26
	BDy ("Attempted LSP Report	("Attempted LSP State Report for GMPLS if stateful PCE capability not advertise
	Request for GMPLS if stateful PCE capability for GMPLS was not advertise	d") and terminate the PCEP
	d"), and terminate the PCEP	session. Such a PCE <bcp14>MAY</bcp14> decide to utilize the capability
	session. Such a PCE MAY decide to utilize the capability even though it	even though it did not advertise support
	did not advertise support
	for it.</t>	for it.</t>

	<t>If the PCC understands the I flag that indicates LSP-INSTANTIATION-C APABILITY, but did not	<t>If the PCC understands the I flag that indicates LSP-INSTANTIATION-C APABILITY, but did not
	advertise this capability, then upon receipt of a PCInitiate message for GMPLS LSP from the PCE,	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"), err	it <bcp14>SHOULD</bcp14> generate a PCErr with Error-Type 19 ("Invalid O
	or-value TBDz ("Attempted	peration") Error-value 27 ("Attempted
	LSP Instantiation Request for GMPLS if stateful PCE instantiation capabi	LSP instantiation request for GMPLS if stateful PCE instantiation capabi
	lity for GMPLS was not	lity for not
	advertised"), and terminate the PCEP session. Such a PCC MAY decide to u	advertised") and terminate the PCEP session. Such a PCC <bcp14>MAY</bcp1
	tilize the capability	4> decide to utilize the capability
	even though it did not advertise support for it.</t>	even though it did not advertise support for it.</t>

	</section>	</section>

	<section anchor="erropt">	<section anchor="erropt">

	<name>Error Handling in LSP Re-optimization</name>	<name>Error Handling in LSP Reoptimization</name>


	<t>A stateful PCE is expected to perform an LSP re-optimization when rec	<t>A stateful PCE is expected to perform an LSP reoptimization when rece
	eiving a message with the	iving a message with the
	R bit set in the RP object. If no LSP state information is available to	R bit set in the RP object.
	carry out re-optimization,
	the stateful PCE SHOULD report the error "LSP state information unavaila	If no LSP state information is available to carry out reoptimization,
	ble for the LSP	the stateful PCE <bcp14>SHOULD</bcp14> report Error-Type 19 ("Invalid Op
	re-optimization" (Error Type = 19, Error value= TBD6), although such a P	eration") Error-value 23 ("LSP state info unavailable for reoptimization"), alth
	CE MAY consider the	ough such a PCE <bcp14>MAY</bcp14> consider the
	re-optimization to have successfully completed. Note that this error me	reoptimization to have successfully completed. Note that this error mes
	ssage could also be	sage could also be
	used by non-GMPLS LSPs.</t>	used by non-GMPLS LSPs.</t>

	</section>	</section>

	<section anchor="errex">	<section anchor="errex">
	<name>Error Handling in Route Exclusion</name>	<name>Error Handling in Route Exclusion</name>


	<t>The LSP exclusion sub-object in XRO is defined in <xref target="exclu	<t>The LSP Exclusion subobject in XRO, as defined in <xref target="exclu
	sion" /> of this document MAY be present	sion" /> of this document, <bcp14>MAY</bcp14> be present
	multiple times. When a stateful PCE receives a PCEP message carrying th	multiple times. When a stateful PCE receives a PCEP message carrying th
	is sub-object, it searches	is subobject, it searches
	for the identified LSP in its LSP-DB and then excludes from the new path	for the identified LSP in its LSP-DB. It then excludes from the new pat
	computation all the	h computation all the
	resources used by the identified LSP. If the stateful PCE cannot recogn ize the symbolic path	resources used by the identified LSP. If the stateful PCE cannot recogn ize the symbolic path

	name of the identified LSP, it SHOULD send an error message PCErr report	name of the identified LSP, it <bcp14>SHOULD</bcp14> send an error messa
	ing Error-type = 19	ge PCErr reporting Error-Type 19 ("Invalid Operation") Error-value 24 ("LSP stat
	("Invalid Operation"), Error-value = TBD7 ("The LSP state information fo	e info for route exclusion not found"). Along with the unrecognized symbolic pa
	r route exclusion purpose	th name, it <bcp14>MAY</bcp14> also provide information to the requesting PCC us
	cannot be found"). Optionally, it MAY also provide with the unrecognize	ing the error-reporting techniques described in <xref
	d symbolic path name	target="RFC5440" />.
	information to the requesting PCC using the error reporting techniques d
	escribed in <xref	An implementation <bcp14>MAY</bcp14> choose to ignore the requested exclu
	target="RFC5440" />. An implementation MAY choose to ignore the request	sion when the
	ed exclusion when the	LSP cannot be found because it could claim that it has avoided using all
	LSP cannot be found because it could claim it that it has avoided using	resources associated
	all resources associated
	with an LSP that doesn't exist. </t>	with an LSP that doesn't exist. </t>

	</section>	</section>

	<section anchor="errgen">	<section anchor="errgen">

	<name>Error Handling for generalized END-POINTS</name>	<name>Error Handling for the Generalized END-POINTS Object</name>


	<t>Note that the END-POINTS object in the Stateful PCEP messages was int	<t>Note that the END-POINTS object in stateful PCEP messages was introdu
	roduced for P2MP	ced for Point-to-Multipoint (P2MP)
	<xref target="RFC8623" />. Similarly, the END-POINTS object MUST be carr	<xref target="RFC8623" />. Similarly, the END-POINTS object <bcp14>MUST<
	ied for the GMPLS	/bcp14> be carried for the GMPLS
	LSP. If the END-POINTS object is missing and the GMPLS flag in LSP-EXTE NDED-FLAG is set,	LSP. If the END-POINTS object is missing and the GMPLS flag in LSP-EXTE NDED-FLAG is set,

	the receiving PCE or PCC MUST send a PCErr message with Error-type=6 ("M	the receiving PCE or PCC <bcp14>MUST</bcp14> send a PCErr message with E
	andatory Object	rror-Type 6 ("Mandatory Object missing") and Error-value 3 ("END-POINTS object m
	missing") and Error-value=3 ("END-POINTS object missing") (defined in <x	issing") (defined in <xref target="RFC5440" />).
	ref target="RFC5440" />).	Similarly, if the END-POINTS object with the Generalized Endpoint object
	Similarly, if the END-POINTS object with the Generalized Endpoint object	type is received but
	type is received but if	the LSP-EXTENDED-FLAG TLV is missing in the LSP object or the G flag in
	the LSP-EXTENDED-FLAG TLV is missing in the LSP object or if the G flag	the LSP-EXTENDED-FLAG
	in the LSP-EXTENDED-FLAG	TLV is not set, the receiving PCE or PCC <bcp14>MUST</bcp14> send a PCEr
	TLV is not set, the receiving PCE or PCC MUST send a PCErr message with	r message with Error-Type 19 ("Invalid Operation") Error-value 28 ("Use of the G
	Error-type = 19 ("Invalid	eneralized Endpoint object type for non-GMPLS LSPs").</t>
	Operation"), Error-value = TBD9 ("Use of Generalized Endpoint object typ
	e for non-GMPLS LSP").</t>

	<t>If the END-POINTS object with Generalized Endpoint Object Type is mis
	sing 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"). </t>

	</section>

	</section>

	<section anchor="imp">
	<name>Implementation</name>

	<t>[NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942
	is to be removed
	before publication as an RFC]</t>

	<t>This section records the status of known implementations of the protoco
	l defined by this
	specification at the time of posting of this Internet-Draft, and is based
	on a proposal
	described in <xref target="RFC7942" />. The description of implementation
	s in this section
	is intended to assist the IETF in its decision processes in progressing dr
	afts to RFCs.
	Please note that the listing of any individual implementation here does no
	t imply endorsement
	by the IETF. Furthermore, no effort has been spent to verify the informat
	ion 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.</t>

	<t>According to <xref target="RFC7942" />, "this will allow reviewers and
	working groups to
	assign due consideration to documents that have the benefit of running cod
	e, which may serve
	as evidence of valuable experimentation and feedback that have made the im
	plemented protocols
	more mature. It is up to the individual working groups to use this informa
	tion as they see fit".</t>

	<section anchor="huawei">
	<name>Huawei Technologies</name>


	<ul>	<t>If the END-POINTS object with Generalized Endpoint object type is mis
	<li>Organization: Huawei Technologies, Co. LTD</li>	sing the LABEL-REQUEST
	<li>Implementation: Huawei NCE-T </li>	TLV, the receiving PCE or PCC <bcp14>MUST</bcp14> send a PCErr message w
	<li>Description: PCRpt, PCUpd and PCInitiate messages for GMPLS Networ	ith Error-Type 6 ("Mandatory Object missing") Error-value 20 ("LABEL-REQUEST TLV
	k</li>	missing"). </t>
	<li>Maturity Level: Production</li>
	<li>Coverage: Full</li>
	<li>Contact: zhenghaomian@huawei.com</li>
	</ul>

	</section>	</section>

	</section>	</section>

	<section anchor="iana">	<section anchor="iana">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<section anchor="iana-flag">	<section anchor="iana-flag">

	<name>title=New Flags in GMPLS-CAPABILITY TLV</name>	<name>New Flags in the GMPLS-CAPABILITY TLV</name>


	<t><xref target="RFC8779" /> defines the GMPLS-CAPABILITY TLV; per that	<t><xref target="RFC8779" /> defines the GMPLS-CAPABILITY TLV; per that
	RFC, IANA created a	RFC, IANA created the "GMPLS-CAPABILITY TLV Flag Field" registry to manage the v
	registry to manage the value of the GMPLS-CAPABILITY TLV's Flag field.	alues of the GMPLS-CAPABILITY TLV's Flag field. This document registers new bit
	This document requests	s in this registry as follows:</t>
	IANA to allocate new bits in the GMPLS-CAPABILITY TLV Flag Field registr
	y, as follows. IANA is
	requested to make allocations starting from the least significant bit (3
	1).</t>


	<artwork>	<table anchor="iana-1" align="center">
	<![CDATA[	<name></name>
	Bit \| Description \| Reference	<thead>
	-----+----------------------------------+------------	<tr>
	TBDa \| LSP-REPORT-CAPABILITY (R) \| [This.I-D]	<th>Bit</th>
	TBD1 \| LSP-UPDATE-CAPABILITY (U) \| [This.I-D]	<th>Capability Description</th>
	TBD2 \| LSP-INSTANTIATION-CAPABILITY (I) \| [This.I-D]	<th>Reference</th>
	]]>	</tr>
	</artwork>	</thead>
		<tbody>
		<tr>
		<td>31</td>
		<td>LSP-REPORT-CAPABILITY (R)</td>
		<td>RFC 9504</td>
		</tr>
		<tr>
		<td>30</td>
		<td>LSP-UPDATE-CAPABILITY (U)</td>
		<td>RFC 9504</td>
		</tr>
		<tr>
		<td>29</td>
		<td>LSP-INSTANTIATION-CAPABILITY (I)</td>
		<td>RFC 9504</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>

	<section anchor="iana-xro">	<section anchor="iana-xro">

	<name>New Sub-object for the Exclude Route Object</name>	<name>New Subobject for the Exclude Route Object</name>


	<t>IANA maintains the various XRO Subobjects types within the "XRO Subob	<t>IANA maintains the various XRO subobject types within the "XRO Subobj
	jects" subregistry	ects" subregistry
	of the PCEP Numbers registry. IANA is requested to allocate a codepoint	of the "Path Computation Element Protocol (PCEP) Numbers" registry. IAN
	for another XRO	A has allocated a codepoint for another XRO
	subobject as follows:</t>	subobject as follows:</t>


	<artwork>	<table anchor="iana-2" align="center">
	<![CDATA[	<name></name>
	Value \| Description \| Reference	<thead>
	--------+------------------------------+-------------	<tr>
	TBD3 \| LSP \| [This.I-D]	<th>Value</th>
	]]>	<th>Description</th>
	</artwork>	<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>11</td>
		<td>LSP</td>
		<td>RFC 9504</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>

	<section anchor="iana-excl">	<section anchor="iana-excl">

	<name>Flags Field for LSP exclusion Sub-object</name>	<name>Flags Field for the LSP Exclusion Subobject</name>


	<t>IANA is requested to create a registry named "LSP Exclusion Sub-Obje ct Flag Field",	<t>IANA has created a registry named "LSP Exclusion Subobject Flag Field ",
	within the "Path Computation Element Protocol (PCEP) Numbers" group, to manage the Flag	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 d	field of the LSP Exclusion subobject in the XRO. No flag is currently de
	efined for this	fined for this
	flag field in this document.</t>	Flag field in this document.</t>


	<t>Codespace of the Flag field (LSP Exclusion sub-object)</t>	<t>Codespace of the Flag field (LSP Exclusion Subobject)</t>


	<artwork>	<table anchor="iana-3" align="center">
	<![CDATA[	<name></name>
	Bit \| Description \| Reference	<thead>
	------+-------------------+-------------	<tr>
	0-7 \| Unassigned \| [This.I-D]	<th>Bit</th>
	]]>	<th>Capability Description</th>
	</artwork>	<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0-7</td>
		<td>Unassigned</td>
		<td>RFC 9504</td>
		</tr>
		</tbody>
		</table>

	<t>New values are to be assigned by Standards Action <xref target="RFC81 26" />.	<t>New values are to be assigned by Standards Action <xref target="RFC81 26" />.

	Each bit should be tracked with the following qualities:</t>	Each bit should be registered with the following entries:</t>

	<ul>	<ul>
	<li>Bit number (counting from bit 0 as the most significant bit)</li>	<li>Bit number (counting from bit 0 as the most significant bit)</li>
	<li>Capability description</li>	<li>Capability description</li>

	<li>Defining RFC</li>	<li>Reference to defining RFC</li>
	</ul>	</ul>

	</section>	</section>

	<section anchor="iana-extend">	<section anchor="iana-extend">
	<name>New Flags in the LSP-EXTENDED-FLAGS TLV</name>	<name>New Flags in the LSP-EXTENDED-FLAGS TLV</name>


	<t><xref target="I-D.ietf-pce-lsp-extended-flags" /> requested IANA to c reate a	<t><xref target="RFC9357" /> requested IANA to create a
	subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within the "P ath Computation	subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within the "P ath Computation
	Element Protocol (PCEP) Numbers" registry, to manage the Flag field of t he	Element Protocol (PCEP) Numbers" registry, to manage the Flag field of t he
	LSP-EXTENDED-FLAG TLV.</t>	LSP-EXTENDED-FLAG TLV.</t>


	<t>IANA is requested to make assignments from this registry as follows:<	<t>IANA has made assignments from this registry as follows:</t>
	/t>

	<artwork>
	<![CDATA[
	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]
	]]>
	</artwork>


	<t>* - 2 bits need to be allocated</t>	<table anchor="iana-4" align="center">
		<name></name>
		<thead>
		<tr>
		<th>Bit</th>
		<th>Capability Description</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>0</td>
		<td>GMPLS LSP (G)</td>
		<td>RFC 9504</td>
		</tr>
		<tr>
		<td>1</td>
		<td>Bidirectional Co-routed LSP (B)</td>
		<td>RFC 9504</td>
		</tr>
		<tr>
		<td>2-3</td>
		<td>Routing Granularity (RG)</td>
		<td>RFC 9504</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>

	<section anchor="iana-er">	<section anchor="iana-er">

	<name>New PCEP Error Codes</name>	<name>New PCEP Error Codes</name>


	<t>IANA is requested to make the following allocation in the "PCEP-ERROR Object	<t>IANA has made the following allocations in the "PCEP-ERROR Object
	Error Types and Values" registry.</t>	Error Types and Values" registry.</t>


	<artwork>	<table anchor="iana-5" align="center">
	<![CDATA[	<name></name>
	+===========+================+=========================+===========+	<thead>
	\| Error-Type\| Meaning \| Error-value \| Reference \|	<tr>
	+===========+================+=========================+===========+	<th>Error-Type</th>
	\| 6 \| Mandatory \|TBD8: LABEL-REQUEST TLV \| This I-D \|	<th>Meaning</th>
	\| \| Object missing \|missing \| \|	<th>Error-value</th>
	\|-----------\|----------------+-------------------------+-----------+	<th>Reference</th>
	\|19 \| Invalid \|TBD6: LSP state info \| This I-D \|	</tr>
	\| \| Operation \|unavailable for the \| \|	</thead>
	\| \| \|Re-optimization \| \|	<tbody>
	\| \| +-------------------------+-----------+	<tr>
	\| \| \|TBD7: LSP state info for \| This I-D \|	<td>6</td>
	\| \| \|route exclusion not found\| \|	<td>Mandatory Object missing</td>
	\| \| +-------------------------+-----------+	<td>20: LABEL-REQUEST TLV missing</td>
	\| \| \|TBDx: Attempted LSP \| This I-D \|	<td>RFC 9504</td>
	\| \| \|Update Request for GMPLS \| \|	</tr>
	\| \| \|if stateful PCE \| \|	<tr>
	\| \| \|capability not advertised\| \|	<td rowspan="6">19</td>
	\| \| +-------------------------+-----------+	<td rowspan="6">Invalid Operation</td>
	\| \| \|TBDy: Attempted LSP State\| This I-D \|	<td>23: LSP state info unavailable for reoptimization</td>
	\| \| \|Report for GMPLS if \| \|	<td>RFC 9504</td>
	\| \| \|stateful PCE capability \| \|	</tr>
	\| \| \|not advertised \| \|	<tr>
	\| \| +-------------------------+-----------+	<td>24: LSP state info for route exclusion not found</td>
	\| \| \|TBDz: Attempted LSP \| This I-D \|	<td>RFC 9504</td>
	\| \| \|Instantiation Request for\| \|	</tr>
	\| \| \|GMPLS if stateful PCE \| \|	<tr>
	\| \| \|instantiation capability \| \|	<td>25: Attempted LSP update request for GMPLS if stateful PCE capability
	\| \| \|not advertised \| \|	not advertised</td>
	\| \| +-------------------------+-----------+	<td>RFC 9504</td>
	\| \| \|TBD9: use of Generalized \| This I-D \|	</tr>
	\| \| \|Endpoint object type for \| \|	<tr>
	\| \| \|non-GMPLS LSP \| \|	<td>26: Attempted LSP State Report for GMPLS if stateful PCE capability n
	+-----------+----------------+-------------------------+-----------+	ot advertised</td>
	]]>	<td>RFC 9504</td>
	</artwork>	</tr>
		<tr>
		<td>27: Attempted LSP instantiation request for GMPLS if stateful PCE ins
		tantiation capability not advertised</td>
		<td>RFC 9504</td>
		</tr>
		<tr>
		<td>28: Use of the Generalized Endpoint object type for non-GMPLS LSPs</t
		d>
		<td>RFC 9504</td>
		</tr>
		</tbody>
		</table>

	</section>	</section>

	</section>	</section>

	<section anchor="mgmt">	<section anchor="mgmt">
	<name>Manageability Considerations</name>	<name>Manageability Considerations</name>

	<t>General PCE management considerations are discussed in <xref target="RF C4655" />	<t>General PCE management considerations are discussed in <xref target="RF C4655" />

	and <xref target="RFC5440" />, and GMPLS specific PCEP management consider	and <xref target="RFC5440" />, and GMPLS-specific PCEP management consider
	ations are	ations are
	described in <xref target="RFC8779" />. In this document the management c	described in <xref target="RFC8779" />. In this document, the management
	onsiderations	considerations
	for stateful PCEP extension in GMPLS are described. </t>	for stateful PCEP extension in GMPLS are described. </t>

	<t>This section follows the guidance of <xref target="RFC6123" />.</t>	<t>This section follows the guidance of <xref target="RFC6123" />.</t>

	<section>	<section>
	<name>Control of Function through Configuration and Policy</name>	<name>Control of Function through Configuration and Policy</name>


	<t>In addition to the parameters already listed in Section 8.1 of <xref	<t>In addition to the parameters already listed in <xref
	target="RFC5440" />,	target="RFC5440" sectionFormat="of" section="8.1"/>, a PCEP
	a PCEP implementation SHOULD allow configuration of the following PCEP s	implementation <bcp14>SHOULD</bcp14> allow configuration of the
	ession parameters	following PCEP session parameters on a PCC. However, an implementation
	on a PCC, however, an implementation MAY choose to make these features a	<bcp14>MAY</bcp14> choose to make these features available on all PCEP
	vailable on all PCEP
	sessions:</t>	sessions:</t>

	<ul>	<ul>
	<li>The ability to send stateful PCEP messages for GMPLS LSPs.</li>	<li>The ability to send stateful PCEP messages for GMPLS LSPs.</li>
	<li>The ability to use path computation constraints (e.g., XRO).</li>	<li>The ability to use path computation constraints (e.g., XRO).</li>
	</ul>	</ul>


	<t>In addition to the parameters already listed in Section 8.1 of <xref	<t>In addition to the parameters already listed in <xref
	target="RFC5440" />,	target="RFC5440" sectionFormat="of" section="8.1"/>, a PCEP
	a PCEP implementation SHOULD allow configuration of the following PCEP s	implementation <bcp14>SHOULD</bcp14> allow configuration of the
	ession parameters on	following PCEP session parameters on a PCE:</t>
	a PCE:</t>

	<ul>	<ul>
	<li>The ability to compute paths in a stateful manner in GMPLS network s.</li>	<li>The ability to compute paths in a stateful manner in GMPLS network s.</li>
	<li>A set of GMPLS-specific constraints.</li>	<li>A set of GMPLS-specific constraints.</li>
	</ul>	</ul>

	<t>These parameters may be configured as default parameters for any PCEP session the PCEP	<t>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	speaker participates in or they may apply to a specific session with a g iven PCEP peer
	or a specific group of sessions with a specific group of PCEP peers.</t>	or a specific group of sessions with a specific group of PCEP peers.</t>

	</section>	</section>

	<section>	<section>
	<name>Information and Data Models</name>	<name>Information and Data Models</name>


	<t>The YANG model in <xref target="I-D.ietf-pce-pcep-yang" /> can be use	<t>The YANG module in <xref target="I-D.ietf-pce-pcep-yang" /> can be us
	d to configure and	ed to configure and
	monitor PCEP states and messages. To make sure that the YANG model is us	monitor PCEP states and messages. To make sure that the YANG module is u
	eful for the	seful for the
	extensions as described in this document, it would need to include adver tised GMPLS stateful	extensions as described in this document, it would need to include adver tised GMPLS stateful
	capabilities etc. A future version of <xref target="I-D.ietf-pce-pcep-ya ng" /> will include	capabilities etc. A future version of <xref target="I-D.ietf-pce-pcep-ya ng" /> will include
	this.</t>	this.</t>

	<t>As described in <xref target="I-D.ietf-teas-yang-path-computation" /> , a YANG-based	<t>As described in <xref target="I-D.ietf-teas-yang-path-computation" /> , a YANG-based
	interface can be used in some cases to request GMPLS path computations, instead of PCEP.	interface can be used in some cases to request GMPLS path computations, instead of PCEP.

	Refer <xref target="I-D.ietf-teas-yang-path-computation" /> for details. </t>	Refer to <xref target="I-D.ietf-teas-yang-path-computation" /> for detai ls. </t>

	</section>	</section>

	<section>	<section>
	<name>Liveness Detection and Monitoring</name>	<name>Liveness Detection and Monitoring</name>


	<t>This document makes no change to the basic operation of PCEP, so ther	<t>This document makes no change to the basic operation of PCEP, so
	e are no changes	there are no changes to the requirements for liveness detection and
	to the requirements for liveness detection and monitoring in <xref targe	monitoring in <xref target="RFC4657" /> and <xref target="RFC5440"
	t="RFC4657" />	sectionFormat="of" section="8.3"/>.</t>
	and Section 8.3 of <xref target="RFC5440" />.</t>

	</section>	</section>

	<section>	<section>
	<name>Verifying Correct Operation</name>	<name>Verifying Correct Operation</name>


	<t>This document makes no change to the basic operations of PCEP and the	<t>This document makes no change to the basic operations of PCEP and
	considerations	the considerations described in <xref target="RFC5440"
	described in Section 8.4 of <xref target="RFC5440" />. New errors defin	sectionFormat="of" section="8.4"/>. New errors defined by this
	ed by this document	document should satisfy the requirement to log error events.</t>
	should satisfy the requirement to log error events.</t>

	</section>	</section>

	<section>	<section>
	<name>Requirements on Other Protocols and Functional Components</name>	<name>Requirements on Other Protocols and Functional Components</name>

	<t>When the detailed route information is included for LSP state synchro nization (either	<t>When the detailed route information is included for LSP state synchro nization (either

	at the initial stage or during LSP state report process), this requires	at the initial stage or during the LSP State Report process), this requi
	the ingress node	res the ingress node
	of an LSP to carry the RRO object in order to enable the collection of s	of an LSP to carry the Record Route Object (RRO) object in order to enab
	uch information. </t>	le the collection of such information. </t>

	</section>	</section>

	<section>	<section>
	<name>Impact on Network Operation</name>	<name>Impact on Network Operation</name>


	<t>The management considerations concerning the impact on network operat	<t>The management considerations concerning the impact on network
	ions described	operations described in <xref target="RFC8779" sectionFormat="of"
	in Section 4.6 of <xref target="RFC8779" /> apply here.</t>	section="4.6"/> apply here.</t>

	</section>	</section>

	</section>	</section>

	<section>	<section>
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>The security considerations elaborated in <xref target="RFC5440" /> app ly to this	<t>The security considerations elaborated in <xref target="RFC5440" /> app ly to this
	document. The PCEP extensions to support GMPLS-controlled networks should be considered	document. The PCEP extensions to support GMPLS-controlled networks should be considered

	under the same security as for MPLS networks, as noted in <xref target="RF C7025" />. So	under the same security as for MPLS networks, as noted in <xref target="RF C7025" />. Therefore,
	the PCEP extension to support GMPLS specified in <xref target="RFC8779" /> is used as the	the PCEP extension to support GMPLS specified in <xref target="RFC8779" /> is used as the

	foundation of this document and the security considerations in <xref targe t="RFC8779" />	foundation of this document; the security considerations in <xref target=" RFC8779" />
	should also be applicable to this document. The secure transport of PCEP specified in	should also be applicable to this document. The secure transport of PCEP specified in
	<xref target="RFC8253" /> allows the usage of Transport Layer Security (TL S). The same	<xref target="RFC8253" /> allows the usage of Transport Layer Security (TL S). The same
	can also be used by the PCEP extension defined in this document. </t>	can also be used by the PCEP extension defined in this document. </t>

	<t>This document provides additional extensions to PCEP so as to facilitat e stateful	<t>This document provides additional extensions to PCEP so as to facilitat e stateful
	PCE usage in GMPLS-controlled networks, on top of <xref target="RFC8231" / > and	PCE usage in GMPLS-controlled networks, on top of <xref target="RFC8231" / > and
	<xref target="RFC8281" />. Security issues caused by the extension in	<xref target="RFC8281" />. Security issues caused by the extension in
	<xref target="RFC8231" /> and <xref target="RFC8281" /> are not altered by the additions	<xref target="RFC8231" /> and <xref target="RFC8281" /> are not altered by the additions
	in this document. The security considerations in <xref target="RFC8231" / > and	in this document. The security considerations in <xref target="RFC8231" / > and
	<xref target="RFC8281" />, including both issues and solutions, apply to t his document	<xref target="RFC8281" />, including both issues and solutions, apply to t his document
	as well.</t>	as well.</t>

	</section>	</section>


	<section>
	<name>Acknowledgement</name>

	<t>We would like to thank Adrian Farrel, Cyril Margaria, George Swallow,
	Jan Medved,
	Sue Hares, and John Scudder for the useful comments and discussions. </t>

	<t>Thanks to Dhruv Dhody for Shepherding this document and providing usefu
	l comments.</t>

	</section>

	</middle>	</middle>


	<back>	<back>


	<references>	<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
	<name>Nomative References</name>	<displayreference target="I-D.ietf-teas-yang-path-computation" to="YANG-PATH-COM
		PUTATION"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.5440.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.5521.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8231.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8253.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8281.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8779.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.9357.xml"/>


	</references>	<references><name>References</name>
		<references>
		<name>Normative References</name>


		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
		9.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.544
		0.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
		FC.5511.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.552
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
		4.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.823
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.825
		3.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.828
		1.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.877
		9.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.935
		7.xml"/>
		</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>


	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.805
	.7942.xml"/>	1.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.823
	.8051.xml"/>	2.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.828
	.8232.xml"/>	2.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.347
	.8282.xml"/>	1.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.347
	.3471.xml"/>	3.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.465
	.3473.xml"/>	5.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.465
	.4655.xml"/>	7.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.487
	.4657.xml"/>	2.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.487
	.4872.xml"/>	3.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.612
	.4873.xml"/>	3.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.702
	.5511.xml"/>	5.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.739
	.6123.xml"/>	9.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
	.7025.xml"/>	6.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.862
	.7399.xml"/>	3.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.874
	.8126.xml"/>	5.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8623.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
	.8745.xml"/>

	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-
	pcep-yang.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas
	-yang-path-computation.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pce-
	lsp-extended-flags.xml"/>

	</references>

	<section title="Contributors' Address">

	<artwork>
	<![CDATA[
	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
	Castelldefels, Barcelona 08860
	Spain
	Email: ramon.casellas@cttc.es


	Siva Sivabalan	<!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists. Updated to long version bec
	Cisco Systems	ause missing editor role -->
	Email: msiva@cisco.com


	Clarence Filsfils	<reference anchor="I-D.ietf-pce-pcep-yang" target="https://datatracker.ietf.org/
	Cisco Systems	doc/html/draft-ietf-pce-pcep-yang-22">
	Email: cfilsfil@cisco.com	<front>
		<title>A YANG Data Model for Path Computation Element Communications Protocol (P
		CEP)
		</title>
		<author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor">
		<organization>Huawei</organization>
		</author>
		<author initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
		<organization>Juniper Networks</organization>
		</author>
		<author initials="J." surname="Hardwick" fullname="Jonathan Hardwick">
		<organization>Microsoft</organization>
		</author>
		<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
		<organization>Nvidia</organization>
		</author>
		<date month="September" day="11" year="2023"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-22"/>
		</reference>


	Robert Varga	<!-- [I-D.ietf-teas-yang-path-computation] IESG state I-D Exists. Updated to lon
	Pantheon Technologies	g version because missing editor roles -->
	Email: nite@hq.sk
	]]>
	</artwork>


	</section>	<reference anchor="I-D.ietf-teas-yang-path-computation" target="https://datatrac
		ker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-21">
		<front>
		<title>A YANG Data Model for requesting path computation</title>
		<author initials="I." surname="Busi" fullname="Italo Busi" role="editor">
		<organization>Huawei Technologies</organization>
		</author>
		<author initials="S." surname="Belotti" fullname="Sergio Belotti" role="editor">
		<organization>Nokia</organization>
		</author>
		<author initials="O. G." surname="de Dios" fullname="Oscar Gonzalez de Dios">
		<organization>Telefonica</organization>
		</author>
		<author initials="A." surname="Sharma" fullname="Anurag Sharma">
		<organization>Google</organization>
		</author>
		<author initials="Y." surname="Shi" fullname="Yan Shi">
		<organization>China Unicom</organization>
		</author>
		<date month="July" day="7" year="2023"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-path-computation-2
		1"/>
		</reference>
		</references>
		</references>

	<section title="PCEP Messages">	<section title="PCEP Messages">

	<t>This section uses the Routing Backus-Naur Form (RBNF) <xref target="RFC 5511" /> to illustrate	<t>This section uses the Routing Backus-Naur Form (RBNF) <xref target="RFC 5511" /> to illustrate
	the PCEP messages. The RBNF in this section is reproduced for informative purposes. It is also	the PCEP messages. The RBNF in this section is reproduced for informative purposes. It is also

	expanded to show the GMPLS specific objects. </t>	expanded to show the GMPLS-specific objects. </t>

	<section title="The PCRpt Message">	<section title="The PCRpt Message">


	<t>According to <xref target="RFC8231" />, the PCRpt Message is used to report the current	<t>According to <xref target="RFC8231" />, the PCRpt message is used to report the current
	state of an LSP. This document extends the message in reporting the stat us of LSPs with GMPLS	state of an LSP. This document extends the message in reporting the stat us of LSPs with GMPLS
	characteristics. </t>	characteristics. </t>

	<t>The format of the PCRpt message is as follows:</t>	<t>The format of the PCRpt message is as follows:</t>


	<artwork>	<sourcecode type="rbnf"><![CDATA[
	<![CDATA[	<PCRpt Message> ::= <Common Header>
	<PCRpt Message> ::= <Common Header>	<state-report-list>
	<state-report-list>	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>


	<artwork>	<sourcecode type="rbnf"><![CDATA[
	<![CDATA[	<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>	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>


	<artwork>	<sourcecode type="rbnf"><![CDATA[
	<![CDATA[	<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>]	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>

	<ul>	<ul>


	<li>The END-POINTS object MUST be carried in a PCRpt message when the G flag is set in the	<li>The END-POINTS object <bcp14>MUST</bcp14> be carried in a PCRpt me ssage when the G flag is set in the
	LSP-EXTENDED-FLAG TLV in the LSP object for a GMPLS LSP.</li>	LSP-EXTENDED-FLAG TLV in the LSP object for a GMPLS LSP.</li>


	<li><intended-path> is represented by the ERO object defined in	<li><intended-path> is represented by the ERO object defined
	Section 7.9 of	in <xref target="RFC5440" sectionFormat="of" section="7.9"/> and
	<xref target="RFC5440" />, augmented in <xref target="RFC8779" /> with	augmented in <xref target="RFC8779" /> with ELC.</li>
	explicit label
	control (ELC) and Path Keys.</li>

	<li><actual-attribute-list> consists of the actual computed and signaled values of the	<li><actual-attribute-list> consists of the actual computed and signaled values of the
	<BANDWIDTH> and <metric-lists> objects defined in <xref ta rget="RFC5440" />.</li>	<BANDWIDTH> and <metric-lists> objects defined in <xref ta rget="RFC5440" />.</li>


	<li><actual-path> is represented by the RRO object defined in Se	<li><actual-path> is represented by the RRO object defined in
	ction 7.10 of	<xref target="RFC5440" sectionFormat="of" section="7.10"/>.</li>
	<xref target="RFC5440" />.</li>


	<li><intended-attribute-list> is the attribute-list defined in S	<li><intended-attribute-list> is the attribute-list defined in
	ection 6.5 of	<xref target="RFC5440" sectionFormat="of" section="6.5"/> and
	<xref target="RFC5440" /> and extended by many other documents that de	extended by many other documents that define PCEP extensions for
	fine PCEP	specific scenarios as shown below:</li>
	extensions for specific scenarios as shown below:</li>

	</ul>	</ul>


	<artwork>	<sourcecode type='rbnf'><![CDATA[
	<![CDATA[	<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>]	]]></sourcecode>
	]]>
	</artwork>

	</section>	</section>

	<section title="The PCUpd Message">	<section title="The PCUpd Message">

	<t>The format of a PCUpd message is as follows:</t>	<t>The format of a PCUpd message is as follows:</t>


	<artwork>	<sourcecode type='rbnf'><![CDATA[
	<![CDATA[	<PCUpd Message> ::= <Common Header>
	<PCUpd Message> ::= <Common Header>	<update-request-list>
	<update-request-list>	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>


	<artwork>	<sourcecode type='rbnf'><![CDATA[
	<![CDATA[	<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>	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>


	<artwork>	<sourcecode type='rbnf'><![CDATA[
	<![CDATA[	<path> ::= <intended-path><intended-attribute-list>
	<path> ::= <intended-path><intended-attribute-list>	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>

	<ul>	<ul>


	<li>The END-POINTS object MUST be carried in a PCUpd message for the G MPLS LSP.</li>	<li>The END-POINTS object <bcp14>MUST</bcp14> be carried in a PCUpd me ssage for the GMPLS LSP.</li>


	<li><intended-path> is represented by the ERO object defined in	<li><intended-path> is represented by the ERO object defined
	Section 7.9 of	in <xref target="RFC5440" sectionFormat="of" section="7.9"/>,
	<xref target="RFC5440" />, augmented in <xref target="RFC8779" /> with	augmented in <xref target="RFC8779" /> with ELC.</li>
	explicit
	label control (ELC) and Path Keys.</li>

	<li><intended-attribute-list> is the attribute-list defined in < xref target="RFC5440" />	<li><intended-attribute-list> is the attribute-list defined in < xref target="RFC5440" />
	and extended by many other documents that define PCEP extensions for s pecific scenarios	and extended by many other documents that define PCEP extensions for s pecific scenarios
	and as shown for PCRpt above.</li>	and as shown for PCRpt above.</li>

	</ul>	</ul>

	</section>	</section>

	<section title="The PCInitiate Message">	<section title="The PCInitiate Message">


	<t>According to <xref target="RFC8281" />, the PCInitiate Message is use d allow LSP Initiation. This	<t>According to <xref target="RFC8281" />, the PCInitiate message is use d allow LSP Initiation. This
	document extends the message in initiating LSPs with GMPLS characteristi cs. The format of a PCInitiate	document extends the message in initiating LSPs with GMPLS characteristi cs. The format of a PCInitiate
	message is as follows:</t>	message is as follows:</t>


	<artwork>	<sourcecode type="rbnf"><![CDATA[
	<![CDATA[	<PCInitiate Message> ::= <Common Header>
	<PCInitiate Message> ::= <Common Header>	<PCE-initiated-lsp-list>
	<PCE-initiated-lsp-list>	]]></sourcecode>
	]]>
	</artwork>

	<t>Where:</t>	<t>Where:</t>


	<artwork>	<sourcecode type="rbnf"><![CDATA[
	<![CDATA[	<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>	]]></sourcecode>
	]]>
	</artwork>


	<t>The format of the PCInitiate message is unchanged from Section 5.1 of	<t>The format of the PCInitiate message is unchanged from <xref
	<xref target="RFC8281" />. All fields are	target="RFC8281" sectionFormat="of" section="5.1"/>. All fields are
	similar to the PCRpt and the PCUpd message. </t>	similar to the PCRpt and the PCUpd messages. </t>

	</section>	</section>

	</section>	</section>


	</back>	<section numbered="false">
		<name>Acknowledgements</name>

		<t>We would like to thank <contact fullname="Adrian Farrel"/>, <contact
		fullname="Cyril Margaria"/>, <contact fullname="George Swallow"/>,
		<contact fullname="Jan Medved"/>, <contact fullname="Sue Hares"/>, and
		<contact fullname="John Scudder"/> for the useful comments and
		discussions. </t>

		<t>Thanks to <contact fullname="Dhruv Dhody"/> for Shepherding this
		document and providing useful comments.</t>

		</section>

		<section title="Contributors" numbered="false">


		<contact fullname="Xian Zhang">
		<organization>Huawei Technologies</organization>
		<address>
		<email>zhang.xian@huawei.com</email>
		</address>
		</contact>

		<contact fullname="Dhruv Dhody">
		<organization>Huawei Technology</organization>
		<address>
		<postal>
		<country>India</country>
		</postal>
		<email>dhruv.ietf@gmail.com</email>
		</address>
		</contact>

		<contact fullname="Yi Lin">
		<organization>Huawei Technologies</organization>
		<address>
		<email>yi.lin@huawei.com</email>
		</address>
		</contact>

		<contact fullname="Fatai Zhang">
		<organization>Huawei Technologies</organization>
		<address>
		<email>zhangfatai@huawei.com</email>
		</address>
		</contact>

		<contact fullname="Ramon Casellas">
		<organization>CTTC</organization>
		<address>
		<postal>
		<street>Av. Carl Friedrich Gauss n7</street>
		<city>Barcelona</city>
		<region>Castelldefels</region><code>08860</code>
		<country>Spain</country>
		</postal>
		<email>ramon.casellas@cttc.es</email>
		</address>
		</contact>

		<contact fullname="Siva Sivabalan">
		<organization>Cisco Systems</organization>
		<address>
		<email>msiva@cisco.com</email>
		</address>
		</contact>

		<contact fullname="Clarence Filsfils">
		<organization>Cisco Systems</organization>
		<address>
		<email>cfilsfil@cisco.com</email>
		</address>
		</contact>

		<contact fullname="Robert Varga">
		<organization>Pantheon Technologies</organization>
		<address>
		<email>nite@hq.sk</email>
		</address>
		</contact>

		</section>

		</back>
	</rfc>	</rfc>

End of changes. 127 change blocks.
	881 lines changed or deleted	889 lines changed or added
This html diff was produced by rfcdiff 1.48.