rfc8779xml2.original.xml		rfc8779.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<?rfc strict="yes" ?>		nsus="true" docName="draft-ietf-pce-gmpls-pcep-extensions-16" indexInclude="true
	<?rfc toc="yes"?>		" ipr="trust200902" number="8779" prepTime="2020-07-21T15:46:04" scripts="Common
	<?rfc tocompact="yes"?>		,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInc
	<?rfc tocdepth="3"?>		lude="true" xml:lang="en">
	<?rfc tocindent="yes"?>		<link href="https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensi
	<?rfc symrefs="yes"?>		ons-16" rel="prev"/>
	<?rfc sortrefs="yes" ?>		<link href="https://dx.doi.org/10.17487/rfc8779" rel="alternate"/>
	<?rfc comments="yes"?>		<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc inline="yes"?>
	<?rfc compact="no"?>
	<?rfc subcompact="no"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.
	An alternate method (rfc include) is described in the references. -->
	]>
	<rfc category="std" docName="draft-ietf-pce-gmpls-pcep-extensions-16"
	ipr="trust200902" >
	<front>		<front>
			<title abbrev="PCEP Extensions for GMPLS">Path Computation Element Communica
	<title abbrev="PCEP Ext for GMPLS">PCEP extensions for GMPLS</title>		tion Protocol (PCEP) Extensions for GMPLS</title>
	<author fullname="Cyril Margaria" initials="C.M." role="editor" surname="Mar		<seriesInfo name="RFC" value="8779" stream="IETF"/>
	garia">		<author fullname="Cyril Margaria" initials="C." role="editor" surname="Marga
	<organization>Juniper</organization>		ria">
			<organization showOnFrontPage="true">Juniper</organization>
	<address>		<address>
	<email>cmargaria@juniper.net</email>		<email>cmargaria@juniper.net</email>
	<!-- uri and facsimile elements may also be added -->
	</address>		</address>
	</author>		</author>
	<author fullname="Oscar Gonzalez de Dios" initials="O.G."		<author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surnam
	role="editor" surname="Gonzalez de Dios" >		e="Gonzalez de Dios">
	<organization>Telefonica Investigacion y Desarrollo</organization>		<organization showOnFrontPage="true">Telefonica Investigacion y Desarrollo
			</organization>
	<address>		<address>
	<postal>		<postal>
	<street>C/ Ronda de la Comunicacion</street>		<street>C/ Ronda de la Comunicacion</street>
	<city>Madrid</city>		<city>Madrid</city>
	<region></region>		<region/>
	<code>28050</code>		<code>28050</code>
	<country>Spain</country>		<country>Spain</country>
	</postal>		</postal>
	<phone>+34 91 4833441</phone>		<phone>+34 91 4833441</phone>
	<email>oscar.gonzalezdedios@telefonica.com</email>		<email>oscar.gonzalezdedios@telefonica.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Fatai Zhang" role="editor" initials="F.Z." surname="Zhang"		<author fullname="Fatai Zhang" role="editor" initials="F." surname="Zhang">
	>		<organization showOnFrontPage="true">Huawei Technologies</organization>
	<organization>Huawei Technologies</organization>
	<address>		<address>
	<postal>		<postal>
	<street>F3-5-B R&amp;D Center, Huawei Base</street>		<street>F3-5-B R&amp;D Center, Huawei Base</street>
	<street>Bantian, Longgang District </street>		<cityarea>Bantian, Longgang District</cityarea>
	<city>Shenzhen</city>		<city>Shenzhen</city>
	<region></region>		<region/>
	<code>518129</code>		<code>518129</code>
	<country>P.R.China</country>		<country>China</country>
	</postal>		</postal>
	<email>zhangfatai@huawei.com</email>		<email>zhangfatai@huawei.com</email>
	</address>		</address>
	</author>		</author>
			<date month="07" year="2020"/>
	<!-- Meta-data Declarations -->
	<date day="12" month="December" year="2019" />
	<area>Routing</area>		<area>Routing</area>
	<workgroup>Network Working Group</workgroup>		<workgroup>Network Working Group</workgroup>
	<keyword>RSVP-TE</keyword>		<keyword>RSVP-TE</keyword>
	<keyword>GMPLS</keyword>		<keyword>GMPLS</keyword>
	<keyword>PCE</keyword>		<keyword>PCE</keyword>
			<abstract pn="section-abstract">
	<abstract>		<t pn="section-abstract-1">A Path Computation Element (PCE) provides path
	<t>A Path Computation Element (PCE) provides path computation functions		computation functions
	for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)		for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
	networks. Additional requirements for GMPLS are identified in		networks. Additional requirements for GMPLS are identified in
	RFC7025.		RFC 7025.
	</t>		</t>
	<t>		<t pn="section-abstract-2">
	This memo provides extensions to the Path Computation Element		This memo provides extensions to the Path Computation Element
	communication Protocol (PCEP) for the support of the GMPLS control plane		Communication Protocol (PCEP) for the support of the GMPLS control plane
	to address those requirements.		to address those requirements.
	</t>		</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further
			information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc8779" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t pn="section-boilerplate.2-1">
			Copyright (c) 2020 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Simplified BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Simplified BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter
			" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-introduction">Introduction</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.1.2">
			<li pn="section-toc.1-1.1.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
			dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-terminology">
			Terminology</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.2">
			<t keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derive
			dContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-pcep-requirem
			ents-for-gmpls">PCEP Requirements for GMPLS</xref></t>
			</li>
			<li pn="section-toc.1-1.1.2.3">
			<t pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" forma
			t="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-requirements-applicability">Requi
			rements Applicability</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.1.2.3.2">
			<li pn="section-toc.1-1.1.2.3.2.1">
			<t keepWithNext="true" pn="section-toc.1-1.1.2.3.2.1.1"><xre
			f derivedContent="1.3.1" format="counter" sectionFormat="of" target="section-1.3
			.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-r
			equirements-on-the-path-co">Requirements on the Path Computation Request</xref><
			/t>
			</li>
			<li pn="section-toc.1-1.1.2.3.2.2">
			<t pn="section-toc.1-1.1.2.3.2.2.1"><xref derivedContent="1.
			3.2" format="counter" sectionFormat="of" target="section-1.3.2"/>.  <xref derive
			dContent="" format="title" sectionFormat="of" target="name-requirements-on-the-p
			ath-com">Requirements on the Path Computation Response</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.1.2.4">
			<t pn="section-toc.1-1.1.2.4.1"><xref derivedContent="1.4" forma
			t="counter" sectionFormat="of" target="section-1.4"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-existing-support-and-limita">Exis
			ting Support and Limitations for GMPLS in Base PCEP Objects</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.2">
			<t pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter
			" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-pcep-objects-and-extensions">PCEP Objects and
			Extensions</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.2.2">
			<li pn="section-toc.1-1.2.2.1">
			<t pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" forma
			t="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-gmpls-capability-advertisem">GMPL
			S Capability Advertisement</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.2.2.1.2">
			<li pn="section-toc.1-1.2.2.1.2.1">
			<t pn="section-toc.1-1.2.2.1.2.1.1"><xref derivedContent="2.
			1.1" format="counter" sectionFormat="of" target="section-2.1.1"/>.  <xref derive
			dContent="" format="title" sectionFormat="of" target="name-gmpls-computation-tlv
			-in-th">GMPLS Computation TLV in the Existing PCE Discovery Protocol</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.1.2.2">
			<t pn="section-toc.1-1.2.2.1.2.2.1"><xref derivedContent="2.
			1.2" format="counter" sectionFormat="of" target="section-2.1.2"/>.  <xref derive
			dContent="" format="title" sectionFormat="of" target="name-open-object-extension
			-gmpls">OPEN Object Extension GMPLS-CAPABILITY TLV</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.2.2.2">
			<t pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" forma
			t="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-rp-object-extension">RP Object Ex
			tension</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.3">
			<t pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" forma
			t="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-bandwidth-object-extensions">BAND
			WIDTH Object Extensions</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.4">
			<t pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" forma
			t="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-load-balancing-object-exten">LOAD
			-BALANCING Object Extensions</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.5">
			<t pn="section-toc.1-1.2.2.5.1"><xref derivedContent="2.5" forma
			t="counter" sectionFormat="of" target="section-2.5"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-end-points-object-extension">END-
			POINTS Object Extensions</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.2.2.5.2">
			<li pn="section-toc.1-1.2.2.5.2.1">
			<t pn="section-toc.1-1.2.2.5.2.1.1"><xref derivedContent="2.
			5.1" format="counter" sectionFormat="of" target="section-2.5.1"/>.  <xref derive
			dContent="" format="title" sectionFormat="of" target="name-generalized-endpoint-
			object">Generalized Endpoint Object Type</xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.5.2.2">
			<t pn="section-toc.1-1.2.2.5.2.2.1"><xref derivedContent="2.
			5.2" format="counter" sectionFormat="of" target="section-2.5.2"/>.  <xref derive
			dContent="" format="title" sectionFormat="of" target="name-end-points-tlv-extens
			ions">END-POINTS TLV Extensions</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.2.2.6">
			<t pn="section-toc.1-1.2.2.6.1"><xref derivedContent="2.6" forma
			t="counter" sectionFormat="of" target="section-2.6"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-iro-extension">IRO Extension</xre
			f></t>
			</li>
			<li pn="section-toc.1-1.2.2.7">
			<t pn="section-toc.1-1.2.2.7.1"><xref derivedContent="2.7" forma
			t="counter" sectionFormat="of" target="section-2.7"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-xro-extension">XRO Extension</xre
			f></t>
			</li>
			<li pn="section-toc.1-1.2.2.8">
			<t pn="section-toc.1-1.2.2.8.1"><xref derivedContent="2.8" forma
			t="counter" sectionFormat="of" target="section-2.8"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-lspa-extensions">LSPA Extensions<
			/xref></t>
			</li>
			<li pn="section-toc.1-1.2.2.9">
			<t pn="section-toc.1-1.2.2.9.1"><xref derivedContent="2.9" forma
			t="counter" sectionFormat="of" target="section-2.9"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-no-path-object-extension">NO-PATH
			Object Extension</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.2.2.9.2">
			<li pn="section-toc.1-1.2.2.9.2.1">
			<t pn="section-toc.1-1.2.2.9.2.1.1"><xref derivedContent="2.
			9.1" format="counter" sectionFormat="of" target="section-2.9.1"/>.  <xref derive
			dContent="" format="title" sectionFormat="of" target="name-extensions-to-no-path
			-vecto">Extensions to NO-PATH-VECTOR TLV</xref></t>
			</li>
			</ul>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.3">
			<t pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter
			" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-additional-error-types-and-">Additional Error
			-Types and Error-Values Defined</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter
			" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-manageability-consideration">Manageability Co
			nsiderations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.4.2">
			<li pn="section-toc.1-1.4.2.1">
			<t pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" forma
			t="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-control-of-function-through">Cont
			rol of Function through Configuration and Policy</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.2">
			<t pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" forma
			t="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-information-and-data-models">Info
			rmation and Data Models</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.3">
			<t pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" forma
			t="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-liveness-detection-and-moni">Live
			ness Detection and Monitoring</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.4">
			<t pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" forma
			t="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-verifying-correct-operation">Veri
			fying Correct Operation</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.5">
			<t pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" forma
			t="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-requirements-on-other-proto">Requ
			irements on Other Protocols and Functional Components</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.6">
			<t pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" forma
			t="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-impact-on-network-operation">Impa
			ct on Network Operation</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.5">
			<t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter
			" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xre
			f></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.5.2">
			<li pn="section-toc.1-1.5.2.1">
			<t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" forma
			t="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-pcep-objects">PCEP Objects</xref>
			</t>
			</li>
			<li pn="section-toc.1-1.5.2.2">
			<t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" forma
			t="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-endpoint-type-field-in-the-">Endp
			oint Type Field in the Generalized END-POINTS Object</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.3">
			<t pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" forma
			t="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-new-pcep-tlvs">New PCEP TLVs</xre
			f></t>
			</li>
			<li pn="section-toc.1-1.5.2.4">
			<t pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" forma
			t="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-rp-object-flag-field">RP Object F
			lag Field</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.5">
			<t pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" forma
			t="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-new-pcep-error-codes">New PCEP Er
			ror Codes</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.6">
			<t pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" forma
			t="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-new-bits-in-no-path-vector-">New
			Bits in NO-PATH-VECTOR TLV</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.7">
			<t pn="section-toc.1-1.5.2.7.1"><xref derivedContent="5.7" forma
			t="counter" sectionFormat="of" target="section-5.7"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-new-subobject-for-the-inclu">New
			Subobject for the Include Route Object</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.8">
			<t pn="section-toc.1-1.5.2.8.1"><xref derivedContent="5.8" forma
			t="counter" sectionFormat="of" target="section-5.8"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-new-subobject-for-the-exclu">New
			Subobject for the Exclude Route Object</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.9">
			<t pn="section-toc.1-1.5.2.9.1"><xref derivedContent="5.9" forma
			t="counter" sectionFormat="of" target="section-5.9"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-new-gmpls-capability-tlv-fl">New
			GMPLS-CAPABILITY TLV Flag Field</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.6">
			<t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter
			" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-security-considerations">Security Considerati
			ons</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter
			" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="titl
			e" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.7.2">
			<li pn="section-toc.1-1.7.2.1">
			<t pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" forma
			t="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-normative-references">Normative R
			eferences</xref></t>
			</li>
			<li pn="section-toc.1-1.7.2.2">
			<t pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" forma
			t="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent=""
			format="title" sectionFormat="of" target="name-informative-references">Informati
			ve References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.8">
			<t pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format
			="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedConte
			nt="" format="title" sectionFormat="of" target="name-load-balancing-usage-for-sd
			">LOAD-BALANCING Usage for SDH Virtual Concatenation</xref></t>
			</li>
			<li pn="section-toc.1-1.9">
			<t pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" se
			ctionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="ti
			tle" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
			</li>
			<li pn="section-toc.1-1.10">
			<t pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" s
			ectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="t
			itle" sectionFormat="of" target="name-contributors">Contributors</xref></t>
			</li>
			<li pn="section-toc.1-1.11">
			<t pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" s
			ectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="t
			itle" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xre
			f></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
	<t>Although <xref target="RFC4655" /> defines the PCE architecture and fra		<name slugifiedName="name-introduction">Introduction</name>
	mework for both MPLS and GMPLS networks, most preexisting PCEP RFCs <xref target		<t pn="section-1-1">Although the PCE architecture and framework for both M
	="RFC5440" />, <xref target="RFC5521" />, <xref target="RFC5541" />, <xref targe		PLS and GMPLS networks are defined in <xref target="RFC4655" format="default" se
	t="RFC5520" /> are focused on MPLS networks, and do not cover the wide range of		ctionFormat="of" derivedContent="RFC4655"/>, most pre-existing PCEP RFCs, such a
	GMPLS networks. This document complements these RFCs by addressing the extension		s <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC
	s required for GMPLS applications and routing requests, for example for Optical		5440"/>, <xref target="RFC5521" format="default" sectionFormat="of" derivedConte
	Transport Network (OTN) and Wavelength Switched Optical Network (WSON) networks.		nt="RFC5521"/>, <xref target="RFC5541" format="default" sectionFormat="of" deriv
	</t>		edContent="RFC5541"/>, and <xref target="RFC5520" format="default" sectionFormat
			="of" derivedContent="RFC5520"/>, are focused on MPLS networks and do not cover
	<t>The functional requirements to be addressed by the PCEP		the wide range of GMPLS networks. This document complements these RFCs by addres
	extensions to support these applications are fully described in <xref		sing the extensions required for GMPLS applications and routing requests, for ex
	target="RFC7025" /> and <xref target='RFC7449' />.		ample, for Optical Transport Networks (OTNs) and Wavelength Switched Optical Net
			works (WSONs).</t>
			<t pn="section-1-2">The functional requirements to be addressed by the PCE
			P
			extensions to support these applications are fully described in <xref targ
			et="RFC7025" format="default" sectionFormat="of" derivedContent="RFC7025"/> and
			<xref target="RFC7449" format="default" sectionFormat="of" derivedContent="RFC74
			49"/>.
	</t>		</t>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1
	<section title ="Terminology">		">
			<name slugifiedName="name-terminology">Terminology</name>
	<t>		<t pn="section-1.1-1">
	This document uses terminologies from the PCE architecture docume		This document uses terminologies from the PCE architecture docume
	nt <xref target="RFC4655"/>, the PCEP documents including <xref target="RFC5440"		nt <xref target="RFC4655" format="default" sectionFormat="of" derivedContent="RF
	/>, <xref target="RFC5521"/>, <xref target="RFC5541"/>, <xref target="RFC5520"/>		C4655"/>; the PCEP documents including <xref target="RFC5440" format="default" s
	, <xref target="RFC7025"/> and <xref target="RFC7449"/>,		ectionFormat="of" derivedContent="RFC5440"/>, <xref target="RFC5521" format="def
	and the GMPLS documents such as <xref		ault" sectionFormat="of" derivedContent="RFC5521"/>, <xref target="RFC5541" form
	target="RFC3471"/>, <xref target="RFC3473"/> and so		at="default" sectionFormat="of" derivedContent="RFC5541"/>, <xref target="RFC552
	on. Note that it is expected the reader is familiar		0" format="default" sectionFormat="of" derivedContent="RFC5520"/>, <xref target=
			"RFC7025" format="default" sectionFormat="of" derivedContent="RFC7025"/>, and <x
			ref target="RFC7449" format="default" sectionFormat="of" derivedContent="RFC7449
			"/>;
			and the GMPLS documents such as <xref target="RFC3471" format="de
			fault" sectionFormat="of" derivedContent="RFC3471"/>, <xref target="RFC3473" for
			mat="default" sectionFormat="of" derivedContent="RFC3473"/>, and so
			on. Note that the reader is expected to be familiar
	with these documents.		with these documents.
	The following abbreviations are used in this document		The following abbreviations are used in this document:
			</t>
	<list style="hanging" hangIndent="6">		<dl newline="false" spacing="normal" indent="10" pn="section-1.1-2">
	<t hangText="ODU"> ODU Optical Channel Data Unit <xref target=		<dt pn="section-1.1-2.1">ERO:</dt>
	"G.709-v3" /></t>		<dd pn="section-1.1-2.2">Explicit Route Object</dd>
	<t hangText="OTN"> Optical Transport Network <xref target="G.7		<dt pn="section-1.1-2.3">IRO:</dt>
	09-v3" /></t>		<dd pn="section-1.1-2.4">Include Route Object</dd>
	<t hangText="L2SC"> Layer-2 Switch Capable <xref target="RFC34		<dt pn="section-1.1-2.5">L2SC:</dt>
	71" /></t>		<dd pn="section-1.1-2.6">Layer 2 Switch Capable <xref target="RFC3471"
	<t hangText="TDM"> Time-Division Multiplex Capable <xref targe		format="default" sectionFormat="of" derivedContent="RFC3471"/></dd>
	t="RFC3471" /></t>		<dt pn="section-1.1-2.7">LSC:</dt>
	<t hangText="LSC"> Lambda Switch Capable <xref target="RFC3471		<dd pn="section-1.1-2.8">Lambda Switch Capable <xref target="RFC3471"
	" /></t>		format="default" sectionFormat="of" derivedContent="RFC3471"/></dd>
	<t hangText="SONET"> Synchronous Optical Networking </t>		<dt pn="section-1.1-2.9">LSP:</dt>
	<t hangText="SDH"> Synchronous Digital Hierarchy </t>		<dd pn="section-1.1-2.10">Label Switched Path</dd>
	<t hangText="PCC"> Path Computation Client</t>		<dt pn="section-1.1-2.11">LSPA:</dt>
	<t hangText="RSVP-TE"> Resource Reservation Protocol - Traffi		<dd pn="section-1.1-2.12">LSP Attribute</dd>
	c Engineering</t>		<dt pn="section-1.1-2.13">MEF:</dt>
	<t hangText="LSP"> Label Switched Path</t>		<dd pn="section-1.1-2.14">Metro Ethernet Forum</dd>
	<t hangText="TE-LSP">Traffic Engineering LSP</t>		<dt pn="section-1.1-2.15">MT:</dt>
	<t hangText="IRO">Include Route Object</t>		<dd pn="section-1.1-2.16">Multiplier <xref target="RFC4328" format="de
	<t hangText="ERO">Explicit Route Object</t>		fault" sectionFormat="of" derivedContent="RFC4328"/> <xref target="RFC4606" form
	<t hangText="XRO"> eXclude Route Object</t>		at="default" sectionFormat="of" derivedContent="RFC4606"/></dd>
	<t hangText="RRO"> Record Route Object</t>		<dt pn="section-1.1-2.17">NCC:</dt>
	<t hangText="LSPA"> LSP Attribute</t>		<dd pn="section-1.1-2.18">Number of Contiguous Components <xref target
	<t hangText="SRLG">Shared Risk Link Group</t>		="RFC4606" format="default" sectionFormat="of" derivedContent="RFC4606"/></dd>
	<t hangText="NVC">Number of Virtual Components <xref target="R		<dt pn="section-1.1-2.19">NVC:</dt>
	FC4328" /><xref target="RFC4606" /></t>		<dd pn="section-1.1-2.20">Number of Virtual Components <xref target="R
	<t hangText="NCC">Number of Contiguous Components <xref target		FC4328" format="default" sectionFormat="of" derivedContent="RFC4328"/> <xref tar
	="RFC4328" /><xref target="RFC4606" /></t>		get="RFC4606" format="default" sectionFormat="of" derivedContent="RFC4606"/></dd
	<t hangText="MT">Multiplier <xref target="RFC4328" /><xref tar		>
	get="RFC4606" /></t>		<dt pn="section-1.1-2.21">ODU:</dt>
	<t hangText="RCC">Requested Contiguous Concatenation <xref tar		<dd pn="section-1.1-2.22">Optical Data Unit <xref target="G.709-v3" fo
	get="RFC4606" /></t>		rmat="default" sectionFormat="of" derivedContent="G.709-v3"/></dd>
	<t hangText="PCReq">Path Computation Request <xref target="RFC		<dt pn="section-1.1-2.23">OTN:</dt>
	5440" /></t>		<dd pn="section-1.1-2.24">Optical Transport Network <xref target="G.70
	<t hangText="PCRep">Path Computation Reply <xref target="RFC5		9-v3" format="default" sectionFormat="of" derivedContent="G.709-v3"/></dd>
	440" /></t>		<dt pn="section-1.1-2.25">P2MP:</dt>
	<t hangText="MEF">Metro Ethernet Forum</t>		<dd pn="section-1.1-2.26">Point-to-Multipoint</dd>
	<t hangText="SSON">Spectrum-Switched Optical Network</t>		<dt pn="section-1.1-2.27">PCC:</dt>
	<t hangText="P2MP">Point to Multi-Point</t>		<dd pn="section-1.1-2.28">Path Computation Client</dd>
			<dt pn="section-1.1-2.29">PCRep:</dt>
	</list>		<dd pn="section-1.1-2.30">Path Computation Reply <xref target="RFC544
	</t>		0" format="default" sectionFormat="of" derivedContent="RFC5440"/></dd>
			<dt pn="section-1.1-2.31">PCReq:</dt>
	<t>		<dd pn="section-1.1-2.32">Path Computation Request <xref target="RFC54
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO		40" format="default" sectionFormat="of" derivedContent="RFC5440"/></dd>
	T",		<dt pn="section-1.1-2.33">RCC:</dt>
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		<dd pn="section-1.1-2.34">Requested Contiguous Concatenation <xref tar
	"MAY", and "OPTIONAL" in this document are to be interpreted		get="RFC4606" format="default" sectionFormat="of" derivedContent="RFC4606"/></dd
	as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/		>
	> when,		<dt pn="section-1.1-2.35">RRO:</dt>
			<dd pn="section-1.1-2.36">Record Route Object</dd>
			<dt pn="section-1.1-2.37">RSVP-TE:</dt>
			<dd pn="section-1.1-2.38">Resource Reservation Protocol - Traffic Eng
			ineering</dd>
			<dt pn="section-1.1-2.39">SDH:</dt>
			<dd pn="section-1.1-2.40">Synchronous Digital Hierarchy </dd>
			<dt pn="section-1.1-2.41">SONET:</dt>
			<dd pn="section-1.1-2.42">Synchronous Optical Network</dd>
			<dt pn="section-1.1-2.43">SRLG:</dt>
			<dd pn="section-1.1-2.44">Shared Risk Link Group</dd>
			<dt pn="section-1.1-2.45">SSON:</dt>
			<dd pn="section-1.1-2.46">Spectrum-Switched Optical Network</dd>
			<dt pn="section-1.1-2.47">TDM:</dt>
			<dd pn="section-1.1-2.48">Time-Division Multiplex Capable <xref target
			="RFC3471" format="default" sectionFormat="of" derivedContent="RFC3471"/></dd>
			<dt pn="section-1.1-2.49">TE-LSP:</dt>
			<dd pn="section-1.1-2.50">Traffic Engineered LSP</dd>
			<dt pn="section-1.1-2.51">XRO:</dt>
			<dd pn="section-1.1-2.52">Exclude Route Object</dd>
			</dl>
			<t pn="section-1.1-3">
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
			"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMEND
			ED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document ar
			e to be interpreted
			as described in BCP 14 <xref target="RFC2119" format="default" sectionF
			ormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" se
			ctionFormat="of" derivedContent="RFC8174"/> when,
	and only when, they appear in all capitals, as shown here.		and only when, they appear in all capitals, as shown here.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-1.2
	<section title="PCEP Requirements for GMPLS">		">
	<t>The document <xref target="RFC7025" /> describes the set of		<name slugifiedName="name-pcep-requirements-for-gmpls">PCEP Requirements
	PCEP requirements to support GMPLS TE-LSPs. This document		for GMPLS</name>
	assumes a significant familiarity with <xref target="RFC7025"		<t pn="section-1.2-1"><xref target="RFC7025" format="default" sectionFor
	/> and existing PCEP extensions. As a short		mat="of" derivedContent="RFC7025"/> describes the set of PCEP
	overview, those requirements can be broken down into the following categ		requirements that support GMPLS TE-LSPs. This document assumes a
	ories.		significant familiarity with <xref target="RFC7025" format="default" sec
			tionFormat="of" derivedContent="RFC7025"/>
			and existing PCEP extensions. As a short overview, those requirements
			can be broken down into the following categories.
	</t>		</t>
	<t>		<ul spacing="normal" bare="false" empty="false" pn="section-1.2-2">
	<list style="symbols">		<li pn="section-1.2-2.1">Which data flow is switched by the LSP: a com
	<t>Which data flow is switched by the LSP: a combination		bination
	of Switching type (for instance		of a switching type (for instance,
	L2SC or TDM ), LSP Encoding		L2SC or TDM), an LSP encoding
	type (e.g., Ethernet, SONET/SDH) and sometimes the Signal		type (e.g., Ethernet, SONET/SDH), and sometimes the signal
	Type (e.g., in case of TDM/LSC switching capability).</t>		type (e.g., in case of a TDM or an LSC switching capability).</li>
	<t>Data flow specific traffic parameters, which are		<li pn="section-1.2-2.2">Data-flow-specific traffic parameters, which
	technology specific. For instance, in SDH/SONET and <xref		are
	target="G.709-v3" /> OTN networks the Concatenation Type and the Co		technology specific. For instance, in SDH/SONET and OTN networks <xr
	ncatenation Number have an influence on the switched data and on which link it c		ef target="G.709-v3" format="default" sectionFormat="of" derivedContent="G.709-v
	an be supported</t>		3"/>, the concatenation type and the concatenation number have an influence on t
	<t>Support for asymmetric bandwidth requests.</t>		he switched data and on which link it can be supported.</li>
	<t>Support for unnumbered interface identifiers, as		<li pn="section-1.2-2.3">Support for asymmetric bandwidth requests.</l
	defined in <xref target="RFC3477"></xref></t>		i>
	<t>Label information and technology specific label(s) such		<li pn="section-1.2-2.4">Support for unnumbered interface identifiers,
	as wavelength labels as defined in <xref target="RFC6205"		as
	/>. A PCC should also be able to		defined in <xref target="RFC3477" format="default" sectionFormat="of
			" derivedContent="RFC3477"/>.</li>
			<li pn="section-1.2-2.5">Label information and technology-specific lab
			el(s) such
			as wavelength labels as defined in <xref target="RFC6205" format="de
			fault" sectionFormat="of" derivedContent="RFC6205"/>. A PCC should also be able
			to
	specify a label restriction similar to the one supported		specify a label restriction similar to the one supported
	by RSVP-TE in <xref target="RFC3473" />.</t>		by RSVP-TE in <xref target="RFC3473" format="default" sectionFormat
	<t>Ability to indicate the requested granularity for the		="of" derivedContent="RFC3473"/>.</li>
	path ERO: node, link or label. This is to allow the use of the expli		<li pn="section-1.2-2.6">Ability to indicate the requested granularity
	cit label control feature of RSVP-TE.</t>		for the
	</list>		path ERO: node, link, or label. This is to allow the use of the expl
	The requirements of <xref target="RFC7025" /> apply to several objects		icit label control feature of RSVP-TE.</li>
	conveyed by PCEP, this is described in <xref target="requirement-map" />.		</ul>
	Some of the requirements of <xref target="RFC7025" /> are		<t pn="section-1.2-3">
			The requirements of <xref target="RFC7025" format="default" sectionFor
			mat="of" derivedContent="RFC7025"/> apply to several objects conveyed by PCEP; t
			his is described in <xref target="requirement-map" format="default" sectionForma
			t="of" derivedContent="Section 1.3"/>.
			Some of the requirements of <xref target="RFC7025" format="default" se
			ctionFormat="of" derivedContent="RFC7025"/> are
	already supported in existing documents, as described in		already supported in existing documents, as described in
	<xref target="existing-support" />.		<xref target="existing-support" format="default" sectionFormat="of" de rivedContent="Section 1.4"/>.
	</t>		</t>
	<t>		<t pn="section-1.2-4">
	This document describes a set of PCEP		This document describes a set of PCEP
	extensions, including new object types, TLVs, encodings, error		extensions, including new object types, TLVs, encodings, error
	codes and procedures, in order to fulfill the aforementioned		codes, and procedures, in order to fulfill the aforementioned
	requirements not covered in existing RFCs.</t>		requirements not covered in existing RFCs.</t>
	</section>		</section>
	<section title="Requirements Applicability" anchor="requirement-map">		<section anchor="requirement-map" numbered="true" toc="include" removeInRF
	<t> This section follows the organization of <xref target="RFC7025" /> S		C="false" pn="section-1.3">
	ection 3 and indicates, for each requirement, the affected piece of information		<name slugifiedName="name-requirements-applicability">Requirements Appli
	carried by PCEP and its scope.</t>		cability</name>
	<section title="Requirements on Path Computation Request">		<t pn="section-1.3-1"> This section follows the organization of <xref ta
	<t>		rget="RFC7025" sectionFormat="comma" section="3" format="default" derivedLink="h
	<list style="hanging" hangIndent="6"><t hangText="(1)">		ttps://rfc-editor.org/rfc/rfc7025#section-3" derivedContent="RFC7025"/> and indi
	Switching capability/type: as described in <xref		cates, for each requirement, the affected piece of information carried by PCEP a
	target="RFC3471" /> this piece of information is used		nd its scope.</t>
	with the Encoding Type and Signal Type to fully describe		<section numbered="true" toc="include" removeInRFC="false" pn="section-1
			.3.1">
			<name slugifiedName="name-requirements-on-the-path-co">Requirements on
			the Path Computation Request</name>
			<ol spacing="normal" type="(%d)" start="1" pn="section-1.3.1-1">
			<li pn="section-1.3.1-1.1" derivedCounter="(1)">Switching capability
			/type: As described in <xref target="RFC3471" format="default" sectionFormat="of
			" derivedContent="RFC3471"/>, this piece of information is used
			with the encoding type and signal type to fully describe
	the switching technology and data carried by the		the switching technology and data carried by the
	TE-LSP. This is applicable to the TE-LSP itself and also to the TE		TE-LSP. This is applicable to the TE-LSP itself and also to the TE
	-LSP endpoint (Carried in the END-POINTS object for MPLS networks in <xref targe		-LSP endpoint (carried in the END-POINTS object for MPLS networks in <xref targe
	t="RFC5440" />) when considering multiple network layers. Inter-layer path compu		t="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>) when
	tation requirements are addressed in in <xref target="RFC8282" /> which addressi		considering multiple network layers.
	ng the TE-LSP itself, but the TE-LSP endpoints are not addressed.
	</t>
	<t hangText="(2)">
	Encoding type: see (1).
	</t>
	<t hangText="(3)">
	Signal type: see (1).
	</t>
	<t hangText="(4)">		Inter-layer path computation requirements are addressed in <xref target="RFC828
	Concatenation type: this parameter and the Concatenation		2" format="default" sectionFormat="of" derivedContent="RFC8282"/>, which focuses
	Number (5) are specific to some TDM (SDH and ODU)		on the TE-LSP itself but
	switching technology. They MUST be described together		does not address the TE-LSP endpoints.
			</li>
			<li pn="section-1.3.1-1.2" derivedCounter="(2)">Encoding type: See (
			1).
			</li>
			<li pn="section-1.3.1-1.3" derivedCounter="(3)">Signal type: See (1)
			.
			</li>
			<li pn="section-1.3.1-1.4" derivedCounter="(4)">Concatenation type:
			This parameter and the concatenation
			number (see (5)) are specific to some TDM (SDH and ODU)
			switching technologies. They <bcp14>MUST</bcp14> be described toge
			ther
	and are used to derive the requested resource allocation		and are used to derive the requested resource allocation
	for the TE-LSP. It is scoped to the TE-LSP and is related		for the TE-LSP. It is scoped to the TE-LSP and is related
	to the <xref target="RFC5440" /> BANDWIDTH object in MPLS networks		to the BANDWIDTH object <xref target="RFC5440" format="default" se
	. See <xref		ctionFormat="of" derivedContent="RFC5440"/> in MPLS networks. See concatenation
	target="RFC4606" /> and <xref		information in <xref target="RFC4606" format="default" sectionForm
	target="RFC4328" /> about concatenation		at="of" derivedContent="RFC4606"/> and <xref target="RFC4328" format="default" s
	information.		ectionFormat="of" derivedContent="RFC4328"/>.
	</t>		</li>
			<li pn="section-1.3.1-1.5" derivedCounter="(5)">Concatenation number
	<t hangText="(5)">		: See (4).
	Concatenation number: see (4).		</li>
	</t>		<li pn="section-1.3.1-1.6" derivedCounter="(6)">Technology-specific
			label(s): As described in <xref target="RFC3471" format="default" sectionFormat=
	<t hangText="(6)">		"of" derivedContent="RFC3471"/>, the GMPLS labels are specific to each switching
	Technology-specific label(s): as described in <xref target="RFC3471		technology. They can be specified on each link and also on the TE-LSP endpoints
	" /> the GMPLS Labels are specific to each switching technology. They can be spe		, in WSON networks, for instance, as described in <xref target="RFC6163" format=
	cified on each link and also on the TE-LSP endpoints , in WSON networks for inst		"default" sectionFormat="of" derivedContent="RFC6163"/>. The label restriction c
	ance, as described in <xref target="RFC6163" />. The label restriction can apply		an apply to endpoints, and on each hop, the related PCEP objects are END-POINTS,
	to endpoints and on each hop, the related PCEP objects are END-POINTS, IRO, XRO		IRO, XRO, and RRO.
	and RRO.		</li>
	</t>		<li pn="section-1.3.1-1.7" derivedCounter="(7)">End-to-End (E2E) pat
			h protection type: As defined in <xref target="RFC4872" format="default" section
	<t hangText="(7)">		Format="of" derivedContent="RFC4872"/>, this is applicable to the TE-LSP. In MPL
	End-to-End (E2E) path protection type: as defined in <xref target="		S networks, the related PCEP object is LSPA (carrying local protection informati
	RFC4872"/>, this is applicable to the TE-LSP. In MPLS networks the related PCEP		on).
	object is LSPA (carrying local protection information).		</li>
	</t>		<li pn="section-1.3.1-1.8" derivedCounter="(8)">Administrative group
			: As defined in <xref target="RFC3630" format="default" sectionFormat="of" deriv
	<t hangText="(8)">		edContent="RFC3630"/>, this information is already carried in the LSPA object.
	Administrative group: as defined in <xref target="RFC3630"/>, this		</li>
	information is already carried in the LSPA object.		<li pn="section-1.3.1-1.9" derivedCounter="(9)">Link protection type
	</t>		: As defined in <xref target="RFC4872" format="default" sectionFormat="of" deriv
			edContent="RFC4872"/>, this is applicable to the TE-LSP and is carried in associ
	<t hangText="(9)">		ation with the E2E path protection type.
	Link protection type: as defined in <xref target="RFC4872"/>, this		</li>
	is applicable to the TE-LSP and is carried in association with the E2E path prot		<li pn="section-1.3.1-1.10" derivedCounter="(10)">Support for unnumb
	ection type.		ered interfaces: As defined in <xref target="RFC3477" format="default" sectionFo
	</t>		rmat="of" derivedContent="RFC3477"/>. Its scope and related objects are the same
			as labels.
	<t hangText="(10)">		</li>
	Support for unnumbered interfaces: as defined in <xref target="RFC3		<li pn="section-1.3.1-1.11" derivedCounter="(11)">Support for asymme
	477"/>. Its scope and related objects are the same as labels		tric bandwidth requests: As defined in <xref target="RFC6387" format="default" s
	</t>		ectionFormat="of" derivedContent="RFC6387"/>, the scope is similar to (4).
			</li>
	<t hangText="(11)">		<li pn="section-1.3.1-1.12" derivedCounter="(12)">Support for explic
	Support for asymmetric bandwidth requests: as defined <xref target=		it label control during the path
	"RFC6387"/>, the scope is similar to (4)		computation: This affects the TE-LSP and the amount of information
	</t>		returned in the ERO.
			</li>
	<t hangText="(12)">		<li pn="section-1.3.1-1.13" derivedCounter="(13)"> Support of label
	Support for explicit label control during the path computation. Thi		restrictions in the requests/responses:
	s affects the TE-LSP and amount of information returned in the ERO.
	</t>
	<t hangText="(13)">
	Support of label restrictions in the requests/responses:
	This is described in (6).		This is described in (6).
	</t>		</li>
	</list>		</ol>
	</t>
	</section>		</section>
	<section title="Requirements on Path Computation Response">		<section numbered="true" toc="include" removeInRFC="false" pn="section-1
	<t><list style="hanging" hangIndent="5"><t hangText="(1)">		.3.2">
	Path computation with concatenation: This is related to		<name slugifiedName="name-requirements-on-the-path-com">Requirements o
	Path Computation request requirement (4). In addition		n the Path Computation Response</name>
	there is a specific type of concatenation called virtual		<ol spacing="normal" type="(%d)" start="1" pn="section-1.3.2-1">
	concatenation that allows different routes to be used		<li pn="section-1.3.2-1.1" derivedCounter="(1)">Path computation wit
			h concatenation: This is related to
			the Path Computation request requirement (4). In addition,
			there is a specific type of concatenation, called virtual
			concatenation, that allows different routes to be used
	between the endpoints. It is similar to the semantic and scope of th e LOAD-BALANCING in MPLS networks.		between the endpoints. It is similar to the semantic and scope of th e LOAD-BALANCING in MPLS networks.
	</t>		</li>
	<t hangText="(2)">		<li pn="section-1.3.2-1.2" derivedCounter="(2)">Label constraint: Th
	Label constraint: The PCE should be able to include Labels in the pat		e PCE should be able to include labels in the path returned to the PCC; the rela
	h returned to the PCC, the related object is the ERO object.		ted object is the ERO object.
	</t>		</li>
			<li pn="section-1.3.2-1.3" derivedCounter="(3)">Roles of the routes:
	<t hangText="(3)">		As defined in <xref target="RFC4872" format="default" sectionFormat="of" derive
	Roles of the routes: as defined in <xref target="RFC4872"/>, this is		dContent="RFC4872"/>, this is applicable to the TE-LSP and is carried in associa
	applicable to the TE-LSP and is carried in association with the E2E path protec		tion with the E2E path protection type.
	tion type.		</li>
	</t>		</ol>
	</list>
	</t>
	</section>		</section>
	</section> <!-- End Requirements on Protocol Objects -->		</section>
	<section title="Existing Support for GMPLS in Base PCEP Objects and its Li		<section anchor="existing-support" numbered="true" toc="include" removeInR
	mitations" anchor="existing-support">		FC="false" pn="section-1.4">
	<t> The support provided by specifications in <xref target="RFC8282" /		<name slugifiedName="name-existing-support-and-limita">Existing Support
	> and <xref target="RFC5440" /> for the		and Limitations for GMPLS in Base PCEP Objects</name>
	requirements listed in <xref target="RFC7025" /> is summarized in <xre		<t pn="section-1.4-1"> The support provided by specifications in <xref t
	f target="rfc7025_pcreq_reqss" /> and <xref target="rfc7025_pcrep_reqss"/>. In		arget="RFC8282" format="default" sectionFormat="of" derivedContent="RFC8282"/> a
	some cases the support may not be complete, as noted, and additional s		nd <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RF
	upport		C5440"/> for the
	need to be provided in this specification.		requirements listed in <xref target="RFC7025" format="default" section
			Format="of" derivedContent="RFC7025"/> is summarized in Tables <xref target="rfc
	</t>		7025_pcreq_reqss" format="counter" sectionFormat="of" derivedContent="1"/> and <
			xref target="rfc7025_pcrep_reqss" format="counter" sectionFormat="of" derivedCon
	<texttable anchor='rfc7025_pcreq_reqss' suppress-title='false'		tent="2"/>. In
	style='none' title='RFC7025 Section 3.1		some cases, the support may not be complete, as noted, and additional
	requirements support'>		support
	<ttcol align='left'></ttcol>		needs to be provided as indicated in this specification.
	<ttcol align='left'></ttcol>
	<ttcol align='left'></ttcol>
	<c>Req. </c><c> Name
	</c><c> Support </c>
	<c> 1 </c><c> Switching capability/type
	</c><c> SWITCH-LAYER (RFC8282) </c>
	<c> 2 </c><c> Encoding type
	</c><c> SWITCH-LAYER (RFC8282) </c>
	<c> 3 </c><c> Signal type
	</c><c> SWITCH-LAYER (RFC8282) </c>
	<c> 4 </c><c> Concatenation type
	</c><c> No </c>
	<c> 5 </c><c> Concatenation number
	</c><c> No </c>
	<c> 6 </c><c> Technology-specific label
	</c><c> (Partial) ERO (RFC5440)</c>
	<c> 7 </c><c> End-to-End (E2E) path protection type
	</c><c> No </c>
	<c> 8 </c><c> Administrative group
	</c><c> LSPA (RFC5440) </c>
	<c> 9 </c><c> Link protection type
	</c><c> No </c>
	<c> 10 </c><c> Support for unnumbered interfaces
	</c><c> (Partial) ERO (RFC5440)</c>
	<c> 11 </c><c> Support for asymmetric bandwidth requests
	</c><c> No </c>
	<c> 12 </c><c> Support for explicit label control during the path c
	omputation </c><c> No </c>
	<c> 13 </c><c> Support of label restrictions in the requests/respon
	ses </c><c> No </c>
	</texttable>
	<t><vspace blankLines="2"/></t>
	<texttable anchor='rfc7025_pcrep_reqss' suppress-title='false'
	style='none' title='RFC7025 Section 3.2
	requirements support'>
	<ttcol align='left'></ttcol>
	<ttcol align='left'></ttcol>
	<ttcol align='left'></ttcol>
	<c>Req. </c><c> Name </c><c> Support </c>
	<c>1</c><c>Path computation with concatenation </c><c> No </c>
	<c>2</c><c>Label constraint </c><c> No </c>
	<c>3</c><c>Roles of the routes </c><c> No </c>
	</texttable>
	<t> As described in <xref target="requirement-map" /> PCEP as of <xref t
	arget="RFC5440"></xref>, <xref target="RFC5521"></xref> and <xref target="RFC828
	2" />, supports the following objects, included in requests and responses, rela
	ted to the described requirements.</t>
	<t>From <xref target="RFC5440"></xref>:
	<list style='symbols'>
	<t>END-POINTS: related to requirements (1, 2, 3, 6, 10 and 13). The o
	bject only supports numbered endpoints. The context specifies whether they are n
	ode identifiers or numbered interfaces.</t>
	<t>BANDWIDTH: related to requirements (4, 5 and 11). The data rate is
	encoded in the bandwidth object (as IEEE 32 bit float). <xref target="RFC5440" /
	> does not include the ability to convey an encoding proper to all GMPLS-control
	led networks.</t>
	<t>ERO: related to requirements (6, 10, 12 and 13). The ERO
	content is defined in RSVP in
	<xref target="RFC3209" /><xref target="RFC3473" /><xref target="RFC347
	7" /><xref target="RFC7570" />
	and supports all the requirements already. </t>
	<t>LSPA: related to requirements (7, 8 and 9). The requirement 8 (setu
	p and holding priorities) is already supported.</t>
	</list></t>
	<t>From <xref target="RFC5521"></xref>:
	<list style='symbols'>
	<t>XRO:
	<list style='symbols'>
	<t>This object allows excluding (strict or not) resources and is rel
	ated to requirements (6, 10 and 13). It also includes the requested diversity (n
	ode, link or SRLG).</t>
	<t>When the F bit is set, the request indicates that the
	existing path has failed and the resources present in the RRO can be
	reused.
	</t></list>
	</t>
	</list>
	</t>		</t>
	<t>From <xref target="RFC8282"></xref>:<list style='symbols'>		<table anchor="rfc7025_pcreq_reqss" align="center" pn="table-1">
	<t>SWITCH-LAYER: addresses requirements (1, 2 and 3) for the TE-LSP and		<name slugifiedName="name-requirements-support-per-rf">Requirements Su
	indicates which layer(s) should be considered. The object can be used to repres		pport per RFC 7025, Section 3.1</name>
	ent the RSVP-TE generalized label request. It does not address the endpoints cas		<thead>
	e of requirements (1, 2 and 3).</t>		<tr>
	<t>REQ-ADAP-CAP: indicates the adaptation capabilities requested, can al		<th align="left" colspan="1" rowspan="1">Req.</th>
	so be used for the endpoints in case of mono-layer computation</t>		<th align="left" colspan="1" rowspan="1">Name</th>
	</list></t>		<th align="left" colspan="1" rowspan="1">Support</th>
	<t>		</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 1 </td>
			<td align="left" colspan="1" rowspan="1"> Switching capability/typ
			e </td>
			<td align="left" colspan="1" rowspan="1"> SWITCH-LAYER (RFC 8282)
			</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 2 </td>
			<td align="left" colspan="1" rowspan="1"> Encoding type
			</td>
			<td align="left" colspan="1" rowspan="1"> SWITCH-LAYER (RFC 8282)
			</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 3 </td>
			<td align="left" colspan="1" rowspan="1"> Signal type
			</td>
			<td align="left" colspan="1" rowspan="1"> SWITCH-LAYER (RFC 8282)
			</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 4 </td>
			<td align="left" colspan="1" rowspan="1"> Concatenation type
			</td>
			<td align="left" colspan="1" rowspan="1"> No <
			/td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 5 </td>
			<td align="left" colspan="1" rowspan="1"> Concatenation number
			</td>
			<td align="left" colspan="1" rowspan="1"> No <
			/td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 6 </td>
			<td align="left" colspan="1" rowspan="1"> Technology-specific labe
			l </td>
			<td align="left" colspan="1" rowspan="1"> (Partial) ERO (RFC 5440)
			</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 7 </td>
			<td align="left" colspan="1" rowspan="1"> End-to-End (E2E) path pr
			otection type </td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 8 </td>
			<td align="left" colspan="1" rowspan="1"> Administrative group
			</td>
			<td align="left" colspan="1" rowspan="1"> LSPA (RFC 5440) </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 9 </td>
			<td align="left" colspan="1" rowspan="1"> Link protection type
			</td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 10 </td>
			<td align="left" colspan="1" rowspan="1"> Support for unnumbered i
			nterfaces </td>
			<td align="left" colspan="1" rowspan="1"> (Partial) ERO (RFC 5440)
			</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 11 </td>
			<td align="left" colspan="1" rowspan="1"> Support for asymmetric b
			andwidth requests </td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 12 </td>
			<td align="left" colspan="1" rowspan="1"> Support for explicit lab
			el control during the path computation </td>
			<td align="left" colspan="1" rowspan="1"> No</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"> 13 </td>
			<td align="left" colspan="1" rowspan="1"> Support of label restric
			tions in the requests/responses </td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			</tbody>
			</table>
			<table anchor="rfc7025_pcrep_reqss" align="center" pn="table-2">
			<name slugifiedName="name-requirements-support-per-rfc">Requirements S
			upport per RFC 7025, Section 3.2</name>
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Req.</th>
			<th align="left" colspan="1" rowspan="1">Name</th>
			<th align="left" colspan="1" rowspan="1">Support</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">1</td>
			<td align="left" colspan="1" rowspan="1">Path computation with con
			catenation </td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">2</td>
			<td align="left" colspan="1" rowspan="1">Label constraint
			</td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">3</td>
			<td align="left" colspan="1" rowspan="1">Roles of the routes
			</td>
			<td align="left" colspan="1" rowspan="1"> No </td>
			</tr>
			</tbody>
			</table>
			<t pn="section-1.4-4">Per <xref target="requirement-map" format="default
			" sectionFormat="of" derivedContent="Section 1.3"/>, PCEP (as
			described in <xref target="RFC5440" format="default" sectionFormat="of"
			derivedContent="RFC5440"/>, <xref target="RFC5521" format="default" sectionForma
			t="of" derivedContent="RFC5521"/>, and <xref target="RFC8282" format="default" s
			ectionFormat="of" derivedContent="RFC8282"/>) supports the following objects, in
			cluded in
			requests and responses, that are related to the described
			requirements.</t>
			<t pn="section-1.4-5">From <xref target="RFC5440" format="default" secti
			onFormat="of" derivedContent="RFC5440"/>:
			</t>
			<ul spacing="normal" empty="true" bare="false" pn="section-1.4-6">
			<li pn="section-1.4-6.1">
			<dl newline="false" spacing="normal" pn="section-1.4-6.1.1">
			<dt pn="section-1.4-6.1.1.1">END-POINTS:</dt>
			<dd pn="section-1.4-6.1.1.2">related to requirements 1, 2, 3, 6, 1
			0, and 13. The object only supports numbered endpoints. The context specifies wh
			ether they are node identifiers or numbered interfaces.</dd>
			<dt pn="section-1.4-6.1.1.3">BANDWIDTH:</dt>
			<dd pn="section-1.4-6.1.1.4">related to requirements 4, 5, and 11.
			The data rate is encoded in the BANDWIDTH object (as an IEEE 32-bit float). <xr
			ef target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"
			/> does not include the ability to convey an encoding proper to all GMPLS-contro
			lled networks.</dd>
			<dt pn="section-1.4-6.1.1.5">ERO:</dt>
			<dd pn="section-1.4-6.1.1.6">related to requirements 6, 10, 12, an
			d 13. The ERO
			content is defined in RSVP in
			<xref target="RFC3209" format="default" sectionFormat="of" derivedCont
			ent="RFC3209"/>, <xref target="RFC3473" format="default" sectionFormat="of" deri
			vedContent="RFC3473"/>, <xref target="RFC3477" format="default" sectionFormat="o
			f" derivedContent="RFC3477"/>, and <xref target="RFC7570" format="default" secti
			onFormat="of" derivedContent="RFC7570"/> and
			already supports all of the requirements. </dd>
			<dt pn="section-1.4-6.1.1.7">LSPA:</dt>
			<dd pn="section-1.4-6.1.1.8">related to requirements 7, 8, and 9.
			Requirement 8 (Administrative group) is already supported.</dd>
			</dl>
			</li>
			</ul>
			<t pn="section-1.4-7">From <xref target="RFC5521" format="default" secti
			onFormat="of" derivedContent="RFC5521"/>:</t>
			<ul spacing="normal" empty="true" bare="false" pn="section-1.4-8">
			<li pn="section-1.4-8.1">
			<t pn="section-1.4-8.1.1">XRO:
			</t>
			<ul spacing="normal" bare="false" empty="false" pn="section-1.4-8.1.
			2">
			<li pn="section-1.4-8.1.2.1">This object allows excluding (strict
			or not) resources and is related to requirements 6, 10, and 13. It also includes
			the requested diversity (node, link, or SRLG).</li>
			<li pn="section-1.4-8.1.2.2">When the F bit is set, the request in
			dicates that the
			existing path has failed, and the resources present in the RRO can b
			e reused.
			</li>
			</ul>
			</li>
			</ul>
			<t pn="section-1.4-9">From <xref target="RFC8282" format="default" secti
			onFormat="of" derivedContent="RFC8282"/>:</t>
			<ul spacing="normal" empty="true" bare="false" pn="section-1.4-10">
			<li pn="section-1.4-10.1">
			<dl newline="false" spacing="normal" pn="section-1.4-10.1.1">
			<dt pn="section-1.4-10.1.1.1">SWITCH-LAYER:</dt>
			<dd pn="section-1.4-10.1.1.2">addresses requirements 1, 2, and 3 f
			or the TE-LSP and indicates which layer(s) should be considered. The object can
			be used to represent the RSVP-TE Generalized Label Request. It does not address
			the endpoints case of requirements 1, 2, and 3.</dd>
			<dt pn="section-1.4-10.1.1.3">REQ-ADAP-CAP:</dt>
			<dd pn="section-1.4-10.1.1.4">indicates the adaptation capabilitie
			s requested; it can also be used for the endpoints in case of mono-layer computa
			tion.</dd>
			</dl>
			</li>
			</ul>
			<t pn="section-1.4-11">
	The gaps in functional coverage of the base PCEP objects are:		The gaps in functional coverage of the base PCEP objects are:
	<list>		</t>
	<t>The BANDWIDTH and LOAD-BALANCING objects do not describe the d		<ul empty="false" spacing="normal" bare="false" pn="section-1.4-12">
	etails of the traffic request (requirements 4 and 5, for example NVC, multiplier		<li pn="section-1.4-12.1">The BANDWIDTH and LOAD-BALANCING objects do
	) in the context of GMPLS networks, for instance TDM or OTN networks.</t>		not describe the details of the traffic request (requirements 4 and 5, for examp
	<t>The END-POINTS object does not allow specifying an unnumbered		le, NVC and multiplier) in the context of GMPLS networks, for instance, in TDM o
	interface, nor potential label restrictions on the interface (requirements 6, 10		r OTN networks.</li>
	and 13). Those parameters are of interest in case of switching constraints.</t>		<li pn="section-1.4-12.2">The END-POINTS object does not allow specify
	<t>The Include/eXclude Route Objects (IRO/XRO) do not allow the		ing an unnumbered interface, nor potential label restrictions on the interface (
	inclusion/exclusion of labels (requirements 6, 10 and 13).</t>		requirements 6, 10, and 13). Those parameters are of interest in case of switchi
	<t>Base attributes do not allow expressing the requested link pr		ng constraints.</li>
	otection level and/or the end-to-end protection attributes.</t>		<li pn="section-1.4-12.3">The IROs/XROs do not allow the inclusion/exc
	</list>		lusion of labels (requirements 6, 10, and 13).</li>
	</t>		<li pn="section-1.4-12.4">Base attributes do not allow expressing the
			requested link protection level and/or the end-to-end protection attributes.</li
	<t>The PCEP extensions defined later in this document to cover the gaps a		>
	re:		</ul>
	<list>		<t pn="section-1.4-13">As defined later in this document, the PCEP exten
	<t>Two new object types are defined for the BANDWIDTH object (G		sions that cover the gaps are:
	eneralized bandwidth, Generalized bandwidth of existing TE-LSP for which a reopt		</t>
	imization is requested).</t>		<ul empty="false" spacing="normal" bare="false" pn="section-1.4-14">
	<t>A new object type is defined for the		<li pn="section-1.4-14.1">Two new object types are defined for the BAN
	LOAD-BALANCING object (Generalized Load Balancing).</t>		DWIDTH object
	<t>A new object type is defined for the END-POINTS object (Gene		(Generalized bandwidth and Generalized bandwidth of an existing TE-LSP
	ralized Endpoint).</t>		for which a reoptimization is requested).</li>
	<t>A new TLV is added to the Open message for capability negoti		<li pn="section-1.4-14.2">A new object type is defined for the
	ation.</t>		LOAD-BALANCING object (Generalized Load Balancing).</li>
	<t>A new TLV is added to the LSPA object. </t>		<li pn="section-1.4-14.3">A new object type is defined for the END-POI
	<t>The Label TLV is now allowed in the IRO and XRO objects.</t		NTS object (Generalized Endpoint).</li>
	>		<li pn="section-1.4-14.4">A new TLV is added to the Open message for c
	<t>In order to indicate the used routing granularity in the res		apability negotiation.</li>
	ponse, a new flag in the RP object is added.</t>		<li pn="section-1.4-14.5">A new TLV is added to the LSPA object. </li>
	</list>		<li pn="section-1.4-14.6">The Label subobject is now allowed in the IR
	</t>		O and XRO objects.</li>
			<li pn="section-1.4-14.7">In order to indicate the routing granularity
			used in the response, a new flag is added in the RP object.</li>
			</ul>
	</section>		</section>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
	<section title="PCEP Objects and Extensions">		<name slugifiedName="name-pcep-objects-and-extensions">PCEP Objects and Ex
	<t>		tensions</name>
	This section describes the necessary PCEP objects and extensions. The PC		<t pn="section-2-1">
	Req and PCRep messages are defined in <xref target="RFC5440"></xref>. This docum		This section describes the necessary PCEP objects and extensions. The PC
	ent does not change the existing grammars.</t>		Req and PCRep messages are defined in <xref target="RFC5440" format="default" se
	<section title="GMPLS Capability Advertisement" anchor="capability">		ctionFormat="of" derivedContent="RFC5440"/>. This document does not change the e
	<t>		xisting grammar.</t>
			<section anchor="capability" numbered="true" toc="include" removeInRFC="fa
	</t>		lse" pn="section-2.1">
	<section title="GMPLS Computation TLV in the Existing PCE Discovery Prot		<name slugifiedName="name-gmpls-capability-advertisem">GMPLS Capability
	ocol" anchor="IGP-discovery">		Advertisement</name>
	<t>		<section anchor="IGP-discovery" numbered="true" toc="include" removeInRF
	IGP-based PCE Discovery (PCED) is defined in <xref		C="false" pn="section-2.1.1">
	target="RFC5088" /> and <xref target="RFC5089" /> for the		<name slugifiedName="name-gmpls-computation-tlv-in-th">GMPLS Computati
			on TLV in the Existing PCE Discovery Protocol</name>
			<t pn="section-2.1.1-1">
			IGP-based PCE Discovery (PCED) is defined in <xref target="RFC5088" fo
			rmat="default" sectionFormat="of" derivedContent="RFC5088"/> and <xref target="R
			FC5089" format="default" sectionFormat="of" derivedContent="RFC5089"/> for the
	OSPF and IS-IS protocols. Those documents have defined bit 0		OSPF and IS-IS protocols. Those documents have defined bit 0
	in PCE-CAP-FLAGS Sub-TLV of the PCED TLV as "Path computation		in the PCE-CAP-FLAGS Sub-TLV of the PCED TLV as "Path computation
	with GMPLS link constraints". This capability is optional and		with GMPLS link constraints". This capability is optional and
	can be used to detect GMPLS-capable PCEs. PCEs that set the bit to indi cate support of GMPLS path computation		can be used to detect GMPLS-capable PCEs. PCEs that set the bit to indi cate support of GMPLS path computation
	MUST follow the procedures in Section 2.1.2 to further qualify the level of supp		<bcp14>MUST</bcp14> follow the procedures in <xref target="open-extensions" form
	ort during PCEP session establishment.</t>		at="default" sectionFormat="of" derivedContent="Section 2.1.2"/> to further qual
	</section>		ify the level of support during PCEP session establishment.</t>
	<section title="OPEN Object Extension GMPLS-CAPABILITY TLV" anchor="open		</section>
	-extensions">		<section anchor="open-extensions" numbered="true" toc="include" removeIn
	<t>		RFC="false" pn="section-2.1.2">
	In addition to the IGP advertisement, a PCEP speaker MUST be able to d		<name slugifiedName="name-open-object-extension-gmpls">OPEN Object Ext
	iscover the other peer GMPLS capabilities during the Open message exchange. This		ension GMPLS-CAPABILITY TLV</name>
	capability is also useful to avoid misconfigurations. This document defines a G		<t pn="section-2.1.2-1">
	MPLS-CAPABILITY TLV for use in the OPEN object to negotiate the GMPLS capability		In addition to the IGP advertisement, a PCEP speaker <bcp14>MUST</bcp1
	. The inclusion of this TLV in the Open message indicates that the PCEP speaker		4> be able to discover the other peer GMPLS capabilities during the Open message
	support the PCEP extensions defined in the document.		exchange. This capability is also useful to avoid misconfigurations. This docum
			ent defines a GMPLS-CAPABILITY TLV for use in the OPEN object to negotiate the G
			MPLS capability. The inclusion of this TLV in the Open message indicates that th
			e PCEP speaker supports the PCEP extensions defined in the document.
	A PCEP speaker that is able to support the GMPLS extensions		A PCEP speaker that is able to support the GMPLS extensions
	defined in this document MUST include the GMPLS-CAPABILITY		defined in this document <bcp14>MUST</bcp14> include the GMPLS-CAPABI
	TLV on the Open message.		LITY
			TLV in the Open message.
	If one of the PCEP peers does not include the GMPLS-CAPABILITY TLV		If one of the PCEP peers does not include the GMPLS-CAPABILITY TLV
	in the Open message, the peers MUST NOT make use of the objects and T		in the Open message, the peers <bcp14>MUST NOT</bcp14> make use of th
	LVs defined in this document.		e objects and TLVs defined in this document.
	</t>		</t>
	<t>		<t pn="section-2.1.2-2">
	If the PCEP speaker		If the PCEP speaker
	supports the extensions of this specification but did not advertise		supports the extensions of this specification but did not advertise
	the GMPLS-CAPABILITY capability, upon receipt of a message		the GMPLS-CAPABILITY capability, upon receipt of a message
	from the PCE including an extension defined in this document,		from the PCE including an extension defined in this document,
	it MUST generate a PCEP Error (PCErr) with Error-Type=10		it <bcp14>MUST</bcp14> generate a PCEP Error (PCErr) with Error-Type=
	(Reception of an invalid object) and Error-value=TBA-42		10
			(Reception of an invalid object) and Error-value=31
	(Missing GMPLS-CAPABILITY TLV), and it		(Missing GMPLS-CAPABILITY TLV), and it
	SHOULD terminate the PCEP session.		<bcp14>SHOULD</bcp14> terminate the PCEP session.
	</t>		</t>
	<t>		<t pn="section-2.1.2-3">
	IANA has allocated value TBA-1 from the "PCEP TLV Type Indicators" sub		As documented in <xref target="iana-tlvs" format="default" sectionForm
	-registry, as documented in <xref target="iana-tlvs" /> ("New PCEP TLVs"). The d		at="of" derivedContent="Section 5.3"/> ("New
	escription is "GMPLS-CAPABILITY". Its format is shown in the following figure.		PCEP TLVs"), IANA has allocated value 45 (GMPLS-CAPABILITY) from
	</t>		the "PCEP TLV Type Indicators" sub-registry.
	<figure >		The format for the GMPLS-CAPABILITY TLV is shown in the following figu
	<artwork><![CDATA[		re.
			</t>
			<artwork name="" type="" align="left" alt="" pn="section-2.1.2-4">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=TBA-1 | Length |		| Type=45 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags |		| Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<t pn="section-2.1.2-5">
	<t>		No flags are defined in this document; they are reserved for futur
	No Flags are defined in this document, they are reserved for futur		e use. Unassigned flags
	e use.		<bcp14>MUST</bcp14> be set to zero on transmission and <bcp14>MUST</bcp14> be
	</t>		ignored on receipt.
			</t>
	</section>		</section>
	</section>		</section>
	<section title="RP Object Extension" anchor="rp-extensions">		<section anchor="rp-extensions" numbered="true" toc="include" removeInRFC=
	<t>		"false" pn="section-2.2">
	Explicit label control (ELC) is a procedure supported by RSVP-TE,		<name slugifiedName="name-rp-object-extension">RP Object Extension</name
			>
			<t pn="section-2.2-1">
			Explicit Label Control (ELC) is a procedure supported by RSVP-TE,
	where the outgoing labels are encoded in the ERO. As a consequence,		where the outgoing labels are encoded in the ERO. As a consequence,
	the PCE can provide such labels directly in the path ERO.		the PCE can provide such labels directly in the path ERO.
	Depending on policies or switching layer, it can be necessary fo		Depending on the policies or switching layer, it might be necess
	r the PCC to use		ary for the PCC to use
	explicit label control or explicit link ids, thus it needs to		explicit label control or explicit link ids; thus, it needs to
	indicate in the PCReq which granularity it is expecting in the ERO.		indicate in the PCReq which granularity it is expecting in the ERO.
	This corresponds to requirement 12 of <xref target="RFC7025" />.		This corresponds to requirement 12 in <xref target="RFC7025" sectionFor
	The possible granularities can be node, link or label. The		mat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/
	granularities are inter-dependent, in the sense that link granularity i		rfc7025#section-3.1" derivedContent="RFC7025"/>.
	mplies the		The possible granularities can be node, link, or label. The
	presence of node information in the ERO; similarly, a label granularity		granularities are interdependent, in the sense that link granularity im
	implies that the ERO contains node, link and label information.		plies the
	</t>		presence of node information in the ERO; similarly, a label granularity
	<t>A new 2-bit routing granularity (RG) flag (Bits TBA-13) is defined i		implies that the ERO contains node, link, and label information.
	n		</t>
	the RP object. The values are defined as follows</t>		<t pn="section-2.2-2">A new 2-bit Routing Granularity (RG) flag (bits 15
	<texttable anchor='rp_bits' suppress-title='false'		-16) is defined in
	style='none' title='RG flag'>		the RP object. The values are defined as follows:</t>
	<ttcol align='center'></ttcol>		<ul empty="true" spacing="normal" bare="false" pn="section-2.2-3">
	<ttcol align='left'></ttcol>		<li pn="section-2.2-3.1">
	<c>0:</c><c>reserved </c>		<dl spacing="normal" newline="false" pn="section-2.2-3.1.1">
	<c>1:</c><c>node </c>		<dt pn="section-2.2-3.1.1.1">0:</dt>
	<c>2:</c><c>link </c>		<dd pn="section-2.2-3.1.1.2">reserved</dd>
	<c>3:</c><c>label </c>		<dt pn="section-2.2-3.1.1.3">1:</dt>
	</texttable>		<dd pn="section-2.2-3.1.1.4">node</dd>
	<t>The flag in the RP object indicates the requested		<dt pn="section-2.2-3.1.1.5">2:</dt>
	route granularity. The PCE SHOULD follow this granularity and MAY re		<dd pn="section-2.2-3.1.1.6">link</dd>
	turn a NO-PATH if the requested granularity cannot be provided. The PCE MAY retu		<dt pn="section-2.2-3.1.1.7">3:</dt>
	rn any granularity on the route based on its policy. The PCC can decide if the E		<dd pn="section-2.2-3.1.1.8">label</dd>
	RO is acceptable based on its content.		</dl>
	</t>		</li>
	<t> If a PCE honored the requested routing granularity for a reque		</ul>
	st, it MUST indicate the selected routing		<t pn="section-2.2-4">The RG flag in the RP object indicates the request
	granularity in the RP object included in the response. Otherwise, the		ed
	PCE MUST use the reserved RG to leave the check of the ERO to the PCC. The RG f		route granularity. The PCE <bcp14>SHOULD</bcp14> follow this granula
	lag is backward-compatible with <xref target="RFC5440" />: the value sent by an		rity and <bcp14>MAY</bcp14> return a NO-PATH if the requested granularity cannot
	implementation (PCC or PCE) not supporting it will indicate a reserved value.		be provided. The PCE <bcp14>MAY</bcp14> return any granularity on the route bas
	</t>		ed on its policy. The PCC can decide if the ERO is acceptable based on its conte
	</section>		nt.
	<section title="BANDWIDTH Object Extensions" anchor="generalized-bandwidt		</t>
	h">		<t pn="section-2.2-5"> If a PCE honored the requested routing granula
	<t>		rity for a request, it <bcp14>MUST</bcp14> indicate the selected routing
	From <xref target="RFC5440"/> the object carrying the requested size f		granularity in the RP object included in the response. Otherwise, the
	or the TE-LSP is the BANDWIDTH object. The object types 1 and 2 defined in <xref		PCE <bcp14>MUST</bcp14> use the reserved RG to leave the check of the ERO to th
	target="RFC5440"/> do not describe enough information to describe the TE-LSP ba		e PCC. The RG flag is backward compatible with <xref target="RFC5440" format="de
	ndwidth in GMPLS networks. The BANDWIDTH object encoding has to be extended to a		fault" sectionFormat="of" derivedContent="RFC5440"/>: the value sent by an imple
	llow the object to express the bandwidth as described in <xref target="RFC7025"		mentation (PCC or PCE) not supporting it will indicate a reserved value.
	/>.		</t>
	RSVP-TE extensions for GMPLS provide a set of encodings allowing such re		</section>
	presentation in an unambiguous way, this is encoded in the RSVP-TE TSpec and Flo		<section anchor="generalized-bandwidth" numbered="true" toc="include" remo
	wSpec objects. This document extends the BANDWIDTH object with new object types		veInRFC="false" pn="section-2.3">
	reusing the RSVP-TE encoding. </t>		<name slugifiedName="name-bandwidth-object-extensions">BANDWIDTH Object
	<t>The following possibilities are supported by the extended encoding:		Extensions</name>
	<list style='symbols'>		<t pn="section-2.3-1">
	<t>Asymmetric bandwidth (different bandwidth in forward and reverse d		Per <xref target="RFC5440" format="default" sectionFormat="of" derived
	irection), as described in <xref target="RFC6387"></xref></t>		Content="RFC5440"/>, the object carrying
	<t>GMPLS (SDH/SONET, G.709, ATM, MEF, etc.) parameters.</t>		the requested size for the TE-LSP is the BANDWIDTH object. Object
	</list>		types 1 and 2 defined in <xref target="RFC5440" format="default" secti
	This corresponds to requirements 3, 4, 5 and 11 of <xref target="RFC702		onFormat="of" derivedContent="RFC5440"/>
	5" /> Section 3.1.		do not provide enough information to describe the TE-LSP bandwidth
	</t>		in GMPLS networks. The BANDWIDTH object encoding has to be extended
	<t>		to allow the object to express the bandwidth as described in <xref tar
	This document defines two Object Types for the BANDWIDTH object:		get="RFC7025" format="default" sectionFormat="of" derivedContent="RFC7025"/>. R
	<list style='hanging'>		SVP-TE extensions for GMPLS
	<t hangText="TBA-2">Generalized bandwidth</t>		provide a set of encodings that allow such representation in an
	<t hangText="TBA-3">Generalized bandwidth of an existing TE-LSP for w		unambiguous way; this is encoded in the RSVP-TE Traffic
	hich a reoptimization is requested</t>		Specification (TSpec) and Flow Specification (FlowSpec)
	</list>		objects. This document extends the BANDWIDTH object with new object
	The definitions below apply for Object Type TBA-2 and TBA-3. The body i		types reusing the RSVP-TE encoding. </t>
	s as follows:		<t pn="section-2.3-2">The following possibilities are supported by the e
	</t>		xtended encoding:
			</t>
	<figure>		<ul spacing="normal" bare="false" empty="false" pn="section-2.3-3">
	<artwork><![CDATA[		<li pn="section-2.3-3.1">Asymmetric bandwidth (different bandwidth in
			forward and reverse direction), as described in <xref target="RFC6387" format="d
			efault" sectionFormat="of" derivedContent="RFC6387"/>.</li>
			<li pn="section-2.3-3.2">GMPLS (SDH/SONET, G.709, ATM, MEF, etc.) para
			meters.</li>
			</ul>
			<t pn="section-2.3-4">
			This corresponds to requirements 3, 4, 5, and 11 in <xref target="RFC70
			25" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-e
			ditor.org/rfc/rfc7025#section-3.1" derivedContent="RFC7025"/>.
			</t>
			<t pn="section-2.3-5">
			This document defines two object types for the BANDWIDTH object:
			</t>
			<ul spacing="normal" empty="true" bare="false" pn="section-2.3-6">
			<li pn="section-2.3-6.1">
			<dl newline="false" spacing="normal" pn="section-2.3-6.1.1">
			<dt pn="section-2.3-6.1.1.1">3:</dt>
			<dd pn="section-2.3-6.1.1.2">Generalized bandwidth</dd>
			<dt pn="section-2.3-6.1.1.3">4:</dt>
			<dd pn="section-2.3-6.1.1.4">Generalized bandwidth of an existing
			TE-LSP for which a
			reoptimization is requested</dd>
			</dl>
			</li>
			</ul>
			<t pn="section-2.3-7">
			The definitions below apply for object types 3 and 4. The body is as fo
			llows:
			</t>
			<artwork name="" type="" align="left" alt="" pn="section-2.3-8">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bandwidth Spec Length | Rev. Bandwidth Spec Length |		| Bandwidth Spec Length | Rev. Bandwidth Spec Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bw Spec Type | Reserved |		| Bw Spec Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Generalized Bandwidth ~		~ Generalized Bandwidth ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Optional: Reverse Generalized Bandwidth ~		~ Reverse Generalized Bandwidth (optional) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Optional TLVs ~		~ Optional TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<t pn="section-2.3-9">BANDWIDTH object types 3 and 4 have a variable len
	<t>The BANDWIDTH object type TBA-2 and TBA-3 have a variable length.		gth.
	The 16-bit Bandwidth Spec Length field indicates the length of the Gener alized Bandwidth field.		The 16-bit Bandwidth Spec Length field indicates the length of the Gener alized Bandwidth field.
	The Bandwidth Spec Length MUST be strictly greater than 0.		The Bandwidth Spec Length <bcp14>MUST</bcp14> be strictly greater than 0 .
	The 16-bit Reverse Bandwidth Spec Length field indicates the		The 16-bit Reverse Bandwidth Spec Length field indicates the
	length of the Reverse Generalized Bandwidth field.		length of the Reverse Generalized Bandwidth field.
	The Reverse Bandwidth Spec Length MAY be equal to 0.</t>		The Reverse Bandwidth Spec Length <bcp14>MAY</bcp14> be equal to 0.</t>
	<t>The Bw Spec Type field determines which type of bandwidth is represe		<t pn="section-2.3-10">The Bw Spec Type field determines which type of b
	nted by the object.</t>		andwidth is represented by the object.</t>
	<t>The Bw Spec Type corresponds to the RSVP-TE SENDER_TSPEC (Object Cla		<t pn="section-2.3-11">The Bw Spec Type corresponds to the RSVP-TE SENDE
	ss 12) C-Types</t>		R_TSPEC (Object Class 12) C-Types.</t>
	<t> The encoding of the fields Generalized Bandwidth and		<t pn="section-2.3-12"> The encoding of the Generalized Bandwidth and Re
	Reverse Generalized Bandwidth is the same as the Traffic Parameters carr		verse Generalized
	ied in RSVP-TE, it can be found in the following references. It is to be noted		Bandwidth fields is the same as the traffic parameters carried in
	that the		RSVP-TE; they can be found in the following references.
	RSVP-TE traffic specification MAY also include TLVs (e.g., <xref target
	="RFC6003" /> different from the PCEP TLVs).</t>
	<texttable anchor='TSpec_encoding' suppress-title='false'
	style='none' title='Generalized Bandwidth and Reverse Genera
	lized Bandwidth field encoding'>
	<ttcol align='left'>Bw Spec Type</ttcol>
	<ttcol align='left'>Name </ttcol>
	<ttcol align='left'>Reference</ttcol>
	<c>2</c><c>Intserv</c><c><xref target="RFC2210"></xref></c>
	<c>4</c><c>SONET/SDH</c><c><xref target="RFC4606"></xref></c>
	<c>5</c><c>G.709</c><c><xref target="RFC4328"></xref></c>
	<c>6</c><c>Ethernet</c><c><xref target="RFC6003"></xref></c>
	<c>7</c><c>OTN-TDM</c><c><xref target="RFC7139"></xref></c>
	<c>8</c><c>SSON</c><c><xref target="RFC7792"></xref></c>
	</texttable>
	<t>
	When a PCC requests a bi-directional path with symmetric bandwidth,
	it SHOULD only specify the Generalized Bandwidth field, and set the Reverse B
	andwidth Spec
	Length to 0.
	When a PCC needs to request a bi-directional path with		Note that the RSVP-TE traffic specification <bcp14>MAY</bcp14> also
	asymmetric bandwidth, it SHOULD specify the different bandwidth in the f		include TLVs that are different from the PCEP TLVs (e.g., the TLVs defi
	orward and reverse directions with a Generalized Bandwidth and Reverse Generaliz		ned in <xref target="RFC6003" format="default" sectionFormat="of" derivedContent
	ed Bandwidth fields.		="RFC6003"/>).</t>
	</t>		<table anchor="TSpec_encoding" align="center" pn="table-3">
	<t>The procedure described in <xref target="RFC5440" /> for the PCRep i		<name slugifiedName="name-generalized-bandwidth-and-r">Generalized Ban
	s unchanged: a PCE MAY include the BANDWIDTH objects in the response to indicate		dwidth and Reverse Generalized Bandwidth Field Encoding</name>
	the BANDWIDTH of the path.</t>		<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Bw Spec Type</th>
			<th align="left" colspan="1" rowspan="1">Name </th>
			<th align="left" colspan="1" rowspan="1">Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">2</td>
			<td align="left" colspan="1" rowspan="1">Intserv</td>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC2210" format="default" sectionFormat="of" deriv
			edContent="RFC2210"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">4</td>
			<td align="left" colspan="1" rowspan="1">SONET/SDH</td>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC4606" format="default" sectionFormat="of" deriv
			edContent="RFC4606"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">5</td>
			<td align="left" colspan="1" rowspan="1">G.709</td>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC4328" format="default" sectionFormat="of" deriv
			edContent="RFC4328"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">6</td>
			<td align="left" colspan="1" rowspan="1">Ethernet</td>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC6003" format="default" sectionFormat="of" deriv
			edContent="RFC6003"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">7</td>
			<td align="left" colspan="1" rowspan="1">OTN-TDM</td>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC7139" format="default" sectionFormat="of" deriv
			edContent="RFC7139"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">8</td>
			<td align="left" colspan="1" rowspan="1">SSON</td>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC7792" format="default" sectionFormat="of" deriv
			edContent="RFC7792"/></td>
			</tr>
			</tbody>
			</table>
			<t pn="section-2.3-14">
			When a PCC requests a bidirectional path with symmetric bandwidth,
			it <bcp14>SHOULD</bcp14> only specify the Generalized Bandwidth field and set
			the Reverse Bandwidth Spec
			Length to 0.
	<t>As specified in <xref target="RFC5440" /> in the case of the reoptimi		When a PCC needs to request a bidirectional path with
	zation of a TE-LSP, the bandwidth of the		asymmetric bandwidth, it <bcp14>SHOULD</bcp14> specify the different ban
	existing TE-LSP MUST also be included in addition to the requested		dwidth in the forward and reverse directions with Generalized Bandwidth and Reve
	bandwidth if and only if the two values differ. The Object Type TBA-3 MAY be		rse Generalized Bandwidth fields.
	used instead of the previously specified object		</t>
	type 2 to indicate the existing TE-LSP bandwidth originally specified with		<t pn="section-2.3-15">The procedure described in <xref target="RFC5440"
	object type TBA-2. A PCC that requested a path with a BANDWIDTH object of		format="default" sectionFormat="of" derivedContent="RFC5440"/> for the PCRep is
	object type 1 MUST use object type 2 to represent the existing TE-LSP		unchanged: a PCE <bcp14>MAY</bcp14> include the BANDWIDTH objects in the respon
	BANDWIDTH.		se to indicate the BANDWIDTH of the path.</t>
	</t>		<t pn="section-2.3-16">As specified in <xref target="RFC5440" format="de
	<t>OPTIONAL TLVs MAY be included within the object body to specify		fault" sectionFormat="of" derivedContent="RFC5440"/>, in the case of the reoptim
	more specific bandwidth requirements. No TLVs for the Object Type TBA-2		ization of a TE-LSP, the bandwidth of the
	and TBA-3 are defined by this document.		existing TE-LSP <bcp14>MUST</bcp14> also be included in addition to the reque
	</t>		sted
	</section> <!-- Generalized BW-->		bandwidth if and only if the two values differ. The object type 4 <bcp14>MAY
	<section title="LOAD-BALANCING Object Extensions" anchor="generalized-loa		</bcp14> be used instead of the previously specified object
	d-balancing">		type 2 to indicate the existing TE-LSP bandwidth, which was originally specif
	<t>		ied with
	The LOAD-BALANCING object <xref target="RFC5440" /> is used to request		object type 3. A PCC that requested a path with a BANDWIDTH object of
	a set of at most Max-LSP TE-LSP having in total the bandwidth specified in BANDW		object type 1 <bcp14>MUST</bcp14> use object type 2 to represent the existing
	IDTH, with each TE-LSP having at least a specified minimum bandwidth. The LOAD-B		TE-LSP
	ALANCING follows the bandwidth encoding of the BANDWIDTH object, and thus the ex		bandwidth.
	isting definition from <xref target="RFC5440" /> does not describe enough detail		</t>
	s for the bandwidth specification expected by GMPLS.		<t pn="section-2.3-17">Optional TLVs <bcp14>MAY</bcp14> be included with
	</t>		in the object body to specify
	<t>		more specific bandwidth requirements. No TLVs for object types 3 and 4
	Similarly to the BANDWIDTH object, a new object type is defined to all		are defined by this document.
	ow a PCC to represent the bandwidth types supported by GMPLS networks.		</t>
	</t>		</section>
			<section anchor="generalized-load-balancing" numbered="true" toc="include"
			removeInRFC="false" pn="section-2.4">
			<name slugifiedName="name-load-balancing-object-exten">LOAD-BALANCING Ob
			ject Extensions</name>
			<t pn="section-2.4-1">
			The LOAD-BALANCING object <xref target="RFC5440" format="default" secti
			onFormat="of" derivedContent="RFC5440"/>
			is used to request a set of at most Max-LSP TE-LSPs having in total
			the bandwidth specified in BANDWIDTH, with each TE-LSP having at
			least a specified minimum bandwidth.
	<t>		The LOAD-BALANCING object follows the bandwidth
	This document defines the Generalized Load Balancing object type TBA-4 for		encoding of the BANDWIDTH object; thus, the existing definition from
	the LOAD-BALANCING object.		<xref target="RFC5440" format="default" sectionFormat="of" derivedConte
	The Generalized Load Balancing object type has a variable length.		nt="RFC5440"/> does not describe enough
	</t>		details for the bandwidth specification expected by GMPLS.
	<t>The format of the Generalized Load Balancing object type is as follows:</t		</t>
	>		<t pn="section-2.4-2">
	<figure>		Similar to the BANDWIDTH object, a new object type is defined to allow
	<artwork><![CDATA[		a PCC to represent the bandwidth types supported by GMPLS networks.
			</t>
			<t pn="section-2.4-3">
			This document defines object type 2 (Generalized Load Balancing) for the
			LOAD-BALANCING object. The Generalized Load Balancing object type has a
			variable length.
			</t>
			<t pn="section-2.4-4">The format of the Generalized Load Balancing objec
			t type is as follows:</t>
			<artwork name="" type="" align="left" alt="" pn="section-2.4-5">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bandwidth Spec Length | Reverse Bandwidth Spec Length |		| Bandwidth Spec Length | Reverse Bandwidth Spec Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Bw Spec Type | Max-LSP | Reserved |		| Bw Spec Type | Max-LSP | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Min Bandwidth Spec |		| Min Bandwidth Spec |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Min Reverse Bandwidth Spec (optional) |		| Min Reverse Bandwidth Spec (optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Optional TLVs ~		~ Optional TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<dl spacing="normal" newline="false" pn="section-2.4-6">
	<t>Bandwidth Spec Length (16 bits): the total length of		<dt pn="section-2.4-6.1">Bandwidth Spec Length (16 bits):</dt>
	the Min Bandwidth Spec field. The length MUST be strictly greater than		<dd pn="section-2.4-6.2">the total length of
	0.</t>		the Min Bandwidth Spec field. The length <bcp14>MUST</bcp14> be strictl
	<t>Reverse Bandwidth Spec Length (16 bits): the total		y greater than 0.</dd>
	length of the Min Reverse Bandwidth Spec field. It MAY be equal to 0.</		<dt pn="section-2.4-6.3">Reverse Bandwidth Spec Length (16 bits):</dt>
	t>		<dd pn="section-2.4-6.4">the total
			length of the Min Reverse Bandwidth Spec field. It <bcp14>MAY</bcp14> b
	<t>Bw Spec Type (8 bits): the bandwidth specification type, it correspo		e equal to 0.</dd>
	nds to the RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.</t>		<dt pn="section-2.4-6.5">Bw Spec Type (8 bits):</dt>
	<t>Max-LSP (8 bits): maximum number of TE-LSPs in the set.</t>		<dd pn="section-2.4-6.6">the bandwidth specification type; it correspo
	<t>Min Bandwidth Spec (variable): specifies the minimum bandwidth specif		nds to RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.</dd>
	ication of each		<dt pn="section-2.4-6.7">Max-LSP (8 bits):</dt>
	element of the TE-LSP set.</t>		<dd pn="section-2.4-6.8">the maximum number of TE-LSPs in the set.</dd
	<t>Min Reverse Bandwidth Spec (variable): specifies the minimum reverse		>
	bandwidth specification of each		<dt pn="section-2.4-6.9">Min Bandwidth Spec (variable):</dt>
	element of the TE-LSP set.</t>		<dd pn="section-2.4-6.10">specifies the minimum bandwidth specificatio
	<t>The encoding of the fields Min Bandwidth Spec and Min		n of each
	Reverse Bandwidth Spec is the same as in RSVP-TE SENDER_TSPEC		element of the TE-LSP set.</dd>
	object, it can be found in <xref target="TSpec_encoding"/>		<dt pn="section-2.4-6.11">Min Reverse Bandwidth Spec (variable):</dt>
	from <xref target="generalized-bandwidth" /> from this document.</t>		<dd pn="section-2.4-6.12">specifies the minimum reverse bandwidth spec
	<t>		ification of each
	When a PCC requests a bi-directional path with symmetric		element of the TE-LSP set.</dd>
	bandwidth while specifying load balancing constraints it SHOULD		</dl>
	specify the Min Bandwidth Spec field, and set the Reverse		<t pn="section-2.4-7">The encoding of the Min Bandwidth Spec and Min
	Bandwidth Spec Length to 0.		Reverse Bandwidth Spec fields is the same as in the RSVP-TE SENDER_TSPEC
			object; it can be found in <xref target="TSpec_encoding" format="default
	When a PCC needs to request a bi-directional path with		" sectionFormat="of" derivedContent="Table 3"/>
	asymmetric bandwidth while specifying load balancing		in <xref target="generalized-bandwidth" format="default" sectionFormat="
	constraints, it MUST specify the different bandwidth in		of" derivedContent="Section 2.3"/> of this document.</t>
	forward and reverse directions through a Min Bandwidth Spec		<t pn="section-2.4-8">
			When a PCC requests a bidirectional path with symmetric
			bandwidth while specifying load-balancing constraints, it <bcp14>SHOULD
			</bcp14>
			specify the Min Bandwidth Spec field and set the Reverse
			Bandwidth Spec Length to 0. When a PCC needs to request a bidirectional
			path with
			asymmetric bandwidth while specifying load-balancing
			constraints, it <bcp14>MUST</bcp14> specify the different bandwidth in
			forward and reverse directions through Min Bandwidth Spec
	and Min Reverse Bandwidth Spec fields.		and Min Reverse Bandwidth Spec fields.
	</t>		</t>
	<t>OPTIONAL TLVs MAY be included within the object body to specify		<t pn="section-2.4-9">Optional TLVs <bcp14>MAY</bcp14> be included withi
			n the object body to specify
	more specific bandwidth requirements. No TLVs for the Generalized Load Balancing object type are defined by this document.		more specific bandwidth requirements. No TLVs for the Generalized Load Balancing object type are defined by this document.
	</t>		</t>
	<t>The semantic of the LOAD-BALANCING object is not changed. If a PCC		<t pn="section-2.4-10">The semantic of the LOAD-BALANCING object is not
			changed. If a PCC
	requests the computation of a set of TE-LSPs with at most N		requests the computation of a set of TE-LSPs with at most N
	TE-LSPs so that it can carry generalized bandwidth X , each TE-LSP must at least transport bandwidth B, it inserts a		TE-LSPs so that it can carry Generalized bandwidth X, each TE-LSP must a t least transport bandwidth B; it inserts a
	BANDWIDTH object specifying X as the required bandwidth and a LOAD-BALAN CING object with the Max-LSP and Min Bandwidth Spec fields set		BANDWIDTH object specifying X as the required bandwidth and a LOAD-BALAN CING object with the Max-LSP and Min Bandwidth Spec fields set
	to N and B, respectively. When the BANDWIDTH and Min Bandwidth Spec can		to N and B, respectively. When the BANDWIDTH and Min Bandwidth Spec can
	be summarized as scalars, the sum of all TE-LSPs bandwith in the set is greater		be summarized as scalars, the sum of the bandwidth for all TE-LSPs in the set is
	than X.		greater than X.
	The mapping of X over N path with (at least) bandwidth B is technology a		The mapping of the X over N path with (at least) bandwidth B is technolo
	nd possibly node specific.		gy and possibly node specific.
	Each standard definition of the transport technology is defining those m appings and are not repeated in this document.		Each standard definition of the transport technology is defining those m appings and are not repeated in this document.
	A simplified example for SDH is described in <xref target="appendix" />		A simplified example for SDH is described in <xref target="appendix" for
	</t>		mat="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
	<t>		<t pn="section-2.4-11">
	In all other cases, including for technologies based on statistical		In all other cases, including technologies based on statistical
	multiplexing (e.g., InterServ, Ethernet), the exact bandwidth		multiplexing (e.g., InterServ and Ethernet), the exact bandwidth
	management (e.g., Ethernet's Excessive Rate) is left to the PCE's		management (e.g., the Ethernet's Excessive Rate) is left to the PCE's
	policies, according to the operator's configuration. If required,		policies, according to the operator's configuration. If required,
	further documents may introduce a new mechanism to finely express		further documents may introduce a new mechanism to finely express
	complex load balancing policies within PCEP.		complex load-balancing policies within PCEP.
	</t>		</t>
	<t>The BANDWITH and LOAD-BALANCING Bw Spec Type can be different dependi		<t pn="section-2.4-12">The BANDWIDTH and LOAD-BALANCING Bw Spec Type can
	ng on the endpoint nodes architecture. When the PCE is not able to handle those		be different depending on the architecture of the endpoint node. When the PCE i
	two Bw Spec Type, it MUST return a NO-PATH with the bit "LOAD-BALANCING could no		s not able to handle those two Bw Spec Types, it <bcp14>MUST</bcp14> return a NO
	t be performed with the bandwidth constraits " set in the NO-PATH-VECTOR TLV.</		-PATH with the bit "LOAD-BALANCING could not be performed with the bandwidth con
	t>		straints" set in the NO-PATH-VECTOR TLV.</t>
	</section> <!-- Generalized BW-->		</section>
			<section anchor="endpoints_extensions" numbered="true" toc="include" remov
	<section title="END-POINTS Object Extensions" anchor='endpoints_extension		eInRFC="false" pn="section-2.5">
	s'>		<name slugifiedName="name-end-points-object-extension">END-POINTS Object
	<t>		Extensions</name>
			<t pn="section-2.5-1">
	The END-POINTS object is used in a PCEP request message to specify th e		The END-POINTS object is used in a PCEP request message to specify th e
	source and the destination of the path for which a path computation i s requested.		source and the destination of the path for which a path computation i s requested.
	From <xref target="RFC5440"/>, the source IP address and the destinat		Per <xref target="RFC5440" format="default" sectionFormat="of" derive
	ion IP address are used to identify those.		dContent="RFC5440"/>, the source IP address and the destination IP address are u
	A new Object Type is defined to address the following possibilities:		sed to identify those.
	<list style='symbols'>		A new object type is defined to address the following possibilities:
	<t>Different source and destination endpoint types.</t>		</t>
	<t>Label restrictions on the endpoint.</t>		<ul spacing="normal" bare="false" empty="false" pn="section-2.5-2">
	<t>Specification of unnumbered endpoints type as seen in GMPLS netw		<li pn="section-2.5-2.1">Different source and destination endpoint typ
	orks.</t>		es.</li>
	</list>		<li pn="section-2.5-2.2">Label restrictions on the endpoint.</li>
	The Object encoding is described in the following sections.		<li pn="section-2.5-2.3">Specification of unnumbered endpoints type as
	</t>		seen in GMPLS networks.</li>
			</ul>
	<t>In path computation within a GMPLS context the endpoints can:		<t pn="section-2.5-3">
	<list style='symbols'>		The object encoding is described in the following sections.
	<t>Be unnumbered as described in <xref target="RFC3477" />.</t>		</t>
	<t>Have labels associated to them, specifying a set of constraints		<t pn="section-2.5-4">In path computation within a GMPLS context, the en
	on the allocation of labels.</t>		dpoints can:
	<t>Have different switching capabilities</t>		</t>
	</list>		<ul spacing="normal" bare="false" empty="false" pn="section-2.5-5">
			<li pn="section-2.5-5.1">Be unnumbered as described in <xref target="R
			FC3477" format="default" sectionFormat="of" derivedContent="RFC3477"/>.</li>
			<li pn="section-2.5-5.2">Have labels associated to them, specifying a
			set of constraints on the allocation of labels.</li>
			<li pn="section-2.5-5.3">Have different switching capabilities.</li>
			</ul>
			<t pn="section-2.5-6">
	The IPv4 and IPv6 endpoints are used to represent the source and dest ination IP addresses.		The IPv4 and IPv6 endpoints are used to represent the source and dest ination IP addresses.
	The scope of the IP address (Node or numbered Link) is not explicitly		The scope of the IP address (node or numbered link) is not explicitly
	stated.		stated.
	It is also possible to request a Path between a numbered link and an		It is also possible to request a path between a numbered link and an
	unnumbered link, or a P2MP path between different type of endpoints.		unnumbered link, or a P2MP path between different types of endpoints.
	</t>		</t>
	<t>		<t pn="section-2.5-7">
	This document defines the Generalized Endpoint object type TBA-5 for		This document defines object type 5 (Generalized Endpoint) for the
	the END-POINTS object.		END-POINTS object. This new type also supports the specification
	This new type also supports the specification of constraints on the e		of constraints on the endpoint label to be used. The PCE might
	ndpoint label to be used.		know the interface restrictions, but this is not a requirement.
	The PCE might know the interface restrictions but this is not a requi		This corresponds to requirements 6 and 10 in <xref target="RFC7025" s
	rement.		ectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor
	This corresponds to requirements 6 and 10 of <xref target="RFC7025" /		.org/rfc/rfc7025#section-3.1" derivedContent="RFC7025"/>.
	>.		</t>
	</t>		<section anchor="endpoints_generalized" numbered="true" toc="include" re
	<section anchor="endpoints_generalized" title="Generalized Endpoint O		moveInRFC="false" pn="section-2.5.1">
	bject Type ">		<name slugifiedName="name-generalized-endpoint-object">Generalized End
			point Object Type</name>
			<t pn="section-2.5.1-1">
			The Generalized Endpoint object type format consists of a body and a
			list of TLVs scoped to this object. The TLVs give the details of the endpoints
			and are described in <xref target="endpoints_tlvs" format="default" sectionForma
			t="of" derivedContent="Section 2.5.2"/>.
			For each endpoint type, a different grammar is defined.
	<t>
	The Generalized Endpoint object type format consists of a body and a
	list of TLVs scoped to this object. The TLVs give the details of the endpoints
	and are described in <xref target="endpoints_tlvs" />. For each Endpoint Type,
	a different grammar is defined.
	The TLVs defined to describe an endpoint are:		The TLVs defined to describe an endpoint are:
	<list style='numbers'>		</t>
	<t>IPv4 address endpoint.</t>		<ol spacing="normal" type="1" start="1" pn="section-2.5.1-2">
	<t>IPv6 address endpoint.</t>		<li pn="section-2.5.1-2.1" derivedCounter="1.">IPV4-ADDRESS</li>
	<t>Unnumbered endpoint.</t>		<li pn="section-2.5.1-2.2" derivedCounter="2.">IPV6-ADDRESS</li>
	<t>Label request.</t>		<li pn="section-2.5.1-2.3" derivedCounter="3.">UNNUMBERED-ENDPOINT</
	<t>Label set.</t>		li>
	</list>		<li pn="section-2.5.1-2.4" derivedCounter="4.">LABEL-REQUEST</li>
	The Label set TLV is used to restrict or suggest the		<li pn="section-2.5.1-2.5" derivedCounter="5.">LABEL-SET</li>
	label allocation in the PCE. This TLV expresses the set of		</ol>
	restrictions which may apply to signaling. Label restriction		<t pn="section-2.5.1-3">
	support can be an explicit or a suggested value (Label set describing		The LABEL-SET TLV is used to restrict or suggest the label
	one label, with		allocation in the PCE. This TLV expresses the set of restrictions
	the L bit respectively cleared or set), mandatory range restrictions		that may apply to signaling. Label restriction support can be an
	(Label set with L bit cleared) and optional range restriction (Label		explicit or a suggested value (LABEL-SET describing one label, with
	set		the L bit cleared or set, respectively), mandatory range
	with L bit set).		restrictions (LABEL-SET with the L bit cleared), and optional range
			restriction (LABEL-SET with the L bit set). Endpoints label
	Endpoints label restriction may not be part of the RRO or IRO. They c		restriction may not be part of the RRO or IRO. They can be
	an be included when following <xref target="RFC4003" /> in signaling for egress		included when following <xref target="RFC4003" format="default" sectio
	endpoint, but ingress endpoint properties can be local to the PCC and not signal		nFormat="of" derivedContent="RFC4003"/>
	ed. To support this case the label set allows indication which label are used in		in signaling for the egress endpoint, but ingress endpoint
	case of reoptimization.		properties can be local to the PCC and not signaled. To support
			this case, the LABEL-SET allows indication of which labels are used
	The label range restrictions are valid in GMPLS-controlled networks, e		in case of reoptimization.
	ither by PCC policy or depending on the switching technology used, for instance
	on given Ethernet or ODU equipment having limited hardware capabilities restrict
	ing the label range.
	Label set restriction also applies to WSON networks where the optical senders an
	d receivers are limited in their frequency tunability ranges, consequently restr
	icting the possible label ranges on the interface
	in GMPLS.
	The END-POINTS Object with Generalized Endpoint object type is encode		The label range restrictions are valid in GMPLS-controlled
	d as follow:		networks, depending on either the PCC policy or the switching
	</t>		technology used, for instance, on a given Ethernet or ODU
	<figure>		equipment having limited hardware capabilities restricting
	<artwork><![CDATA[		the label range. Label
			set restriction also applies to WSON networks where the optical
			senders and receivers are limited in their frequency tunability
			ranges, consequently restricting the possible label ranges on the
			interface in GMPLS. The END-POINTS object with the Generalized
			Endpoint object type is encoded as follows:
			</t>
			<artwork name="" type="" align="left" alt="" pn="section-2.5.1-4">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Endpoint Type |		| Reserved | Endpoint Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ TLVs ~		~ TLVs ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]>
	</artwork>		</artwork>
	</figure>		<t pn="section-2.5.1-5">Reserved bits <bcp14>SHOULD</bcp14> be set to
	<t>Reserved bits SHOULD be set to 0 when a message is sent and ignore		0 when a message is sent and ignored when the message is received.</t>
	d when the message is received.</t>		<t pn="section-2.5.1-6">The values for the Endpoint Type field are def
	<t>The Endpoint Type is defined as follow:</t>		ined as follows:</t>
	<texttable anchor='endpoints_generalized_endpoint-type'		<table anchor="endpoints_generalized_endpoint-type" align="center" pn=
	suppress-title='false' style='none'		"table-4">
	title='Generalized Endpoint endpoint types'>		<name slugifiedName="name-generalized-endpoint-types">Generalized En
	<ttcol align='left'>Value</ttcol>		dpoint Types</name>
	<ttcol align='left'>Type</ttcol>		<thead>
	<ttcol align='left'>Meaning</ttcol>		<tr>
	<c>0</c><c>Point-to-Point</c><c></c>		<th align="left" colspan="1" rowspan="1">Value</th>
	<c>1</c><c>Point-to-Multipoint</c><c>New leaves to add</c>		<th align="left" colspan="1" rowspan="1">Type</th>
	<c>2</c><c></c><c>Old leaves to remove</c>		</tr>
	<c>3</c><c></c><c>Old leaves whose path can be modified/reoptimized		</thead>
	</c>		<tbody>
	<c>4</c><c></c><c>Old leaves whose path has to be</c>		<tr>
	<c></c><c></c><c>left unchanged</c>		<td align="left" colspan="1" rowspan="1">0</td>
	<c>5-244</c><c>Reserved </c><c></c>		<td align="left" colspan="1" rowspan="1">Point-to-Point</td>
	<c>245-255</c><c>Experimental range</c><c></c>		</tr>
	</texttable>		<tr>
			<td align="left" colspan="1" rowspan="1">1</td>
	<t>		<td align="left" colspan="1" rowspan="1">Point-to-Multipoint wit
	The Endpoint Type is used to cover both point-to-point and different		h leaf type 1</td>
	point-to-multipoint endpoints.		</tr>
			<tr>
	A PCE may accept only Endpoint Type 0: Endpoint Types 1-4 apply if t		<td align="left" colspan="1" rowspan="1">2</td>
	he		<td align="left" colspan="1" rowspan="1">Point-to-Multipoint wit
	PCE implementation supports P2MP path calculation. A PCE not		h leaf type 2</td>
	supporting a given Endpoint Type SHOULD respond with a PCErr with		</tr>
	Error-Type=4 (Not supported object), Error-value=TBA-15 (Unsupported		<tr>
	endpoint type in END-POINTS		<td align="left" colspan="1" rowspan="1">3</td>
	Generalized Endpoint object type). As per <xref		<td align="left" colspan="1" rowspan="1">Point-to-Multipoint wit
	target="RFC5440" />, a PCE unable to		h leaf type 3</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">4</td>
			<td align="left" colspan="1" rowspan="1">Point-to-Multipoint wit
			h leaf type 4</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">5-244</td>
			<td align="left" colspan="1" rowspan="1">Unassigned</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">245-255</td>
			<td align="left" colspan="1" rowspan="1">Experimental Use</td>
			</tr>
			</tbody>
			</table>
			<t pn="section-2.5.1-8">
			The Endpoint Type field is used to cover both point-to-point and
			different point-to-multipoint endpoints. A PCE may only accept
			endpoint type 0; endpoint types 1-4 apply if the PCE
			implementation supports P2MP path calculation. The leaf types for P2
			MP are as per <xref target="RFC8306" format="default" sectionFormat="of" derived
			Content="RFC8306"/>. A PCE not
			supporting a given endpoint type <bcp14>SHOULD</bcp14> respond
			with a PCErr with Error-Type=4 (Not supported object) and
			Error-value=7 (Unsupported endpoint type in END-POINTS
			Generalized Endpoint object type).
			As per <xref target="RFC5440" format="default" sectionFormat="of" de
			rivedContent="RFC5440"/>, a PCE unable to
	process Generalized Endpoints may respond with		process Generalized Endpoints may respond with
	Error-Type=3 (Unknown Object), Error-value=2 (Unrecognized object		Error-Type=3 (Unknown Object) and Error-value=2 (Unrecognized object
	Type) or Error-Type=4 (Not supported object),		type) or with Error-Type=4 (Not supported object) and
	Error-value=2 (Not supported object Type).		Error-value=2 (Not supported object Type).
	The TLVs present in the request object body MUST follow
	the following <xref target='RFC5511' /> grammar:		The TLVs present in the request object body <bcp14>MUST</bcp14> foll
			ow
			the grammar per <xref target="RFC5511" format="default" sectionForma
			t="of" derivedContent="RFC5511"/>:
	</t>		</t>
	<figure>		<sourcecode type="rbnf" markers="false" pn="section-2.5.1-9">
	<artwork><![CDATA[		&lt;generalized-endpoint-tlvs&gt;::=
	<generalized-endpoint-tlvs>::=		&lt;p2p-endpoints&gt; | &lt;p2mp-endpoints&gt;
	<p2p-endpoints> | <p2mp-endpoints>
	<p2p-endpoints> ::=		&lt;p2p-endpoints&gt; ::=
	<endpoint> [<endpoint-restriction-list>]		&lt;endpoint&gt; [&lt;endpoint-restriction-list&gt;]
	<endpoint> [<endpoint-restriction-list>]		&lt;endpoint&gt; [&lt;endpoint-restriction-list&gt;]
	<p2mp-endpoints> ::=		&lt;p2mp-endpoints&gt; ::=
	<endpoint> [<endpoint-restriction-list>]		&lt;endpoint&gt; [&lt;endpoint-restriction-list&gt;]
	<endpoint> [<endpoint-restriction-list>]		&lt;endpoint&gt; [&lt;endpoint-restriction-list&gt;]
	[<endpoint> [<endpoint-restriction-list>]]...		[&lt;endpoint&gt; [&lt;endpoint-restriction-list&gt;]]...
	]]>		</sourcecode>
	</artwork>		<t pn="section-2.5.1-10">For endpoint type Point-to-Point, two endpoin
	</figure>		t TLVs <bcp14>MUST</bcp14>
	<t>For endpoint type Point-to-Point, 2 endpoint TLVs MUST		be present in the message. The first endpoint is the source, and the
	be present in the message. The first endpoint is the source and the
	second is the destination.		second is the destination.
	</t>		</t>
	<t>For endpoint type Point-to-Multipoint, several END-POINT objects MA		<t pn="section-2.5.1-11">For endpoint type Point-to-Multipoint, severa
	Y		l END-POINTS objects <bcp14>MAY</bcp14>
	be present in the message and the exact meaning depending on the		be present in the message, and the exact meaning depends on the
	endpoint type defined for the object. The first endpoint TLV is the		endpoint type defined for the object. The first endpoint TLV is the
	root and other endpoints TLVs are the leaves. The root endpoint		root, and other endpoint TLVs are the leaves. The root endpoint
	MUST be the same for all END-POINTS objects for that P2MP tree		<bcp14>MUST</bcp14> be the same for all END-POINTS objects for that P2MP tree
	request.		request.
	If the root endpoint is not the same for all END-POINTS, a		If the root endpoint is not the same for all END-POINTS, a
	PCErr with Error-Type=17 (P2MP END-POINTS Error), Error-value=4 (The PCE cann		PCErr with Error-Type=17 (P2MP END-POINTS Error) and Error-value=4 (The PCE c
	ot satisfy the		annot satisfy the
	request due to inconsistent END-POINTS) MUST be returned. The		request due to inconsistent END-POINTS) <bcp14>MUST</bcp14> be returned. The
	procedure defined in <xref target="RFC8306" /> Section 3.10 also apply		procedure defined in <xref target="RFC8306" sectionFormat="comma" section="3.
			10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8306#section-3.1
			0" derivedContent="RFC8306"/> also applies
	to the Generalized Endpoint with Point-to-Multipoint endpoint types.		to the Generalized Endpoint with Point-to-Multipoint endpoint types.
	</t>		</t>
	<t>An endpoint is defined as follows:</t>		<t pn="section-2.5.1-12">An endpoint is defined as follows:</t>
	<figure>		<sourcecode type="" markers="false" pn="section-2.5.1-13">
	<artwork><![CDATA[		&lt;endpoint&gt;::=&lt;IPV4-ADDRESS&gt;|&lt;IPV6-ADDRESS&gt;|&lt;UNNUMBERED-END
	<endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT>		POINT&gt;
	<endpoint-restriction-list> ::= <endpoint-restriction>		&lt;endpoint-restriction-list&gt; ::= &lt;endpoint-restriction&gt;
	[<endpoint-restriction-list>]		[&lt;endpoint-restriction-list&gt;]
	<endpoint-restriction> ::=
	[<LABEL-REQUEST>][<label-restriction-list>]
	<label-restriction-list> ::= <label-restriction>		&lt;endpoint-restriction&gt; ::=
	[<label-restriction-list>]		[&lt;LABEL-REQUEST&gt;][&lt;label-restriction-list&gt;]
	<label-restriction> ::= <LABEL-SET>
	]]></artwork>
	</figure>
	<t>The different TLVs are described in the following sections. A PCE M		&lt;label-restriction-list&gt; ::= &lt;label-restriction&gt;
	AY support any or all of IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT TLV		[&lt;label-restriction-list&gt;]
	s.		&lt;label-restriction&gt; ::= &lt;LABEL-SET&gt;
			</sourcecode>
			<t pn="section-2.5.1-14">The different TLVs are described in the follo
			wing sections. A PCE <bcp14>MAY</bcp14> support any or all of the IPV4-ADDRESS,
			IPV6-ADDRESS, and UNNUMBERED-ENDPOINT TLVs.
	When receiving a PCReq, a PCE unable to resolve the identifier in one of		When receiving a PCReq, a PCE unable to resolve the identifier in one of
	those TLVs MUST respond using a PCRep with NO-PATH and set the bit		those TLVs <bcp14>MUST</bcp14> respond by using a PCRep with NO-PATH a nd setting the bit
	"Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV.		"Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV.
	The response SHOULD include the END-POINTS object with only the unsupp orted TLV(s).		The response <bcp14>SHOULD</bcp14> include the END-POINTS object with only the unsupported TLV(s).
	</t>		</t>
	<t>		<t pn="section-2.5.1-15">
	A PCE MAY support either or both of the LABEL-REQUEST and LABEL-SET		A PCE <bcp14>MAY</bcp14> support either or both of the
	TLVs.		LABEL-REQUEST and LABEL-SET TLVs.
	If a PCE finds a non-supported TLV in the END-POINTS the		If a PCE finds a non-supported TLV in the END-POINTS, the PCE
	PCE MUST respond with a PCErr message with Error-Type=4 (Not support		<bcp14>MUST</bcp14> respond with a PCErr message with Error-Type=4
	ed object)		(Not supported object) and Error-value=8 (Unsupported TLV present
	and Error-value=TBA-15 (Unsupported TLV present in END-POINTS Genera		in END-POINTS Generalized Endpoint object type), and the message
	lized Endpoint object type) and the message SHOULD include the END-POINTS object		<bcp14>SHOULD</bcp14> include the END-POINTS object in the
	in the response with only the endpoint and endpoint restriction TLV it did not		response with only the endpoint and endpoint restriction TLV it
	understand.		did not understand. A PCE supporting those TLVs but not being
	A PCE supporting those TLVs but not being able to fulfil the label re		able to fulfill the label restriction <bcp14>MUST</bcp14> send a
	striction MUST send		response with a NO-PATH object that has the bit "No endpoint label
	a response with a NO-PATH object which has the bit "No endpoint label		resource" or "No endpoint label resource in range" set in the
	resource" or "No endpoint label resource in range" set in		NO-PATH-VECTOR TLV. The response <bcp14>SHOULD</bcp14> include an
	the NO-PATH-VECTOR TLV.		END-POINTS object containing only the TLV(s) related to the
	The response SHOULD include an END-POINTS object		constraints the PCE could not meet.
	containing only the TLV(s) related to the constraints the PCE could n
	ot meet.
	</t>		</t>
			</section>
	</section> <!--New ENDPOINTS ObjType : generalized -->		<section anchor="endpoints_tlvs" numbered="true" toc="include" removeInR
			FC="false" pn="section-2.5.2">
	<section title="END-POINTS TLV Extensions" anchor="endpoints_tlvs">		<name slugifiedName="name-end-points-tlv-extensions">END-POINTS TLV Ex
	<t>All endpoint TLVs have the standard PCEP TLV header as defined in <x		tensions</name>
	ref target="RFC5440"/> Section 7.1. For the Generalized Endpoint Object Type the		<t pn="section-2.5.2-1">All endpoint TLVs have the standard PCEP TLV h
	TLVs MUST follow the ordering defined in <xref target="endpoints_generalized" /		eader as defined in <xref target="RFC5440" sectionFormat="comma" section="7.1" f
	>. </t>		ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-7.1" der
	<section title="IPV4-ADDRESS TLV" anchor="endpoints_tlvs_ipv4">		ivedContent="RFC5440"/>. For the Generalized Endpoint object type, the TLVs <bcp
	<t>This TLV represents a numbered endpoint using IPv4 numbering,		14>MUST</bcp14> follow the ordering defined in <xref target="endpoints_generaliz
	the format of the IPv4-ADDRESS TLV value (TLV-Type=TBA-6) is as		ed" format="default" sectionFormat="of" derivedContent="Section 2.5.1"/>. </t>
	follows:		<section anchor="endpoints_tlvs_ipv4" numbered="true" toc="exclude" re
			moveInRFC="false" pn="section-2.5.2.1">
			<name slugifiedName="name-ipv4-address-tlv">IPV4-ADDRESS TLV</name>
			<t pn="section-2.5.2.1-1">The IPV4-ADDRESS TLV (Type 39) represents
			a numbered endpoint
			using IPv4 numbering. The format of the TLV value is as follows:
	</t>		</t>
	<figure>		<artwork name="" type="" align="left" alt="" pn="section-2.5.2.1-2">
	<artwork><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |		| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<t pn="section-2.5.2.1-3">
	<t>		This TLV <bcp14>MAY</bcp14> be ignored, in which case a PCRep with N
	This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD b		O-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref target="endpoint
	e returned, as described in <xref target="endpoints_generalized" />.		s_generalized" format="default" sectionFormat="of" derivedContent="Section 2.5.1
	</t>		"/>.
			</t>
	</section>		</section>
	<section title="IPV6-ADDRESS TLV" anchor="endpoints_tlvs_ipv6">		<section anchor="endpoints_tlvs_ipv6" numbered="true" toc="exclude" re
	<t>This TLV represents a numbered endpoint using IPV6 numbering,		moveInRFC="false" pn="section-2.5.2.2">
	the format of the IPv6-ADDRESS TLV value (TLV-Type=TBA-7) is as		<name slugifiedName="name-ipv6-address-tlv">IPV6-ADDRESS TLV</name>
	follows:		<t pn="section-2.5.2.2-1">The IPv6-ADDRESS TLV (Type 40) represents
			a numbered endpoint
			using IPV6 numbering. The format of the TLV value is as follows:
	</t>		</t>
	<figure>		<artwork name="" type="" align="left" alt="" pn="section-2.5.2.2-2">
	<artwork><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv6 address (16 bytes) |		| IPv6 address (16 bytes) |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<t pn="section-2.5.2.2-3">
	<t>		This TLV <bcp14>MAY</bcp14> be ignored, in which case a PCRep with N
	This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD b		O-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref target="endpoint
	e returned, as described in <xref target="endpoints_generalized" />.		s_generalized" format="default" sectionFormat="of" derivedContent="Section 2.5.1
	</t>		"/>.
			</t>
	</section>		</section>
			<section anchor="endpoints_tlvs_unnumbered-if" numbered="true" toc="ex
	<section title="UNNUMBERED-ENDPOINT TLV" anchor="endpoints_tlvs_unnumb		clude" removeInRFC="false" pn="section-2.5.2.3">
	ered-if">		<name slugifiedName="name-unnumbered-endpoint-tlv">UNNUMBERED-ENDPOI
	<t>This TLV represents an unnumbered interface. This TLV has the sam		NT TLV</name>
	e semantic as in <xref target="RFC3477"/>.		<t pn="section-2.5.2.3-1">The UNNUMBERED-ENDPOINT TLV (Type 41) repr
	The TLV value is encoded as follows (TLV-Type=TBA-8)		esents an unnumbered interface. This TLV has the
			same semantic as in <xref target="RFC3477" format="default" sectionF
			ormat="of" derivedContent="RFC3477"/>.
			The TLV value is encoded as follows:
	</t>		</t>
	<figure>		<artwork name="" type="" align="left" alt="" pn="section-2.5.2.3-2">
	<artwork><![CDATA[
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSR's Router ID |		| LSR's Router ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface ID (32 bits) |		| Interface ID (32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<t pn="section-2.5.2.3-3">
	<t>		This TLV <bcp14>MAY</bcp14> be ignored, in which case a PCRep with N
	This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD b		O-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref target="endpoint
	e returned, as described in <xref target="endpoints_generalized" />.		s_generalized" format="default" sectionFormat="of" derivedContent="Section 2.5.1
	</t>		"/>.
	</section>
	<section title="LABEL-REQUEST TLV" anchor="endpoints_tlvs_label-reques
	t">
	<t>The LABEL-REQUEST TLV indicates the switching
	capability and encoding type of the following label
	restriction list for the endpoint. The value format and encoding
	is the same as described in <xref target="RFC3471"></xref>
	Section 3.1 Generalized label request. The LABEL-REQUEST
	TLV uses TLV-Type=TBA-9. The Encoding Type indicates the
	encoding type, e.g., SONET/SDH/GigE etc., of the LSP with
	which the data is associated. The Switching type indicates
	the type of switching that is being requested on the
	endpoint. G-PID identifies the payload. This TLV and the
	following one are defined to satisfy requirement 13 of
	<xref target="RFC7025"/> for the endpoint. It is not directly relate
	d to the TE-LSP label request, which is expressed by the SWITCH-LAYER object.</t
	>
	<t>
	On the path calculation request only the GENERALIZED-BANDWIDTH and S
	WITCH-LAYER need to be coherent, the endpoint labels could be different (support
	ing a different LABEL-REQUEST). Hence the label restrictions include a Generaliz
	ed label request in order to interpret the labels.
	This TLV MAY be ignored, in which case a PCRep with NO-PATH SHOULD b
	e returned, as described in <xref target="endpoints_generalized" />.
	</t>		</t>
	</section>		</section>
	<section title="LABEL-SET TLV" anchor="endpoints_tlvs_labels">		<section anchor="endpoints_tlvs_label-request" numbered="true" toc="ex
	<t>Label or label range restrictions can be specified for the TE-LSP		clude" removeInRFC="false" pn="section-2.5.2.4">
	endpoints. Those are encoded using the LABEL-SET TLV. The label value need to b		<name slugifiedName="name-label-request-tlv">LABEL-REQUEST TLV</name
	e interpreted with a description on the Encoding and switching type. The REQ-ADA		>
	P-CAP object from <xref target="RFC8282"></xref> can be used in case of mono-lay		<t pn="section-2.5.2.4-1">The LABEL-REQUEST TLV (Type 42) indicates
	er request, however in case of multilayer it is possible to have more than one o		the switching
	bject, so it is better to have a dedicated TLV for the label and label request.		capability and encoding type of the following label restriction
	These TLVs MAY be ignored, in which case a response with NO-PATH SHO		list for the endpoint. The value format and encoding is the same
	ULD be returned, as described in <xref target="endpoints_generalized" />.		as described in <xref target="RFC3471" sectionFormat="of" section="3
	TLVs are encoded as follows (following <xref target="RFC5440"></xref		.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3471#section-3.1
	>):		" derivedContent="RFC3471"/> for the Generalized Label Request. The LSP
			Encoding Type field indicates the encoding type, e.g., SONET, SDH,
			GigE, etc., of the LSP with which the data is associated. The
			Switching Type field indicates the type of switching that is being
			requested on the endpoint. The Generalized Protocol Identifier
			(G-PID) field identifies the payload. This TLV and the following
			one are defined to satisfy requirement 13 in <xref target="RFC7025"
			sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-edito
			r.org/rfc/rfc7025#section-3.1" derivedContent="RFC7025"/> for the
			endpoint. It is not directly related to the TE-LSP label request,
			which is expressed by the SWITCH-LAYER object.</t>
			<t pn="section-2.5.2.4-2">
			On the path calculation request, only the GENERALIZED-BANDWIDTH and
			SWITCH-LAYER need to be coherent; the endpoint labels could be different (suppor
			ting a different LABEL-REQUEST). Hence, the label restrictions include a General
			ized Label Request in order to interpret the labels.
			This TLV <bcp14>MAY</bcp14> be ignored, in which case a PCRep with N
			O-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref target="endpoint
			s_generalized" format="default" sectionFormat="of" derivedContent="Section 2.5.1
			"/>.
	</t>		</t>
	<t><list style='symbols'>		</section>
	<t>LABEL-SET TLV, Type=TBA-10. The TLV Length is		<section anchor="endpoints_tlvs_labels" numbered="true" toc="exclude"
	variable, Encoding follows <xref		removeInRFC="false" pn="section-2.5.2.5">
	target="RFC3471"></xref> Section 3.5 "Label set" with		<name slugifiedName="name-label-set-tlv">LABEL-SET TLV</name>
	the addition of a U bit, O bit and L bit. The L bit is		<t pn="section-2.5.2.5-1">Label or label range restrictions can be s
	used to represent a suggested set of labels, following		pecified for the
	the semantic of SUGGESTED_LABEL defined by <xref		TE-LSP endpoints. Those are encoded using the LABEL-SET TLV. The
	target="RFC3471"></xref>.		label value needs to be interpreted with a description on the
	<figure>		encoding and switching type. The REQ-ADAP-CAP object <xref target="R
	<artwork><![CDATA[		FC8282" format="default" sectionFormat="of" derivedContent="RFC8282"/> can be us
	0 1 2 3		ed in case of a
	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		mono-layer request; however, in case of a multi-layer request, it
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		is possible to have more than one object, so it is better to have
	| Action | Reserved |L|O|U| Label Type |		a dedicated TLV for the label and label request. These TLVs
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		<bcp14>MAY</bcp14> be ignored, in which case a response with
	| Subchannel 1 |		NO-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref tar
	| ... |		get="endpoints_generalized" format="default" sectionFormat="of" derivedContent="
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		Section 2.5.1"/>. Per <xref target="RFC5440" format="default" sectionFormat="of
	: : :		" derivedContent="RFC5440"/>, the LABEL-SET TLV is encoded as follows.
	: : :		The type of the LABEL-SET TLV is 43. The TLV Length is
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		variable, and the value encoding follows <xref target="RFC3471" sect
	| Subchannel N |		ionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.or
	| ... |		g/rfc/rfc3471#section-3.5" derivedContent="RFC3471"/>, with
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		the addition of a U bit, O bit, and L bit.
	]]></artwork>		The L bit is
	</figure></t>		used to represent a suggested set of labels, following
	</list>		the semantic of Suggested Label as defined by <xref target="RFC347
			1" format="default" sectionFormat="of" derivedContent="RFC3471"/>.
	</t>		</t>
			<artwork name="" type="" align="left" alt="" pn="section-2.5.2.5-2">
	<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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Action | Reserved |L|O|U| Label Type |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Subchannel 1 |
			| ... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			: : :
			: : :
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Subchannel N |
			| ... |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			</artwork>
			<t pn="section-2.5.2.5-3">
	A LABEL-SET TLV represents a set of possible labels that		A LABEL-SET TLV represents a set of possible labels that
	can be used on an interface. If the L bit is cleared,		can be used on an interface. If the L bit is cleared,
	the label allocated on the first endpoint MUST be within the label set range. The action parameter in the Label set indicates the type of list pro vided. These parameters are described by <xref target="RFC3471"></xref> Section 3.5.1.		the label allocated on the first endpoint <bcp14>MUST</bcp14> be w ithin the label set range. The Action parameter in the LABEL-SET indicates the t ype of list provided. These parameters are described by <xref target="RFC3471" s ectionFormat="comma" section="3.5.1" format="default" derivedLink="https://rfc-e ditor.org/rfc/rfc3471#section-3.5.1" derivedContent="RFC3471"/>.
	</t>		</t>
	<t>		<t pn="section-2.5.2.5-4">
	The U, O and L bits have the following meaning:		The U, O, and L bits are defined as follows:
	</t>		</t>
	<texttable anchor='endpoints_tlvs_labels_bits'		<ul spacing="normal" empty="true" bare="false" pn="section-2.5.2.5-5
	suppress-title='true' style='none'		">
	title='Labels TLV bits'>		<li pn="section-2.5.2.5-5.1">
	<ttcol align='center'></ttcol>		<dl spacing="normal" newline="false" pn="section-2.5.2.5-5.1.1">
	<ttcol align='left'></ttcol>		<dt pn="section-2.5.2.5-5.1.1.1">U:</dt>
	<c>U:</c><c>Upstream direction: The U bit is set for upstream (rev		<dd pn="section-2.5.2.5-5.1.1.2">Upstream direction. Set for t
	ers) direction in case of bidirectional LSP.</c>		he upstream (reverse)
	<c>O:</c><c>Old Label: set when the TLV represent the		direction in case of bidirectional LSP.</dd>
	old (previously allocated) label in case of re-optimization.		<dt pn="section-2.5.2.5-5.1.1.3">O:</dt>
			<dd pn="section-2.5.2.5-5.1.1.4">Old label. Set when the TLV r
	The R bit of the RP object MUST be set to 1. If the L bit		epresents the old
	is set, this bit SHOULD be set to 0 and ignored on receipt.		(previously allocated) label in case of reoptimization. The R
			bit of the RP object <bcp14>MUST</bcp14> be set to 1. If the L
	When this bit is set, the Action field MUST be set to 0		bit is set, this bit <bcp14>SHOULD</bcp14> be set to 0 and
	(Inclusive List) and the Label Set MUST contain one		ignored on receipt. When this bit is set, the Action field
	subchannel.</c>		<bcp14>MUST</bcp14> be set to 0 (Inclusive List), and the
	<c>L:</c><c>Loose Label: set when the TLV indicates to the PCE a s		LABEL-SET <bcp14>MUST</bcp14> contain one subchannel.</dd>
	et of		<dt pn="section-2.5.2.5-5.1.1.5">L:</dt>
	preferred (ordered) labels to be used. The PCE MAY use those		<dd pn="section-2.5.2.5-5.1.1.6">Loose label. Set when the TLV
	labels for label allocation.		indicates to the
	</c>		PCE that a set of preferred (ordered) labels are to be
	</texttable>		used. The PCE <bcp14>MAY</bcp14> use those labels for label
	<t>		allocation. </dd>
	Several LABEL_SET TLVs MAY be present with the O bit		</dl>
	cleared, LABEL_SET TLVs with L bit set can		</li>
	be combined with a LABEL_SET TLV with L bit cleared.		</ul>
			<t pn="section-2.5.2.5-6">
			Several LABEL_SET TLVs <bcp14>MAY</bcp14> be present with the O bi
			t
			cleared; LABEL_SET TLVs with the L bit set can
			be combined with a LABEL_SET TLV with the L bit cleared.
	There MUST NOT be more than two LABEL_SET TLVs present with the		There <bcp14>MUST NOT</bcp14> be more than two LABEL_SET TLVs pres
	O bit set. If there are two LABEL_SET TLVs present, there MUST NOT		ent with the
	be more than one with the U bit set, and there MUST NOT be more		O bit set. If there are two LABEL_SET TLVs present, there <bcp14>M
			UST NOT</bcp14>
			be more than one with the U bit set, and there <bcp14>MUST NOT</bc
			p14> be more
	than one with the U bit cleared. For a		than one with the U bit cleared. For a
	given U bit value, if more than one LABEL_SET TLV with the O bit s et		given U bit value, if more than one LABEL_SET TLV with the O bit s et
	is present, the first TLV MUST be processed and the following TLVs		is present, the first TLV <bcp14>MUST</bcp14> be processed, and th
	with the same U and O bit MUST be ignored.		e following TLVs
			that have the same U and O bits <bcp14>MUST</bcp14> be ignored.
	</t>		</t>
	<t>		<t pn="section-2.5.2.5-7">
	A LABEL-SET TLV with the O and L bit set MUST trigger a		A LABEL-SET TLV with the O and L bits set <bcp14>MUST</bcp14> trig
			ger a
	PCErr message with Error-Type=10 (Reception of an invalid		PCErr message with Error-Type=10 (Reception of an invalid
	object) Error-value=TBA-25 (Wrong LABEL-SET TLV present with O		object) and Error-value=29 (Wrong LABEL-SET TLV present with O
	and L bit set).		and L bits set).
	</t>		</t>
	<t>		<t pn="section-2.5.2.5-8">
	A LABEL-SET TLV with the O bit set and an Action Field		A LABEL-SET TLV that has the O bit set and an Action field
	not set to 0 (Inclusive list) or containing more than		not set to 0 (Inclusive List) or that contains more than
	one subchannel MUST trigger a PCErr message with Error-Type=10 (		one subchannel <bcp14>MUST</bcp14> trigger a PCErr message with Er
	Reception of an invalid object) Error-value=TBA-26 (Wrong		ror-Type=10 (Reception of an invalid object) and Error-value=30 (Wrong
	LABEL-SET TLV present with O bit and wrong format).		LABEL-SET TLV present with O bit set and wrong format).
	</t>		</t>
	<t>If a LABEL-SET TLV is present with O bit set, the R		<t pn="section-2.5.2.5-9">If a LABEL-SET TLV is present with the O b
	bit of the RP object MUST be set, otherwise a PCErr		it set, the R bit of
	message MUST be sent with Error-Type=10 (Reception of an invalid obj		the RP object <bcp14>MUST</bcp14> be set; otherwise, a PCErr
	ect)		message <bcp14>MUST</bcp14> be sent with Error-Type=10 (Reception
	Error-value=TBA-24 (LABEL-SET TLV present with O bit set but without		of an invalid object) and Error-value=28 (LABEL-SET TLV
	R bit set in RP).</t>		present with O bit set but without R bit set in RP).</t>
	</section> <!-- end Label TLV -->		</section>
	</section> <!-- ENDPOINTS TLVs extensions -->		</section>
	</section> <!-- ENDPOINTS extensions -->		</section>
	<!-- IRO extension -->		<section anchor="iro-label" numbered="true" toc="include" removeInRFC="fal
	<section title="IRO Extension" anchor="iro-label">		se" pn="section-2.6">
	<t>The IRO as defined in <xref target="RFC5440" /> is used to		<name slugifiedName="name-iro-extension">IRO Extension</name>
			<t pn="section-2.6-1">The IRO as defined in <xref target="RFC5440" forma
			t="default" sectionFormat="of" derivedContent="RFC5440"/> is used to
	include specific objects in the path. RSVP-TE allows the inclusion of a		include specific objects in the path. RSVP-TE allows the inclusion of a
	label definition. In order to fulfill requirement 13 of <xref		label definition. In order to fulfill requirement 13 in <xref target="RFC7025"
	target="RFC7025"/> the IRO needs to support the new subobject type as defined		sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-edit
	in <xref target="RFC3473" />:		or.org/rfc/rfc7025#section-3.1" derivedContent="RFC7025"/>, the IRO needs to sup
	</t>		port the new subobject type as defined in <xref target="RFC3473" format="default
	<texttable suppress-title='true' style='none' >		" sectionFormat="of" derivedContent="RFC3473"/>:
	<ttcol align='left'></ttcol>		</t>
	<ttcol align='left'></ttcol>		<table align="center" pn="table-5">
	<c>Type</c><c>Sub-object </c>		<thead>
	<c>TBA-38</c><c> LABEL</c>		<tr>
	</texttable>		<th align="left" colspan="1" rowspan="1">Type</th>
	<t>The Label subobject MUST follow a subobject identifying a link, currently a		<th align="left" colspan="1" rowspan="1">Subobject</th>
	n IP address subobject (Type 1 or 2) or an interface ID (type 4) subobject.		</tr>
	If an IP address subobject is used, then the given IP address MUST be associat		</thead>
	ed with a link.		<tbody>
	More than one label subobject MAY follow each link subobject.		<tr>
	The procedure associated with this subobject is as follows.		<td align="left" colspan="1" rowspan="1">10</td>
	</t>		<td align="left" colspan="1" rowspan="1">Label</td>
	<t>		</tr>
	If the PCE is able to allocate labels (e.g., via explicit label control) the PC		</tbody>
	E MUST allocate one label from within the set of label values for the given link		</table>
	.		<t pn="section-2.6-3">The Label subobject <bcp14>MUST</bcp14> follow a s
	If the PCE does not assign labels, then it sends a response with a		ubobject
	NO-PATH object, containing a NO-PATH-VECTOR TLV with the bit 'No label resource		identifying a link, currently an IP address subobject (Type 1 or 2) or
	in range' set.		an interface ID (Type 4) subobject. If an IP address subobject is
	</t>		used, then the given IP address <bcp14>MUST</bcp14> be associated with
	</section>		a link. More than one Label subobject <bcp14>MAY</bcp14> follow each
	<!-- End IRO -->		subobject identifying a link. The procedure associated with this subobj
	<!-- XRO extension -->		ect is as
	<section title="XRO Extension" anchor="xro-label">		follows.
	<t>The XRO as defined in <xref target="RFC5521" /> is used to		</t>
			<t pn="section-2.6-4">
			If the PCE is able to allocate labels (e.g., via explicit label control), the
			PCE <bcp14>MUST</bcp14> allocate one label from within the set of label
			values for the given link. If the PCE does not assign labels, then it sends
			a response with a NO-PATH object, containing a NO-PATH-VECTOR TLV with the
			bit "No label resource in range" set.
			</t>
			</section>
			<section anchor="xro-label" numbered="true" toc="include" removeInRFC="fal
			se" pn="section-2.7">
			<name slugifiedName="name-xro-extension">XRO Extension</name>
			<t pn="section-2.7-1">The XRO as defined in <xref target="RFC5521" forma
			t="default" sectionFormat="of" derivedContent="RFC5521"/> is used to
	exclude specific objects in the path. RSVP-TE allows the exclusion of certain		exclude specific objects in the path. RSVP-TE allows the exclusion of certain
	labels (<xref target="RFC6001"/>). In order to fulfill requirement		labels <xref target="RFC6001" format="default" sectionFormat="of" derivedConte
	13 of <xref target="RFC7025" /> Section 3.1, the PCEP's XRO needs to		nt="RFC6001"/>. In order to fulfill requirement
			13 in <xref target="RFC7025" sectionFormat="of" section="3.1" format="default"
			derivedLink="https://rfc-editor.org/rfc/rfc7025#section-3.1" derivedContent="RF
			C7025"/>, the PCEP's XRO needs to
	support a new subobject to enable label exclusion.</t>		support a new subobject to enable label exclusion.</t>
	<t>		<t pn="section-2.7-2">
	The encoding of the XRO Label subobject follows the encoding		The encoding of the XRO Label subobject follows the encoding
	of the Label ERO subobject defined in <xref target="RFC3473" /> and XRO subob		of the ERO Label subobject defined in <xref target="RFC3473" format="default"
	ject defined in <xref target="RFC5521" />. The		sectionFormat="of" derivedContent="RFC3473"/> and the XRO subobject defined in
	XRO Label subobject represent one Label and is defined as follows:		<xref target="RFC5521" format="default" sectionFormat="of" derivedContent="RFC55
	</t>		21"/>. The
	<figure>		XRO Label subobject (Type 10) represents one label and is defined as follows:
	<preamble>XRO Subobject Type TBA-39: Label Subobject.</preamble>		</t>
	<artwork><![CDATA[		<artwork name="" type="" align="left" alt="" pn="section-2.7-3">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|X| Type=TBA-39 | Length |U| Reserved | C-Type |		|X| Type=10 | Length |U| Reserved | C-Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label |		| Label |
	| ... |		| ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	</figure>		<dl newline="false" spacing="normal" pn="section-2.7-4">
	<t>		<dt pn="section-2.7-4.1">X (1 bit):</dt>
	<list style='empty'>		<dd pn="section-2.7-4.2">See <xref target="RFC5521" format="default" s
	<t>X (1 bit): as per <xref target="RFC5521" />.		ectionFormat="of" derivedContent="RFC5521"/>. The X bit indicates whether the e
	The X-bit indicates whether the exclusion is mandatory or desired.		xclusion is
	0 indicates that the resource specified MUST be excluded from the		mandatory or desired. 0 indicates that the resource specified
	path computed by the PCE. 1 indicates that the resource specified		<bcp14>MUST</bcp14> be excluded from the path computed by the PCE. 1
	SHOULD be excluded from the path computed by the PCE, but MAY be		indicates that the resource specified <bcp14>SHOULD</bcp14> be
	included subject to PCE policy and the absence of a viable path		excluded from the path computed by the PCE, but it
	that meets the other constraints and excludes the resource.		<bcp14>MAY</bcp14> be included subject to the PCE policy and the
	</t>		absence of a viable path that meets the other constraints and
	<t>Type (7 bits): The Type of the XRO Label subobject is TBA-39<!--, sugg		excludes the resource.</dd>
	ested value 3-->.</t>		<dt pn="section-2.7-4.3">Type (7 bits):</dt>
	<t>Length (8 bits): see <xref target="RFC5521" />, the total		<dd pn="section-2.7-4.4">The type of the XRO Label subobject is
	length of the subobject in bytes (including the Type and Length fields).		10.</dd>
	The Length is always divisible by 4.</t>		<dt pn="section-2.7-4.5">Length (8 bits):</dt>
	<t>U (1 bit): see <xref target="RFC3471" /> Section 6.1.</t>		<dd pn="section-2.7-4.6">See <xref target="RFC5521" format="default" s
	<t>C-Type (8 bits): the C-Type of the included Label Object as defined in		ectionFormat="of" derivedContent="RFC5521"/>. The total length of the subobject
	<xref target="RFC3473" />.</t>		in bytes
	<t>Label: see <xref target="RFC3471" />.</t>		(including the Type and Length fields). The length is always
	</list>		divisible by 4.</dd>
			<dt pn="section-2.7-4.7">U (1 bit):</dt>
	The Label subobject MUST follow a subobject identifying a link,		<dd pn="section-2.7-4.8">See <xref target="RFC3471" sectionFormat="com
			ma" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc34
			71#section-6.1" derivedContent="RFC3471"/>.</dd>
			<dt pn="section-2.7-4.9">C-Type (8 bits):</dt>
			<dd pn="section-2.7-4.10">The C-Type of the included Label object
			as defined in <xref target="RFC3473" format="default" sectionFormat="of
			" derivedContent="RFC3473"/>.</dd>
			<dt pn="section-2.7-4.11">Label:</dt>
			<dd pn="section-2.7-4.12">See <xref target="RFC3471" format="default"
			sectionFormat="of" derivedContent="RFC3471"/>.</dd>
			</dl>
			<t pn="section-2.7-5">
			The Label subobject <bcp14>MUST</bcp14> follow a subobject identifying a lin
			k,
	currently an IP address subobject (Type 1 or 2) or an interface ID		currently an IP address subobject (Type 1 or 2) or an interface ID
	(type 4) subobject. If an IP address subobject is used, then the		(Type 4) subobject. If an IP address subobject is used, the
	given IP address MUST be associated with a link. More than one		given IP address <bcp14>MUST</bcp14> be associated with a link. More than one
	label subobject MAY follow each link subobject.		label subobject <bcp14>MAY</bcp14> follow a subobject identifying a link.
	</t>		</t>
	<texttable suppress-title='true' style='none' >		<table align="center" pn="table-6">
	<ttcol align='left'></ttcol>		<thead>
	<ttcol align='left'></ttcol>		<tr>
	<c>Type</c><c>Sub-object </c>		<th align="left" colspan="1" rowspan="1">Type</th>
	<c>3</c><c>LABEL</c>		<th align="left" colspan="1" rowspan="1">Subobject</th>
	</texttable>		</tr>
	</section>		</thead>
	<!-- End XRO-->		<tbody>
			<tr>
	<section title="LSPA Extensions" anchor="lspa">		<td align="left" colspan="1" rowspan="1">10</td>
	<t>		<td align="left" colspan="1" rowspan="1">Label</td>
			</tr>
			</tbody>
			</table>
			</section>
			<section anchor="lspa" numbered="true" toc="include" removeInRFC="false" p
			n="section-2.8">
			<name slugifiedName="name-lspa-extensions">LSPA Extensions</name>
			<t pn="section-2.8-1">
	The LSPA carries the LSP attributes. In the end-to-end		The LSPA carries the LSP attributes. In the end-to-end
	recovery context, this also includes the protection state information.		recovery context, this also includes the protection state information.
	A new TLV is defined to fulfil requirement 7 of <xref		A new TLV is defined to fulfill requirement 7 in <xref target="RFC7025
	target="RFC7025" /> Section 3.1 and requirement 3 of <xref		" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-edi
	target="RFC7025" /> Section 3.2. This TLV contains the information of		tor.org/rfc/rfc7025#section-3.1" derivedContent="RFC7025"/> and requirement 3 in
	the PROTECTION object defined by <xref target="RFC4872"/> and can be used as a p		<xref target="RFC7025" sectionFormat="of" section="3.2" format="default" derive
	olicy input.		dLink="https://rfc-editor.org/rfc/rfc7025#section-3.2" derivedContent="RFC7025"/
	The LSPA object MAY carry a PROTECTION-ATTRIBUTE TLV defined as:		>. This TLV contains the information of the PROTECTION object defined by <xref t
	Type TBA-12: PROTECTION-ATTRIBUTE</t>		arget="RFC4872" format="default" sectionFormat="of" derivedContent="RFC4872"/> a
	<figure>		nd can be used as a policy input.
	<artwork><![CDATA[		The LSPA object <bcp14>MAY</bcp14> carry a PROTECTION-ATTRIBUTE TLV
			(Type 44), which is defined as follows:</t>
			<artwork name="" type="" align="left" alt="" pn="section-2.8-2">
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|		|S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|I|R| Reserved | Seg.Flags | Reserved |		|I|R| Reserved | Seg.Flags | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		</artwork>
	<postamble>The content is as defined in <xref target="RFC4872"></xref>		<t pn="section-2.8-3">The content is as defined in <xref target="RFC4872
	Section 14, <xref target="RFC4873"></xref> Section 6.1.</postamble>		" sectionFormat="comma" section="14" format="default" derivedLink="https://rfc-e
	</figure>		ditor.org/rfc/rfc4872#section-14" derivedContent="RFC4872"/> and <xref target="R
	<t>LSP (protection) Flags or Link flags field can be used by a		FC4873" sectionFormat="comma" section="6.1" format="default" derivedLink="https:
			//rfc-editor.org/rfc/rfc4873#section-6.1" derivedContent="RFC4873"/>.</t>
			<t pn="section-2.8-4">The LSP (protection) Flags field or the Link Flags
			field can be used by a
	PCE implementation for routing policy input. The other attributes are on ly meaningful for a stateful PCE.</t>		PCE implementation for routing policy input. The other attributes are on ly meaningful for a stateful PCE.</t>
	<t>This TLV is OPTIONAL and MAY be ignored by the PCE. If ignored by the		<t pn="section-2.8-5">This TLV is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY
	PCE, it		</bcp14> be ignored by the PCE. If ignored by the PCE, it
	MUST NOT include the TLV in the LSPA of the response.		<bcp14>MUST NOT</bcp14> include the TLV in the LSPA of the response.
	When the TLV is used by the PCE, a LSPA object and the PROTECTION-ATTRIB		When the TLV is used by the PCE, an LSPA object and the PROTECTION-ATTRI
	UTE TLV MUST be included in the response. Fields that were not considered MUST b		BUTE TLV <bcp14>MUST</bcp14> be included in the response. Fields that were not c
	e set to 0.		onsidered <bcp14>MUST</bcp14> be set to 0.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-2.9
	<section title="NO-PATH Object Extension">		">
	<t>		<name slugifiedName="name-no-path-object-extension">NO-PATH Object Exten
			sion</name>
			<t pn="section-2.9-1">
	The NO-PATH object is used in PCRep messages in response to an		The NO-PATH object is used in PCRep messages in response to an
	unsuccessful path computation request (the PCE could not find a path		unsuccessful Path Computation Request (the PCE could not find a path
	satisfying the set of constraints). In this scenario, PCE MUST		satisfying the set of constraints). In this scenario, the PCE <bcp14>
			MUST</bcp14>
	include a NO-PATH object in the PCRep message.		include a NO-PATH object in the PCRep message.
	The NO-PATH object MAY carry the NO-PATH-VECTOR TLV that specifies mor e		The NO-PATH object <bcp14>MAY</bcp14> carry the NO-PATH-VECTOR TLV tha t specifies more
	information on the reasons that led to a negative reply. In case of		information on the reasons that led to a negative reply. In case of
	GMPLS networks there could be some additional constraints that		GMPLS networks, there could be some additional constraints that
	led to the failure such as protection mismatch, lack of resources, and		led to the failure such as protection mismatch, lack of resources, and
	so on. Several new flags have been defined in the 32-bit flag field of		so on. Several new flags have been defined in the 32-bit Flag field of
	the		the
	NO-PATH-VECTOR TLV but no modifications have been made in the NO-PATH		NO-PATH-VECTOR TLV, but no modifications have been made in the NO-PATH
	object.		object.
	</t>		</t>
	<section title="Extensions to NO-PATH-VECTOR TLV" anchor="no-path_bits">		<section anchor="no-path_bits" numbered="true" toc="include" removeInRFC
	<t>		="false" pn="section-2.9.1">
			<name slugifiedName="name-extensions-to-no-path-vecto">Extensions to N
			O-PATH-VECTOR TLV</name>
			<t pn="section-2.9.1-1">
	The modified NO-PATH-VECTOR TLV carrying the additional information		The modified NO-PATH-VECTOR TLV carrying the additional information
	is as follows:		is as follows:
	<list>
	<t>Bit number TBA-32 - Protection Mismatch (1-bit). Specifies the
	mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in the request.
	</t>
	<t>Bit number TBA-33 - No Resource (1-bit). Specifies that the res
	ources are not currently sufficient to provide the path. </t>
	<t>Bit number TBA-34 - Granularity not supported
	(1-bit). Specifies that the PCE is not able to provide a
	path with the requested granularity. </t>
	<t>Bit number TBA-35 - No endpoint label resource (1-bit). Specifi
	es that the PCE is not able to provide a path because of the endpoint label rest
	riction. </t>
	<t>Bit number TBA-36 - No endpoint label resource in range (1-bit)
	. Specifies that the PCE is not able to provide a path because of the endpoint l
	abel set restriction. </t>
	<t>Bit number TBA-37 - No label resource in range (1-bit). Specifi
	es that the PCE is not able to provide a path because of the label set restricti
	on. </t>
	</list>
	</t>		</t>
	</section> <!-- NO-Path vector TLV -->		<ul empty="true" spacing="normal" bare="false" pn="section-2.9.1-2">
	</section> <!-- end NO-PATH -->		<li pn="section-2.9.1-2.1">
			<dl spacing="normal" newline="false" pn="section-2.9.1-2.1.1">
	</section> <!-- End PCEP Object and Extensions-->		<dt pn="section-2.9.1-2.1.1.1">Bit number 18:</dt>
			<dd pn="section-2.9.1-2.1.1.2">Protection Mismatch (1 bit). Spec
	<section title="Additional Error-Types and Error-Values Defined" anchor="err		ifies the mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in the
	or-codes">		request. </dd>
	<t>		<dt pn="section-2.9.1-2.1.1.3">Bit number 17:</dt>
			<dd pn="section-2.9.1-2.1.1.4">No Resource (1 bit). Specifies th
			at the resources are not currently sufficient to provide the path. </dd>
			<dt pn="section-2.9.1-2.1.1.5">Bit number 16:</dt>
			<dd pn="section-2.9.1-2.1.1.6">Granularity not supported
			(1 bit). Specifies that the PCE is not able to provide a
			path with the requested granularity. </dd>
			<dt pn="section-2.9.1-2.1.1.7">Bit number 15:</dt>
			<dd pn="section-2.9.1-2.1.1.8">No endpoint label resource (1 bit
			). Specifies that the PCE is not able to provide a path because of the endpoint
			label restriction.</dd>
			<dt pn="section-2.9.1-2.1.1.9">Bit number 14:</dt>
			<dd pn="section-2.9.1-2.1.1.10">No endpoint label resource in ra
			nge (1 bit). Specifies that the PCE is not able to provide a path because of the
			endpoint label set restriction. </dd>
			<dt pn="section-2.9.1-2.1.1.11">Bit number 13:</dt>
			<dd pn="section-2.9.1-2.1.1.12">No label resource in range (1
			bit). Specifies that the PCE is not able to provide a path because
			of the label set restriction.</dd>
			<dt pn="section-2.9.1-2.1.1.13">Bit number 12:</dt>
			<dd pn="section-2.9.1-2.1.1.14">LOAD-BALANCING could not be perf
			ormed
			with the bandwidth constraints (1 bit). Specifies that the PCE is
			not able to provide a path because it could not map the BANDWIDTH
			into the parameters specified by the LOAD-BALANCING.</dd>
			</dl>
			</li>
			</ul>
			</section>
			</section>
			</section>
			<section anchor="error-codes" numbered="true" toc="include" removeInRFC="fal
			se" pn="section-3">
			<name slugifiedName="name-additional-error-types-and-">Additional Error-Ty
			pes and Error-Values Defined</name>
			<t pn="section-3-1">
	A PCEP-ERROR object is used to report a PCEP error and is		A PCEP-ERROR object is used to report a PCEP error and is
	characterized by an Error-Type that specifies the type of error while		characterized by an Error-Type that specifies the type of error and an
	Error-value that provides additional information about the error. An add		Error-value that provides additional information about the error. An
	itional error type and several error values are defined to		additional Error-Type and several Error-values are defined to
	represent some of the errors related to the newly identified objects		represent some of the errors related to the newly identified objects,
	related to GMPLS networks.		which are related to GMPLS networks.
	For each PCEP error, an Error-Type and an Error-value are defined.		For each PCEP error, an Error-Type and an Error-value are defined.
	Error-Type 1 to 10 are already defined in <xref target="RFC5440"></xref>		Error-Types 1 to 10 are already defined in <xref target="RFC5440" format
	. Additional Error-values are defined for Error-Types 4 and 10. A new Error-Type		="default" sectionFormat="of" derivedContent="RFC5440"/>. Additional Error-value
	is defined (value TBA-27).		s are defined for
			Error-Types 4 and 10. A new Error-Type 29 (Path computation failure)
			is defined in this document.
	</t>		</t>
	<t>		<t pn="section-3-2">
	The Error-Type TBA-27 (path computation failure) is used to reflect cons		Error-Type 29 (Path computation failure) is used to reflect
	traints not understood by the PCE, for instance when the PCE is not able to unde		constraints not understood by the PCE, for instance, when the PCE is
	rstand the generalized bandwidth. If the constraints are understood, but the PCE		not able to understand the Generalized bandwidth. If the constraints
	is unable to find with those constraints, the NO-PATH is to be used.		are understood, but the PCE is unable to find those constraints,
			NO-PATH is to be used.
	</t>		</t>
	<texttable suppress-title='true' style='none'>		<table align="center" pn="table-7">
	<ttcol align='center' width="4%">Error-Type</ttcol>		<thead>
	<ttcol align='left' width="14%">Error-value</ttcol>		<tr>
	<ttcol align='left' width="53%"></ttcol>		<th align="left" colspan="1" rowspan="1">Error-Type</th>
			<th align="left" colspan="1" rowspan="1">Meaning</th>
	<c>4</c><c>Not supported object </c><c></c>		<th align="left" colspan="1" rowspan="1">Error-value</th>
			</tr>
	<c></c><c>value=TBA-14:</c><c>Bandwidth Object type TBA-2 or TBA-3 not s		</thead>
	upported</c>		<tbody>
	<c></c><c>value=TBA-15:</c><c>Unsupported endpoint type in </c>		<tr>
	<c></c><c></c><c>END-POINTS Generalized Endpoint</c>		<td align="left" colspan="1" rowspan="1">4</td>
	<c></c><c></c><c>object type</c>		<td align="left" colspan="1" rowspan="1">Not supported object</td>
	<c></c><c>value=TBA-16:</c><c>Unsupported TLV present in END-POINTS Gene		<td align="left" colspan="1" rowspan="1"/>
	ralized Endpoint object type</c>		</tr>
	<c></c><c>value=TBA-17:</c><c>Unsupported granularity in the RP object f		<tr>
	lags</c>		<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
	<c>10</c><c>Reception of an invalid object</c><c></c>		<td align="left" colspan="1" rowspan="1">6: BANDWIDTH object type 3
	<c></c><c>value=TBA-18:</c><c>Bad Bandwidth Object type		or 4 not supported</td>
	TBA-2(Generalized bandwidth) or TBA-3( Generalized bandwidth of		</tr>
	existing TE-LSP for which a reoptimization is requested)</c>		<tr>
	<c></c><c>value=TBA-20:</c><c>Unsupported LSP Protection Flags in PROT		<td align="left" colspan="1" rowspan="1"/>
	ECTION-ATTRIBUTE TLV</c>		<td align="left" colspan="1" rowspan="1"/>
	<c></c><c>value=TBA-21:</c><c>Unsupported Secondary LSP Protection Fla		<td align="left" colspan="1" rowspan="1">7: Unsupported endpoint typ
	gs in PROTECTION-ATTRIBUTE TLV</c>		e in END-POINTS
	<c></c><c>value=TBA-22:</c><c>Unsupported Link Protection Type in PROT		Generalized Endpoint object type</td>
	ECTION-ATTRIBUTE TLV</c>		</tr>
	<c></c><c>value=TBA-24:</c><c>LABEL-SET TLV present with 0 bit set but		<tr>
	without R bit set in RP</c>		<td align="left" colspan="1" rowspan="1"/>
	<c></c><c>value=TBA-25:</c><c>Wrong LABEL-SET</c>		<td align="left" colspan="1" rowspan="1"/>
	<c></c><c></c><c>TLV present with</c>		<td align="left" colspan="1" rowspan="1">8: Unsupported TLV present
	<c></c><c></c><c>0 and L bit set</c>		in END-POINTS
	<c></c><c>value=TBA-26:</c><c>Wrong LABEL-SET with O bit		Generalized Endpoint object type</td>
	set and wrong format</c>		</tr>
	<c></c><c>value=TBA-42:</c><c>Missing GMPLS-CAPABILITY TLV</c>		<tr>
	<c>TBA-27</c><c>Path computation failure</c><c></c>		<td align="left" colspan="1" rowspan="1"/>
	<c></c><c>value=0:</c><c>Unassigned</c>		<td align="left" colspan="1" rowspan="1"/>
	<c></c><c>value=TBA-28:</c><c>Unacceptable request message</c>		<td align="left" colspan="1" rowspan="1">9: Unsupported granularity
	<c></c><c>value=TBA-29:</c><c>Generalized bandwidth value not supporte		in the RP object
	d</c>		flags</td>
	<c></c><c>value=TBA-30:</c><c>Label Set constraint could not be</c>		</tr>
	<c></c><c></c><c>met</c>		<tr>
	<c></c><c>value=TBA-31:</c><c>Label constraint could not be</c>		<td align="left" colspan="1" rowspan="1">10</td>
	<c></c><c></c><c>met</c>		<td align="left" colspan="1" rowspan="1">Reception of an invalid obj
			ect </td>
	</texttable>		<td align="left" colspan="1" rowspan="1"/>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">24: Bad BANDWIDTH object ty
			pe 3 or 4</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">25: Unsupported LSP Protect
			ion Flags in
			PROTECTION-ATTRIBUTE TLV</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">26: Unsupported Secondary L
			SP Protection Flags
			in PROTECTION-ATTRIBUTE TLV</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">27: Unsupported Link Protec
			tion Type in
			PROTECTION-ATTRIBUTE TLV</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">28: LABEL-SET TLV present w
			ith O bit set but
			without R bit set in RP</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">29: Wrong LABEL-SET TLV pre
			sent with O and L
			bits set</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">30: Wrong LABEL-SET TLV pre
			sent with O bit set and wrong
			format</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">31: Missing GMPLS-CAPABILIT
			Y TLV</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">29</td>
			<td align="left" colspan="1" rowspan="1">Path computation failure</t
			d>
			<td align="left" colspan="1" rowspan="1"/>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">0: Unassigned</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">1: Unacceptable request mes
			sage</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">2: Generalized bandwidth va
			lue not
			supported</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">3: Label set constraint cou
			ld not be met</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">4: Label constraint could n
			ot be met</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
	<section title="Manageability Considerations">		<name slugifiedName="name-manageability-consideration">Manageability Consi
	<t>This section follows the guidance of <xref target="RFC6123" />.</t>		derations</name>
	<section title="Control of Function through Configuration and Policy">		<t pn="section-4-1">This section follows the guidance of <xref target="RFC
	<t>		6123" format="default" sectionFormat="of" derivedContent="RFC6123"/>.</t>
	This document makes no change to the basic operation of PCEP and so		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
			">
			<name slugifiedName="name-control-of-function-through">Control of Functi
			on through Configuration and Policy</name>
			<t pn="section-4.1-1">
			This document makes no change to the basic operation of PCEP, so
	the requirements described in		the requirements described in
	<xref target="RFC5440" /> Section 8.1. also apply to this document.		<xref target="RFC5440" sectionFormat="comma" section="8.1" format="def
	In addition to those requirements a PCEP implementation may allow the		ault" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.1" derivedConten
			t="RFC5440"/> also apply to this document.
			In addition to those requirements, a PCEP implementation may allow the
	configuration of the following parameters:		configuration of the following parameters:
	<list>		</t>
	<t>Accepted RG in the RP object.</t>		<ul empty="false" spacing="normal" bare="false" pn="section-4.1-2">
	<t>Default RG to use (overriding the one present in the PCReq)</t>		<li pn="section-4.1-2.1">Accepted RG in the RP object.</li>
	<t>Accepted BANDWIDTH object type TBA-2 and TBA-3 parameters in requ		<li pn="section-4.1-2.2">Default RG to use (overriding the one present
	est, default mapping to use when not specified in the request</t>		in the PCReq).</li>
	<t>Accepted LOAD-BALANCING object type TBA-4 parameters in request.<		<li pn="section-4.1-2.3">Accepted BANDWIDTH object type 3 and 4 parame
	/t>		ters in the
	<t>Accepted endpoint type and allowed TLVs in object END-POINTS with		request and default mapping to use when not specified in the request.</
	object type Generalized Endpoint.</t>		li>
	<t>Accepted range for label restrictions in label restriction in END		<li pn="section-4.1-2.4">Accepted LOAD-BALANCING object type 2 paramet
	-POINTS, or IRO or XRO objects</t>		ers in request.</li>
	<t>PROTECTION-ATTRIBUTE TLV acceptance and suppression.</t>		<li pn="section-4.1-2.5">Accepted endpoint type and allowed TLVs in ob
	</list>		ject END-POINTS with the object type Generalized Endpoint.</li>
	The configuration of the above parameters is applicable to the differe		<li pn="section-4.1-2.6">Accepted range for label restrictions in END-
	nt sessions as described in <xref target="RFC5440" /> Section 8.1 (by default, p		POINTS or IRO/XRO objects.</li>
	er PCEP peer, etc.).		<li pn="section-4.1-2.7">Acceptance and suppression of the PROTECTION-
			ATTRIBUTE TLV.</li>
			</ul>
			<t pn="section-4.1-3">
			The configuration of the above parameters is applicable to the differe
			nt sessions as described in <xref target="RFC5440" sectionFormat="comma" section
			="8.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-
			8.1" derivedContent="RFC5440"/> (by default, per PCEP peer, etc.).
	</t>		</t>
	</section>		</section>
	<section title="Information and Data Models">		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.2
	<t>		">
	This document makes no change to the basic operation of PCEP and so		<name slugifiedName="name-information-and-data-models">Information and D
			ata Models</name>
			<t pn="section-4.2-1">
			This document makes no change to the basic operation of PCEP, so
	the requirements described in		the requirements described in
	<xref target="RFC5440" /> Section 8.2. also apply to this document.		<xref target="RFC5440" sectionFormat="comma" section="8.2" format="def
	This document does not introduce any new ERO sub objects, so that the		ault" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-8.2" derivedConten
	, ERO information model is already covered in <xref target="RFC4802"/>.		t="RFC5440"/> also apply to this document.
			This document does not introduce any new ERO subobjects; the ERO info
			rmation model is already covered in <xref target="RFC4802" format="default" sect
			ionFormat="of" derivedContent="RFC4802"/>.
	</t>		</t>
	</section>		</section>
	<section title="Liveness Detection and Monitoring">		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.3
	<t>		">
	This document makes no change to the basic operation of PCEP and so		<name slugifiedName="name-liveness-detection-and-moni">Liveness Detectio
			n and Monitoring</name>
			<t pn="section-4.3-1">
			This document makes no change to the basic operation of PCEP, so
	there are no changes to the requirements for liveness detection and		there are no changes to the requirements for liveness detection and
	monitoring set out in <xref target="RFC4657" /> and <xref target="RFC5 440" /> Section 8.3.		monitoring in <xref target="RFC4657" format="default" sectionFormat="o f" derivedContent="RFC4657"/> and <xref target="RFC5440" sectionFormat="comma" s ection="8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#se ction-8.3" derivedContent="RFC5440"/>.
	</t>		</t>
	</section>		</section>
	<section title="Verifying Correct Operation">		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.4
	<t>		">
	This document makes no change to the basic operations of PCEP and cons		<name slugifiedName="name-verifying-correct-operation">Verifying Correct
	iderations described in <xref target="RFC5440" /> Section 8.4.		Operation</name>
			<t pn="section-4.4-1">
			This document makes no change to the basic operations of PCEP and the
			considerations described in <xref target="RFC5440" sectionFormat="comma" section
			="8.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-
			8.4" derivedContent="RFC5440"/>.
	New errors defined by this document should satisfy the requirement to log error events.		New errors defined by this document should satisfy the requirement to log error events.
	</t>		</t>
	</section>		</section>
	<section title="Requirements on Other Protocols and Functional Components"		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.5
	>		">
	<t>No new Requirements on Other Protocols and Functional		<name slugifiedName="name-requirements-on-other-proto">Requirements on O
	Components are made by this document. This document does not		ther Protocols and Functional Components</name>
			<t pn="section-4.5-1">No new requirements on other protocols and functio
			nal
			components are made by this document. This document does not
	require ERO object extensions. Any new ERO subobject defined		require ERO object extensions. Any new ERO subobject defined
	in the TEAS or CCAMP working group can be adopted without modifying the operations defined in this document. </t>		in the TEAS or CCAMP Working Groups can be adopted without modifying the operations defined in this document. </t>
	</section>		</section>
	<section title="Impact on Network Operation">		<section numbered="true" toc="include" removeInRFC="false" pn="section-4.6
	<t>This document makes no change to the basic operations of PCEP and con		">
	siderations described in <xref target="RFC5440" /> Section 8.6.		<name slugifiedName="name-impact-on-network-operation">Impact on Network
	In addition to the limit on the rate of messages sent by a PCEP speaker,		Operation</name>
	a limit MAY be placed on the size of the PCEP messages.		<t pn="section-4.6-1">This document makes no change to the basic operati
			ons of PCEP and the considerations described in <xref target="RFC5440" sectionFo
			rmat="comma" section="8.6" format="default" derivedLink="https://rfc-editor.org/
			rfc/rfc5440#section-8.6" derivedContent="RFC5440"/>.
			In addition to the limit on the rate of messages sent by a PCEP speaker,
			a limit <bcp14>MAY</bcp14> be placed on the size of the PCEP messages.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section title="IANA Considerations">		<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
	<t>		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	IANA assigns values to the PCEP objects and TLVs. IANA is		<t pn="section-5-1">
	requested to make some allocations for the newly defined objects and		IANA assigns values to PCEP objects and TLVs. IANA has
	TLVs defined in this document. Also, IANA is requested to manage		made allocations for the newly defined objects and
	the space of flags that are newly added in the TLVs.		TLVs defined in this document. In addition, IANA manages
			the space of flags that have been newly added in the TLVs.
	</t>		</t>
	<section title="PCEP Objects">		<section numbered="true" toc="include" removeInRFC="false" pn="section-5.1
	<t>As described in <xref target="generalized-bandwidth"/>, <xref target="g		">
	eneralized-load-balancing"/> and <xref target="endpoints_generalized" /> new Obj		<name slugifiedName="name-pcep-objects">PCEP Objects</name>
	ects types are defined.		<t pn="section-5.1-1">New object types are defined in Sections <xref tar
	IANA is requested to make the following Object-Type		get="generalized-bandwidth" format="counter" sectionFormat="of" derivedContent="
	allocations from the "PCEP Objects" sub-registry.		2.3"/>, <xref target="generalized-load-balancing" format="counter" sectionFormat
			="of" derivedContent="2.4"/>, and <xref target="endpoints_generalized" format="c
			ounter" sectionFormat="of" derivedContent="2.5.1"/>. IANA has made
			the following Object-Type allocations in the "PCEP Objects"
			subregistry.
	</t>		</t>
	<texttable suppress-title='true' style='none' anchor='iana_gen_bw'>		<table anchor="iana_gen_bw" align="center" pn="table-8">
	<ttcol align='left'></ttcol>		<thead>
	<ttcol align='left'></ttcol>		<tr>
	<c>Object Class</c><c>5</c>		<th align="left" colspan="1" rowspan="1">Object-Class Value</th>
	<c>Name</c><c> BANDWIDTH</c>		<th align="left" colspan="1" rowspan="1">Name</th>
	<c>Object-Type</c><c>TBA-2: Generalized bandwidth </c>		<th align="left" colspan="1" rowspan="1">Object-Type</th>
	<c> </c><c>TBA-3: Generalized bandwidth of an existing TE-LS		<th align="left" colspan="1" rowspan="1">Reference</th>
	P for which a reoptimization is requested </c>		</tr>
	<c>Reference</c><c>This document (<xref target="generalized-bandwidth"		</thead>
	></xref>)</c>		<tbody>
	<c /><c />		<tr>
	<c>Object Class</c><c>14</c>		<td align="left" colspan="1" rowspan="1">5</td>
	<c>Name</c><c> LOAD-BALANCING</c>		<td align="left" colspan="1" rowspan="1">BANDWIDTH</td>
	<c>Object-Type</c><c>TBA-4: Generalized Load Balancing </c>		<td align="left" colspan="1" rowspan="1">3: Generalized bandwidth<
	<c /><c />		/td>
	<c>Reference</c><c>This document (<xref target="generalized-load-balan		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="g
	cing"></xref>)</c>		eneralized-bandwidth" format="default" sectionFormat="of" derivedContent="Sectio
	<c>Object Class</c><c>4</c>		n 2.3"/></td>
	<c>Name</c><c> END-POINTS</c>		</tr>
	<c>Object-Type</c><c>TBA-5: Generalized Endpoint </c>		<tr>
	<c>Reference</c><c>This document (<xref target="endpoints_extensions">		<td align="left" colspan="1" rowspan="1"/>
	</xref>)</c>		<td align="left" colspan="1" rowspan="1"/>
	</texttable>		<td align="left" colspan="1" rowspan="1">4: Generalized bandwidth
			of an existing TE-LSP
	</section> <!-- End New PCEP Objects-->		for which a reoptimization is requested</td>
	<section title="Endpoint type field in Generalized END-POINTS Object">		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="g
	<t>IANA is requested to create a registry to manage the Endpoint Type fie		eneralized-bandwidth" format="default" sectionFormat="of" derivedContent="Sectio
	ld of the END-POINTS object, Object Type Generalized Endpoint and manage the cod		n 2.3"/></td>
	e space.</t>		</tr>
	<t>New endpoint type in the Reserved range are assigned by		<tr>
	Standards Action <xref target="RFC8126"/>. Each endpoint type should		<td align="left" colspan="1" rowspan="1">14</td>
	be tracked with the following attributes:		<td align="left" colspan="1" rowspan="1">LOAD-BALANCING</td>
	<list style='symbols'>		<td align="left" colspan="1" rowspan="1">2: Generalized Load Balan
	<t>Endpoint type</t>		cing</td>
	<t>Description</t>		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="g
	<t>Defining RFC</t>		eneralized-load-balancing" format="default" sectionFormat="of" derivedContent="S
	</list>		ection 2.4"/></td>
	</t>		</tr>
	<t>New endpoint type in the Experimental range are for experimental us		<tr>
	e; these will not be registered with IANA and MUST NOT be mentioned by RFCs.</t>		<td align="left" colspan="1" rowspan="1">4</td>
	<t>The following values have been defined by this document.		<td align="left" colspan="1" rowspan="1">END-POINTS</td>
	(<xref target="endpoints_generalized"></xref>, <xref		<td align="left" colspan="1" rowspan="1">5: Generalized Endpoint</
	target="endpoints_generalized_endpoint-type" />):</t>		td>
	<texttable suppress-title='true' style='none'>		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="e
	<ttcol align='left'>Value</ttcol>		ndpoints_extensions" format="default" sectionFormat="of" derivedContent="Section
	<ttcol align='left'>Type</ttcol>		2.5"/></td>
	<ttcol align='left'>Meaning</ttcol>		</tr>
	<c>0</c><c>Point-to-Point</c> <c></c>		</tbody>
	<c>1</c><c>Point-to-Multipoint</c><c>New leaves to add</c>		</table>
	<c>2</c><c></c> <c>Old leaves to remove</c>		</section>
	<c>3</c><c></c> <c>Old leaves whose path can be m		<section numbered="true" toc="include" removeInRFC="false" pn="section-5.2
	odified/reoptimized</c>		">
	<c>4</c><c></c> <c>Old leaves whose path has to b		<name slugifiedName="name-endpoint-type-field-in-the-">Endpoint Type Fie
	e</c>		ld in the Generalized END-POINTS Object</name>
	<c></c><c></c> <c>left unchanged</c>		<t pn="section-5.2-1">IANA has created a new "Generalized Endpoint Types
	<c>5-244</c><c>Unassigned</c><c></c>		" registry to
	<c>245-255</c> <c>Experimental range</c><c></c>		manage the Endpoint Type field of the END-POINTS object, the object
	</texttable>		type Generalized Endpoint, and the code space.</t>
	</section> <!-- End END-POINTS object, Object Type Generalized Endpoint-->		<t pn="section-5.2-2">New endpoint types in the Unassigned range are ass
			igned by
	<section title="New PCEP TLVs" anchor='iana-tlvs'>		Standards Action <xref target="RFC8126" format="default" sectionFormat="
	<t>		of" derivedContent="RFC8126"/>. Each
	IANA manages the PCEP TLV code point registry (see <xref target="RFC544		endpoint type should be tracked with the following attributes:
	0"></xref>). This		</t>
	is maintained as the "PCEP TLV Type Indicators" sub-registry of the		<ul spacing="normal" bare="false" empty="false" pn="section-5.2-3">
			<li pn="section-5.2-3.1">Value</li>
			<li pn="section-5.2-3.2">Type</li>
			<li pn="section-5.2-3.3">Defining RFC</li>
			</ul>
			<t pn="section-5.2-4">New endpoint types in the Experimental Use range w
			ill not be
			registered with IANA and <bcp14>MUST NOT</bcp14> be mentioned by any
			RFCs.</t>
			<t pn="section-5.2-5">The following values are defined by this document
			(see <xref target="endpoints_generalized_endpoint-type" format="defaul
			t" sectionFormat="of" derivedContent="Table 4"/> in <xref target="endpoints_gene
			ralized" format="default" sectionFormat="of" derivedContent="Section 2.5.1"/>):<
			/t>
			<table align="center" pn="table-9">
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Value</th>
			<th align="left" colspan="1" rowspan="1">Type</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">0</td>
			<td align="left" colspan="1" rowspan="1">Point-to-Point</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">1</td>
			<td align="left" colspan="1" rowspan="1">Point-to-Multipoint with
			leaf type 1</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">2</td>
			<td align="left" colspan="1" rowspan="1">Point-to-Multipoint with
			leaf type 2</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">3</td>
			<td align="left" colspan="1" rowspan="1">Point-to-Multipoint with
			leaf type 3</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">4</td>
			<td align="left" colspan="1" rowspan="1">Point-to-Multipoint with
			leaf type 4</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">5-244</td>
			<td align="left" colspan="1" rowspan="1">Unassigned</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">245-255</td>
			<td align="left" colspan="1" rowspan="1">Experimental Use</td>
			</tr>
			</tbody>
			</table>
			</section>
			<section anchor="iana-tlvs" numbered="true" toc="include" removeInRFC="fal
			se" pn="section-5.3">
			<name slugifiedName="name-new-pcep-tlvs">New PCEP TLVs</name>
			<t pn="section-5.3-1">
			IANA manages a registry for PCEP TLV code points (see <xref target="RFC
			5440" format="default" sectionFormat="of" derivedContent="RFC5440"/>), which
			is maintained as the "PCEP TLV Type Indicators" subregistry of the
	"Path Computation Element Protocol (PCEP) Numbers" registry.		"Path Computation Element Protocol (PCEP) Numbers" registry.
	IANA is requested to do the following allocation.		IANA has allocated the following per this document:
	Note: TBA-11 is not used
	<!-- The values here are suggested for use by IANA. -->
	</t>
	<texttable suppress-title='true' style='none'>
	<ttcol align='center'>Value</ttcol>
	<ttcol align='left'>Meaning</ttcol>
	<ttcol align='left'>Reference</ttcol>
	<c>TBA-6</c><c>IPV4-ADDRESS</c><c> This document (<xref tar
	get="endpoints_tlvs_ipv4"></xref>) </c>
	<c>TBA-7</c><c>IPV6-ADDRESS</c><c> This document (<xref tar
	get="endpoints_tlvs_ipv6"></xref>) </c>
	<c>TBA-8</c><c>UNNUMBERED-ENDPOINT</c><c> This document (<x
	ref target="endpoints_tlvs_unnumbered-if"></xref>) </c>
	<c>TBA-9</c><c>LABEL-REQUEST</c><c> This document (<xref ta
	rget="endpoints_tlvs_label-request"></xref>) </c>
	<c>TBA-10</c><c>LABEL-SET</c><c> This document (<xref targe
	t="endpoints_tlvs_labels"></xref>) </c>
	<c>TBA-12 </c><c>PROTECTION-ATTRIBUTE</c><c> This document (<xre
	f target="lspa"></xref>) </c>
	<c>TBA-1</c><c>GMPLS-CAPABILITY</c><c> This document (<xref targ
	et="open-extensions"></xref>) </c>
	</texttable>
	</section> <!-- End New PCEP TLVs-->
	<section title="RP Object Flag Field">
	<t>
	As described in <xref target="rp-extensions"></xref> new flag are defin
	ed in the RP Object Flag
	IANA is requested to make the following Object-Type
	allocations from the "RP Object Flag Field" sub-registry.
	<!-- The values here are suggested for use by IANA. -->
	</t>
	<texttable suppress-title='true' style='none'>
	<ttcol align='center'>Bit</ttcol>
	<ttcol align='left'>Description</ttcol>
	<ttcol align='left'>Reference</ttcol>
	<c>TBA-13</c><c>routing granularity (2 bits)</c><c>This document, <xre
	f target="rp-extensions"></xref></c>
	<c><!-- (suggested bit 17-16) --></c><c> (RG)</c><c></c>
	</texttable>
	</section> <!-- RP object flag-->
	<section title="New PCEP Error Codes">
	<t>As described in <xref target="error-codes"></xref>, new PCEP Error-Ty
	pes and Error-values are
	defined. IANA is requested to make the following allocation in the "PCEP
	-ERROR Object Error Types and Values" registry.
	<!-- The values here are suggested for use by IANA. -->
	</t>
	<texttable suppress-title='true' style='none'>
	<ttcol align='left' >Error</ttcol>
	<ttcol align='left' width="50">name</ttcol>
	<ttcol align='left' >Reference</ttcol>
	<c>Type=4</c><c>Not supported object </c><c><xref target="RFC5440" /><
	/c>
	<c>Value=TBA-14:</c><c>Bandwidth Object type TBA-2 or TBA-3 not suppor
	ted</c><c>This Document</c>
	<c>Value=TBA-15:</c><c>Unsupported endpoint type in END-POINTS General
	ized Endpoint object type</c><c>This Document</c>
	<c>Value=TBA-16:</c><c>Unsupported TLV present in END-POINTS Generaliz
	ed Endpoint object type</c><c>This Document</c>
	<c>Value=TBA-17:</c><c>Unsupported granularity in the RP object flags<
	/c><c>This Document</c>
	<c>Type=10</c><c>Reception of an invalid object </c><c><xref target="R		</t>
	FC5440" /></c>		<table align="center" pn="table-10">
	<c>Value=TBA-18:</c><c> Bad Bandwidth Object		<thead>
	type TBA-2(Generalized bandwidth) or TBA-3(Generalized		<tr>
	bandwidth of existing TE-LSP for which a reoptimization is requested)<		<th align="center" colspan="1" rowspan="1">Value</th>
	/c><c>This Document</c>		<th align="left" colspan="1" rowspan="1">Meaning</th>
	<c>Value=TBA-20:</c><c> Unsupported LSP Protection Flags in PROTECTION		<th align="left" colspan="1" rowspan="1">Reference</th>
	-ATTRIBUTE TLV</c><c>This Document</c>		</tr>
	<c>Value=TBA-21:</c><c> Unsupported Secondary LSP Protection Flags in		</thead>
	PROTECTION-ATTRIBUTE TLV</c><c>This Document</c>		<tbody>
	<c>Value=TBA-22:</c><c> Unsupported Link Protection Type in PROTECTION		<tr>
	-ATTRIBUTE TLV</c><c>This Document</c>		<td align="center" colspan="1" rowspan="1">39</td>
	<c>Value=TBA-24:</c><c> LABEL-SET TLV present with 0 bit set but witho		<td align="left" colspan="1" rowspan="1">IPV4-ADDRESS</td>
	ut R bit set in RP</c><c>This Document</c>		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="e
	<c>Value=TBA-25:</c><c> Wrong LABEL-SET TLV present with 0 and L bit s		ndpoints_tlvs_ipv4" format="default" sectionFormat="of" derivedContent="Section
	et</c><c>This Document</c>		2.5.2.1"/></td>
	<c>Value=TBA-26:</c><c> Wrong LABEL-SET with O bit set and wrong forma		</tr>
	t</c><c>This Document</c>		<tr>
	<c>Value=TBA-42:</c><c> Missing GMPLS-CAPABILITY TLV</c><c>This Docume		<td align="center" colspan="1" rowspan="1">40</td>
	nt</c>		<td align="left" colspan="1" rowspan="1">IPV6-ADDRESS</td>
	<c>Type=TBA-27</c><c>Path computation		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="e
	failure</c><c>This Document</c>		ndpoints_tlvs_ipv6" format="default" sectionFormat="of" derivedContent="Section
	<c>Value=0</c><c> Unassigned</c><c>This Document</c>		2.5.2.2"/></td>
	<c>Value=TBA-28:</c><c>Unacceptable request message</c><c>This Documen		</tr>
	t</c>		<tr>
	<c>Value=TBA-29:</c><c>Generalized bandwidth value not supported</c><c		<td align="center" colspan="1" rowspan="1">41</td>
	>This Document</c>		<td align="left" colspan="1" rowspan="1">UNNUMBERED-ENDPOINT</td>
	<c>Value=TBA-30:</c><c>Label Set constraint could not be met</c><c>Thi		<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="e
	s Document</c>		ndpoints_tlvs_unnumbered-if" format="default" sectionFormat="of" derivedContent=
	<c>Value=TBA-31:</c><c>Label constraint could not be met</c><c>This Do		"Section 2.5.2.3"/></td>
	cument</c>		</tr>
			<tr>
			<td align="center" colspan="1" rowspan="1">42</td>
			<td align="left" colspan="1" rowspan="1">LABEL-REQUEST</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="e
			ndpoints_tlvs_label-request" format="default" sectionFormat="of" derivedContent=
			"Section 2.5.2.4"/></td>
			</tr>
			<tr>
			<td align="center" colspan="1" rowspan="1">43</td>
			<td align="left" colspan="1" rowspan="1">LABEL-SET</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="e
			ndpoints_tlvs_labels" format="default" sectionFormat="of" derivedContent="Sectio
			n 2.5.2.5"/></td>
			</tr>
			<tr>
			<td align="center" colspan="1" rowspan="1">44 </td>
			<td align="left" colspan="1" rowspan="1">PROTECTION-ATTRIBUTE</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="l
			spa" format="default" sectionFormat="of" derivedContent="Section 2.8"/></td>
			</tr>
			<tr>
			<td align="center" colspan="1" rowspan="1">45</td>
			<td align="left" colspan="1" rowspan="1">GMPLS-CAPABILITY</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="o
			pen-extensions" format="default" sectionFormat="of" derivedContent="Section 2.1.
			2"/></td>
			</tr>
			</tbody>
			</table>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-5.4
			">
			<name slugifiedName="name-rp-object-flag-field">RP Object Flag Field</na
			me>
			<t pn="section-5.4-1">
			A new flag is defined in <xref target="rp-extensions" format="default"
			sectionFormat="of" derivedContent="Section 2.2"/> for the Flags field of the RP
			object. IANA has
			made the following allocation in the "RP Object Flag
			Field" subregistry:
	</texttable>		</t>
			<table align="center" pn="table-11">
			<thead>
			<tr>
			<th align="center" colspan="1" rowspan="1">Bit</th>
			<th align="left" colspan="1" rowspan="1">Description</th>
			<th align="left" colspan="1" rowspan="1">Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="center" colspan="1" rowspan="1">15-16</td>
			<td align="left" colspan="1" rowspan="1">Routing Granularity (RG)<
			/td>
			<td align="left" colspan="1" rowspan="1">RFC 8779, <xref target="r
			p-extensions" format="default" sectionFormat="of" derivedContent="Section 2.2"/>
			</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-5.5
			">
			<name slugifiedName="name-new-pcep-error-codes">New PCEP Error Codes</na
			me>
			<t pn="section-5.5-1">New PCEP Error-Types and Error-values are defined
			in <xref target="error-codes" format="default" sectionFormat="of" derivedContent
			="Section 3"/>. IANA has made the
			following allocations in the "PCEP-ERROR Object Error Types and Values"
			registry:
	<section title="New NO-PATH-VECTOR TLV Fields">		</t>
	<t>As described in <xref target="no-path_bits"></xref>, new NO-PATH-VECT		<table align="center" pn="table-12">
	OR TLV Flag Fields have been defined.		<thead>
	IANA is requested to do the following allocations in the "NO-PATH-VECTOR TLV Fla		<tr>
	g Field" sub-registry.		<th align="left" colspan="1" rowspan="1">Error-Type</th>
	<!-- The values here are suggested for use by IANA. -->		<th align="left" colspan="1" rowspan="1">Meaning</th>
	<list>		<th align="left" colspan="1" rowspan="1">Error-value</th>
	<t>Bit number TBA-32 - Protection Mismatch (1-bit). Specifies the		<th align="left" colspan="1" rowspan="1">Reference</th>
	mismatch of the protection type of the PROTECTION-ATTRIBUTE TLV in the request.		</tr>
	</t>		</thead>
	<t>Bit number TBA-33 - No Resource (1-bit). Specifies that the res		<tbody>
	ources are not currently sufficient to provide the path. </t>		<tr>
	<t>Bit number TBA-34 - Granularity not supported (1-bit). Specifie		<td align="left" colspan="1" rowspan="1">4</td>
	s that the PCE is not able to provide a path with the requested granularity. </t		<td align="left" colspan="1" rowspan="1">Not supported object</td>
	>		<td align="left" colspan="1" rowspan="1"/>
	<t>Bit number TBA-35 - No endpoint label resource (1-bit). Specifi		<td align="left" colspan="1" rowspan="1">
	es that the PCE is not able to provide a path because of the endpoint label rest		<xref target="RFC5440" format="default" sectionFormat="of" deriv
	riction. </t>		edContent="RFC5440"/></td>
	<t>Bit number TBA-36 - No endpoint label resource in range (1-bit)		</tr>
	. Specifies that the PCE is not able to provide a path because of the endpoint l		<tr>
	abel set restriction. </t>		<td align="left" colspan="1" rowspan="1"/>
	<t>Bit number TBA-37 - No label resource in range (1-bit). Specifi		<td align="left" colspan="1" rowspan="1"/>
	es that the PCE is not able to provide a path because of the label set restricti		<td align="left" colspan="1" rowspan="1">6: BANDWIDTH object type
	on. </t>		3 or 4 not supported</td>
	<t>Bit number TBA-40 - LOAD-BALANCING could not be performed with		<td align="left" colspan="1" rowspan="1">RFC 8779</td>
	the bandwidth constraits (1 bit). Specifies that the PCE is not able to provide		</tr>
	a path because it could not map the BANDWIDTH into the parameters specified by t		<tr>
	he LOAD-BALANCING. </t>		<td align="left" colspan="1" rowspan="1"/>
	</list>		<td align="left" colspan="1" rowspan="1"/>
	</t>		<td align="left" colspan="1" rowspan="1">7: Unsupported endpoint t
			ype in END-POINTS
			Generalized Endpoint object type</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">8: Unsupported TLV presen
			t in END-POINTS
			Generalized Endpoint object type</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">9: Unsupported granularit
			y in the RP object flags</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">10</td>
			<td align="left" colspan="1" rowspan="1">Reception of an invalid o
			bject </td>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">
			<xref target="RFC5440" format="default" sectionFormat="of" deriv
			edContent="RFC5440"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">24: Bad BANDWIDTH object
			type 3 or 4</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">25: Unsupported LSP Prote
			ction Flags in
			PROTECTION-ATTRIBUTE TLV</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">26: Unsupported Secondary
			LSP Protection Flags
			in PROTECTION-ATTRIBUTE TLV</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">27: Unsupported Link Prot
			ection Type in
			PROTECTION-ATTRIBUTE TLV</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">28: LABEL-SET TLV present
			with O bit set but
			without R bit set in RP</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">29: Wrong LABEL-SET TLV p
			resent with O and L bits set</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">30: Wrong LABEL-SET TLV p
			resent with O bit set and wrong format</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">31: Missing GMPLS-CAPABIL
			ITY TLV</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">29</td>
			<td align="left" colspan="1" rowspan="1">Path computation failure<
			/td>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">0: Unassigned</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">1: Unacceptable request m
			essage</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">2: Generalized bandwidth
			value not supported</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">3: Label set constraint c
			ould not be met</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1"/>
			<td align="left" colspan="1" rowspan="1">4: Label constraint could
			not be met</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section title="New Subobject for the Include Route Object" >		<section numbered="true" toc="include" removeInRFC="false" pn="section-5.6
	<t>The "PCEP Parameters" registry contains a subregistry "IRO Subobjects		">
	"		<name slugifiedName="name-new-bits-in-no-path-vector-">New Bits in NO-PA
	with an entry for the Include Route Object (IRO).</t>		TH-VECTOR TLV</name>
	<t>		<t pn="section-5.6-1">New NO-PATH-VECTOR TLV bits are defined in <xref t
	IANA is requested to add a further subobject that can be carried in th		arget="no-path_bits" format="default" sectionFormat="of" derivedContent="Section
	e IRO as		2.9.1"/>. IANA has made the
			following allocations in the "NO-PATH-VECTOR TLV Flag Field"
			subregistry:
			</t>
			<table anchor="no-path-vector-iana" align="center" pn="table-13">
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Bit</th>
			<th align="left" colspan="1" rowspan="1">Description</th>
			<th align="left" colspan="1" rowspan="1">Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">18</td>
			<td align="left" colspan="1" rowspan="1">Protection Mismatch</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">17</td>
			<td align="left" colspan="1" rowspan="1">No Resource</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">16</td>
			<td align="left" colspan="1" rowspan="1">Granularity not supported
			</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">15</td>
			<td align="left" colspan="1" rowspan="1">No endpoint label resourc
			e</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">14</td>
			<td align="left" colspan="1" rowspan="1">No endpoint label resourc
			e in range</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">13</td>
			<td align="left" colspan="1" rowspan="1">No label resource in rang
			e</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">12</td>
			<td align="left" colspan="1" rowspan="1">LOAD-BALANCING could not
			be performed with the bandwidth constraints</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			</tbody>
			</table>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-5.7
			">
			<name slugifiedName="name-new-subobject-for-the-inclu">New Subobject for
			the Include Route Object</name>
			<t pn="section-5.7-1">IANA has added a new subobject in the "IRO Subobje
			cts" subregistry of the
			"Path Computation Element Protocol (PCEP) Numbers" registry.</t>
			<t pn="section-5.7-2">
			IANA has added a new subobject that can be carried in the IRO as
	follows:		follows:
	</t>		</t>
	<texttable suppress-title='true' style='none'>		<table align="center" pn="table-14">
	<ttcol align='left'>Subobject</ttcol>		<thead>
	<ttcol align='left'>type</ttcol>		<tr>
	<ttcol align='left'>Reference</ttcol>		<th align="left" colspan="1" rowspan="1">Value</th>
	<c>TBA-38<!-- , suggested value 3--></c><c>Label		<th align="left" colspan="1" rowspan="1">Description</th>
	subobject</c><c>This Document</c>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</texttable>		</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">10</td>
			<td align="left" colspan="1" rowspan="1">Label</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section title="New Subobject for the Exclude Route Object" >		<section numbered="true" toc="include" removeInRFC="false" pn="section-5.8
	<t>The "PCEP Parameters" registry contains a subregistry "XRO Subobjects		">
	"		<name slugifiedName="name-new-subobject-for-the-exclu">New Subobject for
	with an entry for the XRO object (Exclude Route Object).</t>		the Exclude Route Object</name>
	<t>		<t pn="section-5.8-1">IANA has added a new subobject in the "XRO Subobje
	IANA is requested to add a further subobject that can be carried in th		cts" subregistry of the
	e XRO as		"Path Computation Element Protocol (PCEP) Numbers" registry.</t>
			<t pn="section-5.8-2">
			IANA has added a new subobject that can be carried in the XRO as
	follows:		follows:
	</t>		</t>
	<texttable suppress-title='true' style='none'>		<table align="center" pn="table-15">
	<ttcol align='left'>Subobject</ttcol>		<thead>
	<ttcol align='left'>type</ttcol>		<tr>
	<ttcol align='left'>Reference</ttcol>		<th align="left" colspan="1" rowspan="1">Value</th>
	<c>TBA-39<!--, suggested value 3--></c><c>Label subobject</c><c>This D		<th align="left" colspan="1" rowspan="1">Description</th>
	ocument</c>		<th align="left" colspan="1" rowspan="1">Reference</th>
	</texttable>		</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">10</td>
			<td align="left" colspan="1" rowspan="1">Label</td>
			<td align="left" colspan="1" rowspan="1">RFC 8779</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	<section title="New GMPLS-CAPABILITY TLV Flag Field" >		<section numbered="true" toc="include" removeInRFC="false" pn="section-5.9
	<t>IANA is requested to create a sub-registry to manage the Flag field		">
	of the GMPLS-CAPABILITY TLV within the "Path Computation		<name slugifiedName="name-new-gmpls-capability-tlv-fl">New GMPLS-CAPABIL
	Element Protocol (PCEP) Numbers" registry.</t>		ITY TLV Flag Field</name>
			<t pn="section-5.9-1">IANA has created a new "GMPLS-CAPABILITY TLV Flag
	<t>New bit numbers are to be assigned by Standards Action <xref target="RFC81		Field"
	26"/>.		subregistry within the "Path Computation Element Protocol (PCEP)
			Numbers" registry to manage the Flag field of the GMPLS-CAPABILITY TLV.<
			/t>
			<t pn="section-5.9-2">New bit numbers are to be assigned by Standards Ac
			tion <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="
			RFC8126"/>.
	Each bit should be tracked with the following qualities:		Each bit should be tracked with the following qualities:
	<list style="symbols">		</t>
			<ul spacing="normal" bare="false" empty="false" pn="section-5.9-3">
	<t>Bit number (counting from bit 0 as the most significant bit)</t>		<li pn="section-5.9-3.1">Bit number (counting from bit 0 as the most s
			ignificant bit)</li>
	<t>Capability description</t>		<li pn="section-5.9-3.2">Capability description</li>
			<li pn="section-5.9-3.3">Defining RFC</li>
	<t>Defining RFC</t>		</ul>
	</list></t>		<t pn="section-5.9-4">The initial contents of the subregistry are empty,
			with bits 0-31
	<t>The initial contents of the sub-registry are empty, with all bits		marked as Unassigned.</t>
	marked unassigned</t>
	</section>		</section>
	</section> <!-- End IANA -->		</section>
	<section title="Security Considerations">		<section numbered="true" toc="include" removeInRFC="false" pn="section-6">
	<t>		<name slugifiedName="name-security-considerations">Security Considerations
			</name>
			<t pn="section-6-1">
	GMPLS controls multiple technologies and types of network elements. The L SPs		GMPLS controls multiple technologies and types of network elements. The L SPs
	that are established using GMPLS, whose paths can be computed using the P CEP		that are established using GMPLS, whose paths can be computed using the P CEP
	extensions to support GMPLS described in this document, can carry a high volume		extensions to support GMPLS described in this document, can carry a high volume
	of traffic and can be a critical part of a network infrastructure. The PC E can then		of traffic and can be a critical part of a network infrastructure. The PC E can then
	play a key role in the use of the resources and in determining the physic al paths		play a key role in the use of the resources and in determining the physic al paths
	of the LSPs and thus it is important to ensure the identity of PCE and PC		of the LSPs; thus, it is important to ensure the identity of the PCE and
	C, as well		PCC, as well
	as the communication channel. In many deployments there will be a complet		as the communication channel. In many deployments, there will be a comple
	ely		tely
	isolated network where an external attack is of very low probability. How ever,		isolated network where an external attack is of very low probability. How ever,
	there are other deployment cases in which the PCC-PCE communication can		there are other deployment cases in which the PCC-PCE communication can
	be more exposed and there could be more security considerations. Three ma		be more exposed, and there could be more security considerations. There a
	in		re three main
	situations in case of an attack in the GMPLS PCE context could happen:		situations in case an attack in the GMPLS PCE context happens:
	<list style="symbols">		</t>
	<t>		<ul spacing="normal" empty="true" bare="false" pn="section-6-2">
	PCE Identity theft: A legitimate PCC could request a path for a GMPLS		<li pn="section-6-2.1">
	LSP to		<dl spacing="normal" newline="false" pn="section-6-2.1.1">
			<dt pn="section-6-2.1.1.1">PCE Identity theft:</dt>
			<dd pn="section-6-2.1.1.2">A legitimate PCC could request a path for
			a GMPLS LSP to
	a malicious PCE, which poses as a legitimate PCE.		a malicious PCE, which poses as a legitimate PCE.
	The answer can make that the LSP traverses some		The response may be that the LSP traverses some geographical place
	geographical place known to the		known to the attacker where confidentiality (sniffing), integrity
	attacker where confidentiality (sniffing), integrity		(traffic modification), or availability (traffic drop) attacks
	(traffic modification) or availability (traffic drop)		could be performed by use of an attacker-controlled middlebox
	attacks could be performed by use of an		device.
	attacker-controlled middlebox
	device. Also, the resulting LSP can omit constraints given in the		Also, the resulting LSP can omit constraints given in the
	requests (e.g., excluding certain fibers, avoiding some SRLGs) which		requests (e.g., excluding certain fibers and avoiding some SRLGs), wh
	could make		ich could make
	that the LSP which will be later set-up can look perfectly fine, but		the LSP that will be set up later look perfectly fine, but it will be
	will be in a risky		in a risky
	situation. Also, the result can lead to the creation of an LSP that d oes not provide the		situation. Also, the result can lead to the creation of an LSP that d oes not provide the
	desired quality and gives less resources than necessary.		desired quality and gives less resources than necessary.</dd>
	</t>		<dt pn="section-6-2.1.1.3">
	<t>		PCC Identity theft:</dt>
	PCC Identity theft: A malicious PCC, acting as a legitimate PCC, requ		<dd pn="section-6-2.1.1.4">A malicious PCC, acting as a legitimate P
	esting LSP		CC, requesting LSP
	paths to a legitimate PCE can obtain a good knowledge of the physical topology of		paths to a legitimate PCE can obtain a good knowledge of the physical topology of
	a critical infrastructure. It could get to know enough details to pla n a later physical		a critical infrastructure. It could learn enough details to plan a la ter physical
	attack.		attack.
	</t>		</dd>
	<t>		<dt pn="section-6-2.1.1.5">
	Message inspection: As in the previous case, knowledge of an infrastr		Message inspection:</dt>
	ucture can		<dd pn="section-6-2.1.1.6">As in the previous case, knowledge of an
			infrastructure can
	be obtained by sniffing PCEP messages.		be obtained by sniffing PCEP messages.
	</t>		</dd>
	</list>		</dl>
			</li>
			</ul>
			<t pn="section-6-3">
	The security mechanisms can provide authentication and		The security mechanisms can provide authentication and
	confidentiality for those scenarios where the PCC-PCE communication		confidentiality for those scenarios where PCC-PCE communication
	cannot be completely trusted. <xref target="RFC8253" /> provides origin		cannot be completely trusted. <xref target="RFC8253" format="default" s
	verification, message integrity and replay protection, and ensures		ectionFormat="of" derivedContent="RFC8253"/> provides origin
			verification, message integrity, and replay protection, and it ensures
	that a third party cannot decipher the contents of a		that a third party cannot decipher the contents of a
	message.		message.
	</t>		</t>
	<t>		<t pn="section-6-4">
	In order to protect against the malicious PCE case the PCC		In order to protect against the malicious PCE case, the PCC
	SHOULD have policies in place to accept or not the path provided by		<bcp14>SHOULD</bcp14> have policies in place to accept or not accept the
			path provided by
	the PCE. Those policies can verify if the path follows the provided		the PCE. Those policies can verify if the path follows the provided
	constraints. In addition, technology specific data plane mechanism		constraints. In addition, a technology-specific data-plane mechanism
	can be used (following <xref target="RFC5920" /> Section 5.8) to verify		can be used (following <xref target="RFC5920" sectionFormat="comma" sect
	the data		ion="5.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5920#secti
	plane connectivity and deviation from constraints.		on-5.8" derivedContent="RFC5920"/>) to verify the data-plane connectivity and de
			viation from constraints.
	</t>		</t>
	<t>		<t pn="section-6-5">
	The document <xref target="RFC8253" /> describes the usage of Transport L		The usage of Transport Layer
	ayer		Security (TLS) to enhance PCEP security is described in <xref target="RFC
	Security (TLS) to enhance PCEP security. The document describes the initi		8253" format="default" sectionFormat="of" derivedContent="RFC8253"/>. The docume
	ation		nt describes the initiation
	of the TLS procedures, the TLS handshake mechanisms, the TLS methods for		of TLS procedures, the TLS handshake mechanisms, the TLS methods for peer
	peer
	authentication, the applicable TLS ciphersuites for data exchange, and th e handling		authentication, the applicable TLS ciphersuites for data exchange, and th e handling
	of errors in the security checks. PCE and PCC SHOULD use <xref		of errors in the security checks. PCE and PCC <bcp14>SHOULD</bcp14> use t
	target="RFC8253" /> mechanism to protect against malicious		he mechanism in <xref target="RFC8253" format="default" sectionFormat="of" deriv
			edContent="RFC8253"/> to protect against malicious
	PCC and PCE.		PCC and PCE.
	</t>		</t>
	<t>		<t pn="section-6-6">
	Finally, as mentioned by <xref target="RFC7025" /> the PCEP extensions to		Finally, as mentioned by <xref target="RFC7025" format="default" sectionF
	support GMPLS should		ormat="of" derivedContent="RFC7025"/>, the PCEP extensions that support GMPLS sh
	be considered under the same security as current PCE work and this extens		ould
	ion		be considered under the same security as current PCE work, and this exten
			sion
	will not change the underlying security issues. However, given the critic al		will not change the underlying security issues. However, given the critic al
	nature of the network infrastructures under control by GMPLS, the securit y issues		nature of the network infrastructures under control by GMPLS, the securit y issues
	described above should be seriously considered when deploying a GMPLS-PCE		described above should be seriously considered when deploying a GMPLS-PCE
	based control plane for such networks. For more information on the securi		-based
	ty considerations		control plane for such networks. For an overview of the security consider
	on a GMPLS control plane, not only related to PCE/PCEP, <xref target="RFC5920		ations, not only related to PCE/PCEP, and vulnerabilities of a GMPLS control pla
	" /> provides an overview of security vulnerabilities of a GMPLS control plane.		ne, see <xref target="RFC5920" format="default" sectionFormat="of" derivedConten
			t="RFC5920"/>.
	</t>		</t>
	</section>		</section>
	<section title="Contributing Authors">		</middle>
	<t>Elie Sfeir<vspace blankLines='0'/>		<back>
	Coriant<vspace blankLines='0'/>		<references pn="section-7">
	St Martin Strasse 76<vspace blankLines='0'/>		<name slugifiedName="name-references">References</name>
	Munich, 81541<vspace blankLines='0'/>		<references pn="section-7.1">
	Germany<vspace blankLines='1'/>		<name slugifiedName="name-normative-references">Normative References</na
	Email: elie.sfeir@coriant.com<vspace blankLines='0'/>		me>
	</t>		<reference anchor="G.709-v3" target="https://www.itu.int/rec/T-REC-G.709
			-201606-I/en" quoteTitle="true" derivedAnchor="G.709-v3">
			<front>
			<title>Interfaces for the optical transport network</title>
			<author>
			<organization showOnFrontPage="true">ITU-T</organization>
			</author>
			<date year="2016" month="June"/>
			</front>
			<refcontent>Recommendation G.709/Y.1331</refcontent>
			</reference>
			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
			119" quoteTitle="true" derivedAnchor="RFC2119">
			<front>
			<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1997" month="March"/>
			<abstract>
			<t>In many standards track documents several words are used to sig
			nify the requirements in the specification. These words are often capitalized.
			This document defines these words as they should be interpreted in IETF document
			s. This document specifies an Internet Best Current Practices for the Internet
			Community, and requests discussion and suggestions for improvements.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
			</reference>
			<reference anchor="RFC2210" target="https://www.rfc-editor.org/info/rfc2
			210" quoteTitle="true" derivedAnchor="RFC2210">
			<front>
			<title>The Use of RSVP with IETF Integrated Services</title>
			<author initials="J." surname="Wroclawski" fullname="J. Wroclawski">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1997" month="September"/>
			<abstract>
			<t>This note describes the use of the RSVP resource reservation pr
			otocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-
			TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2210"/>
			<seriesInfo name="DOI" value="10.17487/RFC2210"/>
			</reference>
			<reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3
			209" quoteTitle="true" derivedAnchor="RFC3209">
			<front>
			<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
			<author initials="D." surname="Awduche" fullname="D. Awduche">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="L." surname="Berger" fullname="L. Berger">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Gan" fullname="D. Gan">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Li" fullname="T. Li">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Swallow" fullname="G. Swallow">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2001" month="December"/>
			<abstract>
			<t>This document describes the use of RSVP (Resource Reservation P
			rotocol), including all the necessary extensions, to establish label-switched pa
			ths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LS
			P is completely identified by the label applied at the ingress node of the path,
			these paths may be treated as tunnels. A key application of LSP tunnels is tra
			ffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3209"/>
			<seriesInfo name="DOI" value="10.17487/RFC3209"/>
			</reference>
			<reference anchor="RFC3471" target="https://www.rfc-editor.org/info/rfc3
			471" quoteTitle="true" derivedAnchor="RFC3471">
			<front>
			<title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling
			Functional Description</title>
			<author initials="L." surname="Berger" fullname="L. Berger" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2003" month="January"/>
			<abstract>
			<t>This document describes extensions to Multi-Protocol Label Swit
			ching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS e
			xtends the MPLS control plane to encompass time-division (e.g., Synchronous Opti
			cal Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical l
			ambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or
			fiber). This document presents a functional description of the extensions. Pro
			tocol specific formats and mechanisms, and technology specific details are speci
			fied in separate documents. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3471"/>
			<seriesInfo name="DOI" value="10.17487/RFC3471"/>
			</reference>
			<reference anchor="RFC3473" target="https://www.rfc-editor.org/info/rfc3
			473" quoteTitle="true" derivedAnchor="RFC3473">
			<front>
			<title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling
			Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
			<author initials="L." surname="Berger" fullname="L. Berger" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2003" month="January"/>
			<abstract>
			<t>This document describes extensions to Multi-Protocol Label Swit
			ching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signa
			ling required to support Generalized MPLS. Generalized MPLS extends the MPLS co
			ntrol plane to encompass time-division (e.g., Synchronous Optical Network and Sy
			nchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatia
			l switching (e.g., incoming port or fiber to outgoing port or fiber). This docu
			ment presents a RSVP-TE specific description of the extensions. A generic funct
			ional description can be found in separate documents. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3473"/>
			<seriesInfo name="DOI" value="10.17487/RFC3473"/>
			</reference>
			<reference anchor="RFC3477" target="https://www.rfc-editor.org/info/rfc3
			477" quoteTitle="true" derivedAnchor="RFC3477">
			<front>
			<title>Signalling Unnumbered Links in Resource ReSerVation Protocol
			- Traffic Engineering (RSVP-TE)</title>
			<author initials="K." surname="Kompella" fullname="K. Kompella">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2003" month="January"/>
			<abstract>
			<t>Current signalling used by Multi-Protocol Label Switching Traff
			ic Engineering (MPLS TE) does not provide support for unnumbered links. This doc
			ument defines procedures and extensions to Resource ReSerVation Protocol (RSVP)
			for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling p
			rotocols, that are needed in order to support unnumbered links. [STANDARDS-TRAC
			K]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3477"/>
			<seriesInfo name="DOI" value="10.17487/RFC3477"/>
			</reference>
			<reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3
			630" quoteTitle="true" derivedAnchor="RFC3630">
			<front>
			<title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
			<author initials="D." surname="Katz" fullname="D. Katz">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Kompella" fullname="K. Kompella">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Yeung" fullname="D. Yeung">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2003" month="September"/>
			<abstract>
			<t>This document describes extensions to the OSPF protocol version
			2 to support intra-area Traffic Engineering (TE), using Opaque Link State Adver
			tisements.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3630"/>
			<seriesInfo name="DOI" value="10.17487/RFC3630"/>
			</reference>
			<reference anchor="RFC4003" target="https://www.rfc-editor.org/info/rfc4
			003" quoteTitle="true" derivedAnchor="RFC4003">
			<front>
			<title>GMPLS Signaling Procedure for Egress Control</title>
			<author initials="L." surname="Berger" fullname="L. Berger">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2005" month="February"/>
			<abstract>
			<t>This document clarifies the procedures for the control of the l
			abel used on an output/downstream interface of the egress node of a Label Switch
			ed Path (LSP). This control is also known as "Egress Control". Support for Egr
			ess Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Si
			gnaling. This document clarifies the specification of GMPLS Signaling and does
			not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4003"/>
			<seriesInfo name="DOI" value="10.17487/RFC4003"/>
			</reference>
			<reference anchor="RFC4328" target="https://www.rfc-editor.org/info/rfc4
			328" quoteTitle="true" derivedAnchor="RFC4328">
			<front>
			<title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling
			Extensions for G.709 Optical Transport Networks Control</title>
			<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
			riou" role="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="January"/>
			<abstract>
			<t>This document is a companion to the Generalized Multi-Protocol
			Label Switching (GMPLS) signaling documents. It describes the technology-specif
			ic information needed to extend GMPLS signaling to control Optical Transport Net
			works (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TR
			ACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4328"/>
			<seriesInfo name="DOI" value="10.17487/RFC4328"/>
			</reference>
			<reference anchor="RFC4606" target="https://www.rfc-editor.org/info/rfc4
			606" quoteTitle="true" derivedAnchor="RFC4606">
			<front>
			<title>Generalized Multi-Protocol Label Switching (GMPLS) Extensions
			for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH)
			Control</title>
			<author initials="E." surname="Mannie" fullname="E. Mannie">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
			riou">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="August"/>
			<abstract>
			<t>This document provides minor clarification to RFC 3946.</t>
			<t>This document is a companion to the Generalized Multi-protocol
			Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (
			SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information neede
			d when GMPLS signaling is used. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4606"/>
			<seriesInfo name="DOI" value="10.17487/RFC4606"/>
			</reference>
			<reference anchor="RFC4802" target="https://www.rfc-editor.org/info/rfc4
			802" quoteTitle="true" derivedAnchor="RFC4802">
			<front>
			<title>Generalized Multiprotocol Label Switching (GMPLS) Traffic Eng
			ineering Management Information Base</title>
			<author initials="T." surname="Nadeau" fullname="T. Nadeau" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Farrel" fullname="A. Farrel" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="February"/>
			<abstract>
			<t>This memo defines a portion of the Management Information Base
			(MIB) for use with network management protocols in the Internet community. In pa
			rticular, it describes managed objects for Generalized Multiprotocol Label Switc
			hing (GMPLS)-based traffic engineering. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4802"/>
			<seriesInfo name="DOI" value="10.17487/RFC4802"/>
			</reference>
			<reference anchor="RFC4872" target="https://www.rfc-editor.org/info/rfc4
			872" quoteTitle="true" derivedAnchor="RFC4872">
			<front>
			<title>RSVP-TE Extensions in Support of End-to-End Generalized Multi
			-Protocol Label Switching (GMPLS) Recovery</title>
			<author initials="J.P." surname="Lang" fullname="J.P. Lang" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
			riou" role="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="May"/>
			<abstract>
			<t>This document describes protocol-specific procedures and extens
			ions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation
			Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label
			Switched Path (LSP) recovery that denotes protection and restoration. A generic
			functional description of GMPLS recovery can be found in a companion document,
			RFC 4426. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4872"/>
			<seriesInfo name="DOI" value="10.17487/RFC4872"/>
			</reference>
			<reference anchor="RFC4873" target="https://www.rfc-editor.org/info/rfc4
			873" quoteTitle="true" derivedAnchor="RFC4873">
			<front>
			<title>GMPLS Segment Recovery</title>
			<author initials="L." surname="Berger" fullname="L. Berger">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="I." surname="Bryskin" fullname="I. Bryskin">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
			riou">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="May"/>
			<abstract>
			<t>This document describes protocol specific procedures for GMPLS
			(Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Proto
			col - Traffic Engineering) signaling extensions to support label switched path (
			LSP) segment protection and restoration. These extensions are intended to comple
			ment and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery
			(RFC 4872). Implications and interactions with fast reroute are also addressed.
			This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-
			TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4873"/>
			<seriesInfo name="DOI" value="10.17487/RFC4873"/>
			</reference>
			<reference anchor="RFC5088" target="https://www.rfc-editor.org/info/rfc5
			088" quoteTitle="true" derivedAnchor="RFC5088">
			<front>
			<title>OSPF Protocol Extensions for Path Computation Element (PCE) D
			iscovery</title>
			<author initials="JL." surname="Le Roux" fullname="JL. Le Roux" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Y." surname="Ikejiri" fullname="Y. Ikejiri">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Zhang" fullname="R. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2008" month="January"/>
			<abstract>
			<t>There are various circumstances where it is highly desirable fo
			r a Path Computation Client (PCC) to be able to dynamically and automatically di
			scover a set of Path Computation Elements (PCEs), along with information that ca
			n be used by the PCC for PCE selection. When the PCE is a Label Switching Router
			(LSR) participating in the Interior Gateway Protocol (IGP), or even a server pa
			rticipating passively in the IGP, a simple and efficient way to announce PCEs co
			nsists of using IGP flooding. For that purpose, this document defines extension
			s to the Open Shortest Path First (OSPF) routing protocol for the advertisement
			of PCE Discovery information within an OSPF area or within the entire OSPF routi
			ng domain. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5088"/>
			<seriesInfo name="DOI" value="10.17487/RFC5088"/>
			</reference>
			<reference anchor="RFC5089" target="https://www.rfc-editor.org/info/rfc5
			089" quoteTitle="true" derivedAnchor="RFC5089">
			<front>
			<title>IS-IS Protocol Extensions for Path Computation Element (PCE)
			Discovery</title>
			<author initials="JL." surname="Le Roux" fullname="JL. Le Roux" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Y." surname="Ikejiri" fullname="Y. Ikejiri">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Zhang" fullname="R. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2008" month="January"/>
			<abstract>
			<t>There are various circumstances where it is highly desirable fo
			r a Path Computation Client (PCC) to be able to dynamically and automatically di
			scover a set of Path Computation Elements (PCEs), along with information that ca
			n be used by the PCC for PCE selection. When the PCE is a Label Switching Router
			(LSR) participating in the Interior Gateway Protocol (IGP), or even a server pa
			rticipating passively in the IGP, a simple and efficient way to announce PCEs co
			nsists of using IGP flooding. For that purpose, this document defines extension
			s to the Intermediate System to Intermediate System (IS-IS) routing protocol for
			the advertisement of PCE Discovery information within an IS-IS area or within t
			he entire IS-IS routing domain. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5089"/>
			<seriesInfo name="DOI" value="10.17487/RFC5089"/>
			</reference>
			<reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5
			440" quoteTitle="true" derivedAnchor="RFC5440">
			<front>
			<title>Path Computation Element (PCE) Communication Protocol (PCEP)<
			/title>
			<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="JL." surname="Le Roux" fullname="JL. Le Roux" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2009" month="March"/>
			<abstract>
			<t>This document specifies the Path Computation Element (PCE) Comm
			unication Protocol (PCEP) for communications between a Path Computation Client (
			PCC) and a PCE, or between two PCEs. Such interactions include path computation
			requests and path computation replies as well as notifications of specific stat
			es related to the use of a PCE in the context of Multiprotocol Label Switching (
			MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be
			flexible and extensible so as to easily allow for the addition of further messag
			es and objects, should further requirements be expressed in the future. [STANDA
			RDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5440"/>
			<seriesInfo name="DOI" value="10.17487/RFC5440"/>
			</reference>
			<reference anchor="RFC5511" target="https://www.rfc-editor.org/info/rfc5
			511" quoteTitle="true" derivedAnchor="RFC5511">
			<front>
			<title>Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encodi
			ng Rules in Various Routing Protocol Specifications</title>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2009" month="April"/>
			<abstract>
			<t>Several protocols have been specified in the Routing Area of th
			e IETF using a common variant of the Backus-Naur Form (BNF) of representing mess
			age syntax. However, there is no formal definition of this version of BNF.</t>
			<t>There is value in using the same variant of BNF for the set of
			protocols that are commonly used together. This reduces confusion and simplifie
			s implementation.</t>
			<t>Updating existing documents to use some other variant of BNF th
			at is already formally documented would be a substantial piece of work.</t>
			<t>This document provides a formal definition of the variant of BN
			F that has been used (that we call Routing BNF) and makes it available for use b
			y new protocols. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5511"/>
			<seriesInfo name="DOI" value="10.17487/RFC5511"/>
			</reference>
			<reference anchor="RFC5520" target="https://www.rfc-editor.org/info/rfc5
			520" quoteTitle="true" derivedAnchor="RFC5520">
			<front>
			<title>Preserving Topology Confidentiality in Inter-Domain Path Comp
			utation Using a Path-Key-Based Mechanism</title>
			<author initials="R." surname="Bradford" fullname="R. Bradford" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2009" month="April"/>
			<abstract>
			<t>Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPL
			S) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path
			Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as
			Autonomous Systems (ASes), the path may be computed by multiple PCEs that coope
			rate, with each responsible for computing a segment of the path. However, in so
			me cases (e.g., when ASes are administered by separate Service Providers), it wo
			uld break confidentiality rules for a PCE to supply a path segment to a PCE in a
			nother domain, thus disclosing AS-internal topology information. This issue may
			be circumvented by returning a loose hop and by invoking a new path computation
			from the domain boundary Label Switching Router (LSR) during TE LSP setup as th
			e signaling message enters the second domain, but this technique has several iss
			ues including the problem of maintaining path diversity.</t>
			<t>This document defines a mechanism to hide the contents of a seg
			ment of a path, called the Confidential Path Segment (CPS). The CPS may be repl
			aced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP)
			and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit ro
			ute object. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5520"/>
			<seriesInfo name="DOI" value="10.17487/RFC5520"/>
			</reference>
			<reference anchor="RFC5521" target="https://www.rfc-editor.org/info/rfc5
			521" quoteTitle="true" derivedAnchor="RFC5521">
			<front>
			<title>Extensions to the Path Computation Element Communication Prot
			ocol (PCEP) for Route Exclusions</title>
			<author initials="E." surname="Oki" fullname="E. Oki">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Takeda" fullname="T. Takeda">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2009" month="April"/>
			<abstract>
			<t>The Path Computation Element (PCE) provides functions of path c
			omputation in support of traffic engineering (TE) in Multi-Protocol Label Switch
			ing (MPLS) and Generalized MPLS (GMPLS) networks.</t>
			<t>When a Path Computation Client (PCC) requests a PCE for a route
			, it may be useful for the PCC to specify, as constraints to the path computatio
			n, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be
			explicitly excluded from the computed route. Such constraints are termed "route
			exclusions".</t>
			<t>The PCE Communication Protocol (PCEP) is designed as a communic
			ation protocol between PCCs and PCEs. This document presents PCEP extensions fo
			r route exclusions. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5521"/>
			<seriesInfo name="DOI" value="10.17487/RFC5521"/>
			</reference>
			<reference anchor="RFC5541" target="https://www.rfc-editor.org/info/rfc5
			541" quoteTitle="true" derivedAnchor="RFC5541">
			<front>
			<title>Encoding of Objective Functions in the Path Computation Eleme
			nt Communication Protocol (PCEP)</title>
			<author initials="JL." surname="Le Roux" fullname="JL. Le Roux">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Y." surname="Lee" fullname="Y. Lee">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2009" month="June"/>
			<abstract>
			<t>The computation of one or a set of Traffic Engineering Label Sw
			itched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized M
			PLS (GMPLS) networks is subject to a set of one or more specific optimization cr
			iteria, referred to as objective functions (e.g., minimum cost path, widest path
			, etc.).</t>
			<t>In the Path Computation Element (PCE) architecture, a Path Comp
			utation Client (PCC) may want a path to be computed for one or more TE LSPs acco
			rding to a specific objective function. Thus, the PCC needs to instruct the PCE
			to use the correct objective function. Furthermore, it is possible that not all
			PCEs support the same set of objective functions; therefore, it is useful for t
			he PCC to be able to automatically discover the set of objective functions suppo
			rted by each PCE.</t>
			<t>This document defines extensions to the PCE communication Proto
			col (PCEP) to allow a PCE to indicate the set of objective functions it supports
			. Extensions are also defined so that a PCC can indicate in a path computation
			request the required objective function, and a PCE can report in a path computat
			ion reply the objective function that was used for path computation.</t>
			<t>This document defines objective function code types for six obj
			ective functions previously listed in the PCE requirements work, and provides th
			e definition of four new metric types that apply to a set of synchronized reques
			ts. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5541"/>
			<seriesInfo name="DOI" value="10.17487/RFC5541"/>
			</reference>
			<reference anchor="RFC6001" target="https://www.rfc-editor.org/info/rfc6
			001" quoteTitle="true" derivedAnchor="RFC6001">
			<front>
			<title>Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer
			and Multi-Region Networks (MLN/MRN)</title>
			<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
			riou">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Vigoureux" fullname="M. Vigoureux">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Shiomoto" fullname="K. Shiomoto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Brungard" fullname="D. Brungard">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="JL." surname="Le Roux" fullname="JL. Le Roux">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2010" month="October"/>
			<abstract>
			<t>There are specific requirements for the support of networks com
			prising Label Switching Routers (LSRs) participating in different data plane swi
			tching layers controlled by a single Generalized Multi-Protocol Label Switching
			(GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Mult
			i-Region Networks (MLN/MRN).</t>
			<t>This document defines extensions to GMPLS routing and signaling
			protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Ne
			tworks. It covers the elements of a single GMPLS control plane instance control
			ling multiple Label Switched Path (LSP) regions or layers within a single Traffi
			c Engineering (TE) domain. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6001"/>
			<seriesInfo name="DOI" value="10.17487/RFC6001"/>
			</reference>
			<reference anchor="RFC6003" target="https://www.rfc-editor.org/info/rfc6
			003" quoteTitle="true" derivedAnchor="RFC6003">
			<front>
			<title>Ethernet Traffic Parameters</title>
			<author initials="D." surname="Papadimitriou" fullname="D. Papadimit
			riou">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2010" month="October"/>
			<abstract>
			<t>This document describes the support of Metro Ethernet Forum (ME
			F) Ethernet traffic parameters as described in MEF10.1 when using Generalized Mu
			lti-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Eng
			ineering (RSVP-TE) signaling. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6003"/>
			<seriesInfo name="DOI" value="10.17487/RFC6003"/>
			</reference>
			<reference anchor="RFC6205" target="https://www.rfc-editor.org/info/rfc6
			205" quoteTitle="true" derivedAnchor="RFC6205">
			<front>
			<title>Generalized Labels for Lambda-Switch-Capable (LSC) Label Swit
			ching Routers</title>
			<author initials="T." surname="Otani" fullname="T. Otani" role="edit
			or">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Li" fullname="D. Li" role="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2011" month="March"/>
			<abstract>
			<t>Technology in the optical domain is constantly evolving, and, a
			s a consequence, new equipment providing lambda switching capability has been de
			veloped and is currently being deployed.</t>
			<t>Generalized MPLS (GMPLS) is a family of protocols that can be u
			sed to operate networks built from a range of technologies including wavelength
			(or lambda) switching. For this purpose, GMPLS defined a wavelength label as on
			ly having significance between two neighbors. Global wavelength semantics are n
			ot considered.</t>
			<t>In order to facilitate interoperability in a network composed o
			f next generation lambda-switch-capable equipment, this document defines a stand
			ard lambda label format that is compliant with the Dense Wavelength Division Mul
			tiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids define
			d by the International Telecommunication Union Telecommunication Standardization
			Sector. The label format defined in this document can be used in GMPLS signalin
			g and routing protocols. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6205"/>
			<seriesInfo name="DOI" value="10.17487/RFC6205"/>
			</reference>
			<reference anchor="RFC6387" target="https://www.rfc-editor.org/info/rfc6
			387" quoteTitle="true" derivedAnchor="RFC6387">
			<front>
			<title>GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths
			(LSPs)</title>
			<author initials="A." surname="Takacs" fullname="A. Takacs">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="L." surname="Berger" fullname="L. Berger">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Caviglia" fullname="D. Caviglia">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Fedyk" fullname="D. Fedyk">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Meuric" fullname="J. Meuric">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2011" month="September"/>
			<abstract>
			<t>This document defines a method for the support of GMPLS asymmet
			ric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented
			is applicable to any switching technology and builds on the original Resource R
			eservation Protocol (RSVP) model for the transport of traffic-related parameters
			. This document moves the experiment documented in RFC 5467 to the standards tr
			ack and obsoletes RFC 5467. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6387"/>
			<seriesInfo name="DOI" value="10.17487/RFC6387"/>
			</reference>
			<reference anchor="RFC7139" target="https://www.rfc-editor.org/info/rfc7
			139" quoteTitle="true" derivedAnchor="RFC7139">
			<front>
			<title>GMPLS Signaling Extensions for Control of Evolving G.709 Opti
			cal Transport Networks</title>
			<author initials="F." surname="Zhang" fullname="F. Zhang" role="edit
			or">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Zhang" fullname="G. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Belotti" fullname="S. Belotti">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Pithewan" fullname="K. Pithewan">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2014" month="March"/>
			<abstract>
			<t>ITU-T Recommendation G.709 [G709-2012] introduced new Optical c
			hannel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced
			Optical Transport Network (OTN) flexibility.</t>
			<t>This document updates the ODU-related portions of RFC 4328 to p
			rovide extensions to GMPLS signaling to control the full set of OTN features, in
			cluding ODU0, ODU4, ODU2e, and ODUflex.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7139"/>
			<seriesInfo name="DOI" value="10.17487/RFC7139"/>
			</reference>
			<reference anchor="RFC7570" target="https://www.rfc-editor.org/info/rfc7
			570" quoteTitle="true" derivedAnchor="RFC7570">
			<front>
			<title>Label Switched Path (LSP) Attribute in the Explicit Route Obj
			ect (ERO)</title>
			<author initials="C." surname="Margaria" fullname="C. Margaria" role
			="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Martinelli" fullname="G. Martinelli">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Balls" fullname="S. Balls">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="B." surname="Wright" fullname="B. Wright">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2015" month="July"/>
			<abstract>
			<t>RFC 5420 extends RSVP-TE to specify or record generic attribute
			s that apply to the whole of the path of a Label Switched Path (LSP). This docu
			ment defines an extension to the RSVP Explicit Route Object (ERO) and Record Rou
			te Object (RRO) to allow them to specify or record generic attributes that apply
			to a given hop.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7570"/>
			<seriesInfo name="DOI" value="10.17487/RFC7570"/>
			</reference>
			<reference anchor="RFC7792" target="https://www.rfc-editor.org/info/rfc7
			792" quoteTitle="true" derivedAnchor="RFC7792">
			<front>
			<title>RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense W
			avelength Division Multiplexing (DWDM) Networks</title>
			<author initials="F." surname="Zhang" fullname="F. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="X." surname="Zhang" fullname="X. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzal
			ez de Dios">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2016" month="March"/>
			<abstract>
			<t>This memo describes the extensions to the Resource Reservation
			Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Swi
			tched Paths (LSPs) in a GMPLS-controlled network that includes devices using the
			flexible optical grid.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7792"/>
			<seriesInfo name="DOI" value="10.17487/RFC7792"/>
			</reference>
			<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
			126" quoteTitle="true" derivedAnchor="RFC8126">
			<front>
			<title>Guidelines for Writing an IANA Considerations Section in RFCs
			</title>
			<author initials="M." surname="Cotton" fullname="M. Cotton">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Narten" fullname="T. Narten">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="June"/>
			<abstract>
			<t>Many protocols make use of points of extensibility that use con
			stants to identify various protocol parameters. To ensure that the values in th
			ese fields do not have conflicting uses and to promote interoperability, their a
			llocations are often coordinated by a central record keeper. For IETF protocols
			, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
			<t>To make assignments in a given registry prudently, guidance des
			cribing the conditions under which new values should be assigned, as well as whe
			n and how modifications to existing values can be made, is needed. This documen
			t defines a framework for the documentation of these guidelines by specification
			authors, in order to assure that the provided guidance for the IANA Considerati
			ons is clear and addresses the various issues that are likely in the operation o
			f a registry.</t>
			<t>This is the third edition of this document; it obsoletes RFC 52
			26.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="26"/>
			<seriesInfo name="RFC" value="8126"/>
			<seriesInfo name="DOI" value="10.17487/RFC8126"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
			tle>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="May"/>
			<abstract>
			<t>RFC 2119 specifies common key words that may be used in protoco
			l specifications. This document aims to reduce the ambiguity by clarifying tha
			t only UPPERCASE usage of the key words have the defined special meanings.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
			</reference>
			<reference anchor="RFC8253" target="https://www.rfc-editor.org/info/rfc8
			253" quoteTitle="true" derivedAnchor="RFC8253">
			<front>
			<title>PCEPS: Usage of TLS to Provide a Secure Transport for the Pat
			h Computation Element Communication Protocol (PCEP)</title>
			<author initials="D." surname="Lopez" fullname="D. Lopez">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzal
			ez de Dios">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Q." surname="Wu" fullname="Q. Wu">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Dhody" fullname="D. Dhody">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="October"/>
			<abstract>
			<t>The Path Computation Element Communication Protocol (PCEP) defi
			nes the mechanisms for the communication between a Path Computation Client (PCC)
			and a Path Computation Element (PCE), or among PCEs. This document describes PC
			EPS -- the usage of Transport Layer Security (TLS) to provide a secure transport
			for PCEP. The additional security mechanisms are provided by the transport pro
			tocol supporting PCEP; therefore, they do not affect the flexibility and extensi
			bility of PCEP.</t>
			<t>This document updates RFC 5440 in regards to the PCEP initializ
			ation phase procedures.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8253"/>
			<seriesInfo name="DOI" value="10.17487/RFC8253"/>
			</reference>
			<reference anchor="RFC8282" target="https://www.rfc-editor.org/info/rfc8
			282" quoteTitle="true" derivedAnchor="RFC8282">
			<front>
			<title>Extensions to the Path Computation Element Communication Prot
			ocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering</title>
			<author initials="E." surname="Oki" fullname="E. Oki">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Takeda" fullname="T. Takeda">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="F." surname="Zhang" fullname="F. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="December"/>
			<abstract>
			<t>The Path Computation Element (PCE) provides path computation fu
			nctions in support of traffic engineering in Multiprotocol Label Switching (MPLS
			) and Generalized MPLS (GMPLS) networks.</t>
			<t>MPLS and GMPLS networks may be constructed from layered service
			networks. It is advantageous for overall network efficiency to provide end-to-
			end traffic engineering across multiple network layers through a process called
			inter-layer traffic engineering. PCE is a candidate solution for such requireme
			nts.</t>
			<t>The PCE Communication Protocol (PCEP) is designed as a communic
			ation protocol between Path Computation Clients (PCCs) and PCEs. This document
			presents PCEP extensions for inter-layer traffic engineering.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8282"/>
			<seriesInfo name="DOI" value="10.17487/RFC8282"/>
			</reference>
			<reference anchor="RFC8306" target="https://www.rfc-editor.org/info/rfc8
			306" quoteTitle="true" derivedAnchor="RFC8306">
			<front>
			<title>Extensions to the Path Computation Element Communication Prot
			ocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths</ti
			tle>
			<author initials="Q." surname="Zhao" fullname="Q. Zhao">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Dhody" fullname="D. Dhody" role="edit
			or">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Palleti" fullname="R. Palleti">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="King" fullname="D. King">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="November"/>
			<abstract>
			<t>Point-to-point Multiprotocol Label Switching (MPLS) and General
			ized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be esta
			blished using signaling techniques, but their paths may first need to be determi
			ned. The Path Computation Element (PCE) has been identified as an appropriate t
			echnology for the determination of the paths of point-to-multipoint (P2MP) TE LS
			Ps.</t>
			<t>This document describes extensions to the PCE Communication Pro
			tocol (PCEP) to handle requests and responses for the computation of paths for P
			2MP TE LSPs.</t>
			<t>This document obsoletes RFC 6006.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8306"/>
			<seriesInfo name="DOI" value="10.17487/RFC8306"/>
			</reference>
			</references>
			<references pn="section-7.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4
			655" quoteTitle="true" derivedAnchor="RFC4655">
			<front>
			<title>A Path Computation Element (PCE)-Based Architecture</title>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Ash" fullname="J. Ash">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="August"/>
			<abstract>
			<t>Constraint-based path computation is a fundamental building blo
			ck for traffic engineering systems such as Multiprotocol Label Switching (MPLS)
			and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computatio
			n in large, multi-domain, multi-region, or multi-layer networks is complex and m
			ay require special computational components and cooperation between the differen
			t network domains.</t>
			<t>This document specifies the architecture for a Path Computation
			Element (PCE)-based model to address this problem space. This document does no
			t attempt to provide a detailed description of all the architectural components,
			but rather it describes a set of building blocks for the PCE architecture from
			which solutions may be constructed. This memo provides information for the Inte
			rnet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4655"/>
			<seriesInfo name="DOI" value="10.17487/RFC4655"/>
			</reference>
			<reference anchor="RFC4657" target="https://www.rfc-editor.org/info/rfc4
			657" quoteTitle="true" derivedAnchor="RFC4657">
			<front>
			<title>Path Computation Element (PCE) Communication Protocol Generic
			Requirements</title>
			<author initials="J." surname="Ash" fullname="J. Ash" role="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J.L." surname="Le Roux" fullname="J.L. Le Roux" ro
			le="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="September"/>
			<abstract>
			<t>The PCE model is described in the "PCE Architecture" document a
			nd facilitates path computation requests from Path Computation Clients (PCCs) to
			Path Computation Elements (PCEs). This document specifies generic requirements
			for a communication protocol between PCCs and PCEs, and also between PCEs where
			cooperation between PCEs is desirable. Subsequent documents will specify appli
			cation-specific requirements for the PCE communication protocol. This memo prov
			ides information for the Internet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4657"/>
			<seriesInfo name="DOI" value="10.17487/RFC4657"/>
			</reference>
			<reference anchor="RFC5920" target="https://www.rfc-editor.org/info/rfc5
			920" quoteTitle="true" derivedAnchor="RFC5920">
			<front>
			<title>Security Framework for MPLS and GMPLS Networks</title>
			<author initials="L." surname="Fang" fullname="L. Fang" role="editor
			">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2010" month="July"/>
			<abstract>
			<t>This document provides a security framework for Multiprotocol L
			abel Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Netw
			orks. This document addresses the security aspects that are relevant in the con
			text of MPLS and GMPLS. It describes the security threats, the related defensiv
			e techniques, and the mechanisms for detection and reporting. This document emp
			hasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-p
			rovider security considerations for building and maintaining MPLS and GMPLS netw
			orks across different domains or different Service Providers. This document is
			not an Internet Standards Track specification; it is published for informationa
			l purposes.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5920"/>
			<seriesInfo name="DOI" value="10.17487/RFC5920"/>
			</reference>
			<reference anchor="RFC6123" target="https://www.rfc-editor.org/info/rfc6
			123" quoteTitle="true" derivedAnchor="RFC6123">
			<front>
			<title>Inclusion of Manageability Sections in Path Computation Eleme
			nt (PCE) Working Group Drafts</title>
			<author initials="A." surname="Farrel" fullname="A. Farrel">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2011" month="February"/>
			<abstract>
			<t>It has often been the case that manageability considerations ha
			ve been retrofitted to protocols after they have been specified, standardized, i
			mplemented, or deployed. This is sub-optimal. Similarly, new protocols or proto
			col extensions are frequently designed without due consideration of manageabilit
			y requirements.</t>
			<t>The Operations Area has developed "Guidelines for Considering O
			perations and Management of New Protocols and Protocol Extensions" (RFC 5706), a
			nd those guidelines have been adopted by the Path Computation Element (PCE) Work
			ing Group.</t>
			<t>Previously, the PCE Working Group used the recommendations cont
			ained in this document to guide authors of Internet-Drafts on the contents of "M
			anageability Considerations" sections in their work. This document is retained
			for historic reference. This document defines a Historic Document for the Inte
			rnet community.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6123"/>
			<seriesInfo name="DOI" value="10.17487/RFC6123"/>
			</reference>
			<reference anchor="RFC6163" target="https://www.rfc-editor.org/info/rfc6
			163" quoteTitle="true" derivedAnchor="RFC6163">
			<front>
			<title>Framework for GMPLS and Path Computation Element (PCE) Contro
			l of Wavelength Switched Optical Networks (WSONs)</title>
			<author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Bernstein" fullname="G. Bernstein" ro
			le="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="W." surname="Imajuku" fullname="W. Imajuku">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2011" month="April"/>
			<abstract>
			<t>This document provides a framework for applying Generalized Mul
			ti-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) archi
			tecture to the control of Wavelength Switched Optical Networks (WSONs). In part
			icular, it examines Routing and Wavelength Assignment (RWA) of optical paths.</t
			>
			<t>This document focuses on topological elements and path selectio
			n constraints that are common across different WSON environments; as such, it do
			es not address optical impairments in any depth. This document is not an Interne
			t Standards Track specification; it is published for informational purposes.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6163"/>
			<seriesInfo name="DOI" value="10.17487/RFC6163"/>
			</reference>
			<reference anchor="RFC7025" target="https://www.rfc-editor.org/info/rfc7
			025" quoteTitle="true" derivedAnchor="RFC7025">
			<front>
			<title>Requirements for GMPLS Applications of PCE</title>
			<author initials="T." surname="Otani" fullname="T. Otani">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Ogaki" fullname="K. Ogaki">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Caviglia" fullname="D. Caviglia">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="F." surname="Zhang" fullname="F. Zhang">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Margaria" fullname="C. Margaria">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2013" month="September"/>
			<abstract>
			<t>The initial effort of the PCE (Path Computation Element) WG foc
			used mainly on MPLS. As a next step, this document describes functional require
			ments for GMPLS applications of PCE.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7025"/>
			<seriesInfo name="DOI" value="10.17487/RFC7025"/>
			</reference>
			<reference anchor="RFC7449" target="https://www.rfc-editor.org/info/rfc7
			449" quoteTitle="true" derivedAnchor="RFC7449">
			<front>
			<title>Path Computation Element Communication Protocol (PCEP) Requir
			ements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Ass
			ignment</title>
			<author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Bernstein" fullname="G. Bernstein" ro
			le="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Martensson" fullname="J. Martensson">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Takeda" fullname="T. Takeda">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Tsuritani" fullname="T. Tsuritani">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzal
			ez de Dios">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2015" month="February"/>
			<abstract>
			<t>This memo provides application-specific requirements for the Pa
			th Computation Element Communication Protocol (PCEP) for the support of Waveleng
			th Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires
			a Routing and Wavelength Assignment (RWA) process. From a path computation persp
			ective, wavelength assignment is the process of determining which wavelength can
			be used on each hop of a path and forms an additional routing constraint to opt
			ical light path computation. Requirements for PCEP extensions in support of opt
			ical impairments will be addressed in a separate document.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7449"/>
			<seriesInfo name="DOI" value="10.17487/RFC7449"/>
			</reference>
			</references>
			</references>
			<section anchor="appendix" numbered="true" toc="include" removeInRFC="false"
			pn="section-appendix.a">
			<name slugifiedName="name-load-balancing-usage-for-sd">LOAD-BALANCING Usag
			e for SDH Virtual Concatenation</name>
			<t pn="section-appendix.a-1">As an example, a request for one co-signaled
			n x VC-4 TE-LSP
			will not use LOAD-BALANCING.
			In case the VC-4 components can
			use different paths, the BANDWIDTH with object type 3 will
			contain the complete n x VC-4 traffic specification,
			and the LOAD-BALANCING object will contain the minimum
			co-signaled VC-4.
			For an SDH network, a request for a TE-LSP group with 10 VC-4
			containers, with each path using at minimum 2 x VC-4 containers, can
			be represented with a BANDWIDTH object with object type 3, the Bw Spec Type
			set to 4, and the content of the Generalized Bandwidth field with ST=6,
			RCC=0, NCC=0, NVC=10, and MT=1.
	<t>		The LOAD-BALANCING with object type 2 with the Bw Spec Type set
	Franz Rambach<vspace blankLines='0'/>		to 4 and Max-LSP=5, Min Bandwidth Spec is ST=6, RCC=0, NCC=0, NVC=2, MT=1.
	Nockherstrasse 2-4,<vspace blankLines='0'/>
	Munich 81541<vspace blankLines='0'/>
	Germany<vspace blankLines='1'/>
	Phone: +49 178 8855738<vspace blankLines='0'/>
	Email: franz.rambach@cgi.com<vspace blankLines='0'/>
	</t>
	<t>
	Francisco Javier Jimenez Chico<vspace blankLines='0'/>
	Telefonica Investigacion y Desarrollo<vspace blankLines='0'/>
	C/ Emilio Vargas 6<vspace blankLines='0'/>
	Madrid, 28043<vspace blankLines='0'/>
	Spain<vspace blankLines='1'/>
	Phone: +34 91 3379037<vspace blankLines='0'/>
	Email: fjjc@tid.es<vspace blankLines='0'/>
	</t>
	<t>
	Huawei Technologies
	<list>
	<t>Suresh BR<vspace blankLines='0'/>
	Shenzhen<vspace blankLines='0'/>
	China<vspace blankLines='0'/>
	Email: sureshbr@huawei.com<vspace blankLines='0'/>
	</t>
	<t>
	Young Lee<vspace blankLines='0'/>
	1700 Alma Drive, Suite 100<vspace blankLines='0'/>
	Plano, TX 75075<vspace blankLines='0'/>
	USA<vspace blankLines='1'/>
	Phone: (972) 509-5599 (x2240)<vspace blankLines='0'/>
	Email: ylee@huawei.com<vspace blankLines='0'/>
	</t>
	<t>
	SenthilKumar S<vspace blankLines='0'/>
	Shenzhen<vspace blankLines='0'/>
	China<vspace blankLines='0'/>
	Email: senthilkumars@huawei.com<vspace blankLines='0'/>
	</t>
	<t>
	Jun Sun<vspace blankLines='0'/>
	Shenzhen<vspace blankLines='0'/>
	China<vspace blankLines='0'/>
	Email: johnsun@huawei.com <vspace blankLines='0'/>
	</t>
	</list>
	</t>
	<t>
	CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
	<list>
	<t>Ramon Casellas<vspace blankLines='0'/>
	PMT Ed B4 Av. Carl Friedrich Gauss 7<vspace blankLines='0'/>
	08860 Castelldefels (Barcelona)<vspace blankLines='0'/>
	Spain<vspace blankLines='0'/>
	Phone: (34) 936452916 <vspace blankLines='0'/>
	Email: ramon.casellas@cttc.es<vspace blankLines='0'/>
	</t>
	</list>
	</t>
	</section>
	<section title="Acknowledgments">		The PCE can respond with a maximum of 5 paths, with each path having a
	<t>		BANDWIDTH object type 3 and a Generalized Bandwidth field matching the Min
	The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar Go		Bandwidth
	nzalez de Dios, Cyril Margaria, and Franz Rambach leading		Spec from the LOAD-BALANCING object of the corresponding request.</t>
	to these results		</section>
	has received funding from the European Community's Seventh Framework Pro		<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	gram FP7/2007-2013		ndix.b">
	under grant agreement no 247674 and no 317999.		<name slugifiedName="name-acknowledgments">Acknowledgments</name>
			<t pn="section-appendix.b-1">
			The research of <contact fullname="Ramon Casellas"/>, <contact fullname=
			"Francisco Javier Jimenez Chico"/>, <contact fullname="Oscar Gonzalez de
			Dios"/>, <contact fullname="Cyril Margaria"/>, and
			<contact fullname="Franz Rambach"/> that led to the results in this
			document received funding from the European Community's Seventh
			Framework Program FP7/2007-2013 under grant agreement no. 247674 and
			no. 317999.
	</t>		</t>
	<t>		<t pn="section-appendix.b-2">
	The authors would like to thank Julien Meuric, Lyndon Ong,		The authors would like to thank <contact fullname="Julien Meuric"/>,
	Giada Lander, Jonathan Hardwick, Diego Lopez, David Sinicrope,		<contact fullname="Lyndon Ong"/>, <contact fullname="Giada Lander"/>,
	Vincent Roca, Dhruv Dhody, Adrian Farrel and Tianran Zhou for their rev		<contact fullname="Jonathan Hardwick"/>, <contact fullname="Diego
	iew and useful comments to the document.		Lopez"/>, <contact fullname="David Sinicrope"/>, <contact fullname="Vincent Ro
			ca"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Adrian Farrel"/>, a
			nd <contact fullname="Tianran Zhou"/> for
			their review and useful comments.
	</t>		</t>
	<t> Thanks to Alisa Cooper, Benjamin Kaduk, Elwun-davies,		<t pn="section-appendix.b-3"> Thanks to <contact fullname="Alisa Cooper"/>
	Martin Vigoureux, Roman Danyliw, and Suresh Krishnan for the IESG		, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Elwyn Davies"/>,
	comments</t>		<contact fullname="Martin Vigoureux"/>, <contact fullname="Roman Dan
			yliw"/>, and <contact fullname="Suresh Krishnan"/> for the
			IESG-related comments.</t>
	</section>		</section>
			<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
	</middle>		ndix.c">
			<name slugifiedName="name-contributors">Contributors</name>
	<!-- *****BACK MATTER ***** -->		<contact fullname="Elie Sfeir">
			<organization showOnFrontPage="true">Coriant</organization>
	<back>		<address>
			<postal>
	<references title="Normative References">		<street>St. Martin Strasse 76</street>
	<reference anchor="G.709-v3" target="https://www.itu.int/rec/T-REC-G.709-20		<city>Munich</city>
	1606-I/en">		<region/>
	<front>		<code>81541</code>
	<title>		<country>Germany</country>
	Interfaces for the optical transport network, Recommendation G.709/Y.		</postal>
	1331		<email>elie.sfeir@coriant.com</email>
	</title>		</address>
	<author> <organization>ITU-T</organization></author>		</contact>
	<date year="2016" month="June"/>		<contact fullname="Franz Rambach">
	</front>		<organization showOnFrontPage="true"/>
	</reference>		<address>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119		<postal>
	.xml"?>		<street>Nockherstrasse 2-4</street>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2210		<city>Munich</city>
	.xml"?>		<region/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209		<code>81541</code>
	.xml"?>		<country>Germany</country>
			</postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.347		<phone>+49 178 8855738</phone>
	1.xml"?>		<email>franz.rambach@cgi.com</email>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.347		</address>
	3.xml"?>		</contact>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.347		<contact fullname="Francisco Javier Jimenez Chico">
	7.xml"?>		<organization showOnFrontPage="true">Telefonica Investigacion y Desarrol
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.363		lo</organization>
	0.xml"?>		<address>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.400		<postal>
	3.xml"?>		<street>C/ Emilio Vargas 6</street>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.432		<city>Madrid</city>
	8.xml"?>		<region/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.460		<code>28043</code>
	6.xml"?>		<country>Spain</country>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.480		</postal>
	2.xml"?>		<phone>+34 91 3379037</phone>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.487		<email>fjjc@tid.es</email>
	2.xml"?>		</address>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.487		</contact>
	3.xml"?>		<contact fullname="Suresh Babu">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.508		<organization showOnFrontPage="true"/>
	8.xml"?>		<address>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.508		<postal>
	9.xml"?>		<street/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.544		<city/>
	0.xml"?>		<region/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.551		<code/>
	1.xml"?>		<country/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.552		</postal>
	0.xml"?>		<email>sureshhimnish@gmail.com</email>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.552		</address>
	1.xml"?>		</contact>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.554		<contact fullname="Young Lee">
	1.xml"?>		<organization showOnFrontPage="true">Samsung Electronics</organization>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.600		<address>
	1.xml"?>		<postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.600		<street/>
	3.xml"?>		<city/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.620		<region/>
	5.xml"?>		<code/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.638		<country/>
	7.xml"?>		</postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.757		<phone/>
	0.xml"?>		<email>younglee.tx@gmail.com</email>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.713		</address>
	9.xml"?>		</contact>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.779		<contact fullname="Senthil Kumar S">
	2.xml"?>		<organization showOnFrontPage="true"/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.812		<address>
	6.xml"?>		<postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817		<street/>
	4.xml"?>		<city/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.825		<region/>
	3.xml"?>		<code/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.828		<country/>
	2.xml"?>		</postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.830		<email>ssenthilkumar@gmail.com</email>
	6.xml"?>		</address>
			</contact>
	</references>		<contact fullname="Jun Sun">
	<references title="Informative References">		<organization showOnFrontPage="true">Huawei Technologies</organization>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.465		<address>
	5.xml"?>		<postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.465		<street/>
	7.xml"?>		<city>Shenzhen</city>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.592		<region/>
	0.xml"?>		<code/>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.612		<country>China</country>
	3.xml"?>		</postal>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.616		<email>johnsun@huawei.com</email>
	3.xml"?>		</address>
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.702		</contact>
	5.xml"?>		<contact fullname="Ramon Casellas">
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.744		<organization showOnFrontPage="true">CTTC - Centre Tecnologic de Telecom
	9.xml"?>		unicacions de Catalunya</organization>
	</references>		<address>
	<section anchor="appendix" title="LOAD-BALANCING Usage for SDH Virtual Conca		<postal>
	tenation">		<street>PMT Ed B4 Av. Carl Friedrich Gauss 7</street>
	<t>For example a request for one co-signaled n x VC-4 TE-LSP		<city>Castelldefels,</city>
	will not use the LOAD-BALANCING. In case the VC-4 components can		<region>Barcelona</region>
	use different paths, the BANDWIDTH with object type TBA-2 will		<code>08660</code>
	contain a traffic specification indicating the complete n x VC-4		<country>Spain</country>
	traffic specification and the LOAD-BALANCING the minimum		</postal>
	co-signaled VC-4. For an SDH network, a request to have a TE-LSP		<phone>+34 93 6452916</phone>
	group with 10 VC-4 containers, each path using at minimum 2 x		<email>ramon.casellas@cttc.e</email>
	VC-4 containers, can be represented with a BANDWIDTH object		</address>
	with OT=TBA-2, Bw Spec Type set to 4, the content of the		</contact>
	Generalized Bandwidth is ST=6, RCC=0, NCC=0, NVC=10, MT=1. The		</section>
	LOAD-BALANCING, OT=TBA-4 with Bw Spec Type set to 4,		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
	Max-LSP=5, Min Bandwidth Spec is (ST=6, RCC=0, NCC=0, NVC=2, MT=1). The PC		="include" pn="section-appendix.d">
	E can respond with a response with maximum 5 paths, each of them having a BANDWI		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
	DTH OT=TBA-2 and Generalized Bandwidth matching the Min Bandwidth Spec from the		<author fullname="Cyril Margaria" initials="C." role="editor" surname="Mar
	LOAD-BALANCING object of the corresponding request.</t>		garia">
			<organization showOnFrontPage="true">Juniper</organization>
			<address>
			<email>cmargaria@juniper.net</email>
			</address>
			</author>
			<author fullname="Oscar Gonzalez de Dios" initials="O." role="editor" surn
			ame="Gonzalez de Dios">
			<organization showOnFrontPage="true">Telefonica Investigacion y Desarrol
			lo</organization>
			<address>
			<postal>
			<street>C/ Ronda de la Comunicacion</street>
			<city>Madrid</city>
			<region/>
			<code>28050</code>
			<country>Spain</country>
			</postal>
			<phone>+34 91 4833441</phone>
			<email>oscar.gonzalezdedios@telefonica.com</email>
			</address>
			</author>
			<author fullname="Fatai Zhang" role="editor" initials="F." surname="Zhang"
			>
			<organization showOnFrontPage="true">Huawei Technologies</organization>
			<address>
			<postal>
			<street>F3-5-B R&amp;D Center, Huawei Base</street>
			<cityarea>Bantian, Longgang District</cityarea>
			<city>Shenzhen</city>
			<region/>
			<code>518129</code>
			<country>China</country>
			</postal>
			<email>zhangfatai@huawei.com</email>
			</address>
			</author>
	</section>		</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 178 change blocks.
	1790 lines changed or deleted		4177 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/