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 strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
An alternate method (rfc include) is described in the references. --> category="std" consensus="true"
]> docName="draft-ietf-pce-gmpls-pcep-extensions-16" number="8779"
<rfc category="std" docName="draft-ietf-pce-gmpls-pcep-extensions-16" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
ipr="trust200902" > tocDepth="3" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="PCEP Ext for GMPLS">PCEP extensions for GMPLS</title> <title abbrev="PCEP Extensions for GMPLS">Path Computation Element Communica
<author fullname="Cyril Margaria" initials="C.M." role="editor" surname="Mar tion Protocol (PCEP) Extensions for GMPLS</title>
garia"> <seriesInfo name="RFC" value="8779"/>
<author fullname="Cyril Margaria" initials="C." role="editor" surname="Marga
ria">
<organization>Juniper</organization> <organization>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>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>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>
<!-- Meta-data Declarations --> <date month="July" year="2020"/>
<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> <abstract>
<t>A Path Computation Element (PCE) provides path computation functions <t>A Path Computation Element (PCE) provides path 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>
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>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>Although <xref target="RFC4655" /> defines the PCE architecture and fra <name>Introduction</name>
mework for both MPLS and GMPLS networks, most preexisting PCEP RFCs <xref target <t>Although the PCE architecture and framework for both MPLS and GMPLS net
="RFC5440" />, <xref target="RFC5521" />, <xref target="RFC5541" />, <xref targe works are defined in <xref target="RFC4655" format="default"/>, most pre-existin
t="RFC5520" /> are focused on MPLS networks, and do not cover the wide range of g PCEP RFCs, such as <xref target="RFC5440" format="default"/>, <xref target="RF
GMPLS networks. This document complements these RFCs by addressing the extension C5521" format="default"/>, <xref target="RFC5541" format="default"/>, and <xref
s required for GMPLS applications and routing requests, for example for Optical target="RFC5520" format="default"/>, are focused on MPLS networks and do not cov
Transport Network (OTN) and Wavelength Switched Optical Network (WSON) networks. er the wide range of GMPLS networks. This document complements these RFCs by add
</t> ressing the extensions required for GMPLS applications and routing requests, for
example, for Optical Transport Networks (OTNs) and Wavelength Switched Optical
Networks (WSONs).</t>
<t>The functional requirements to be addressed by the PCEP <t>The functional requirements to be addressed by the PCEP
extensions to support these applications are fully described in <xref extensions to support these applications are fully described in <xref targ
target="RFC7025" /> and <xref target='RFC7449' />. et="RFC7025" format="default"/> and <xref target="RFC7449" format="default"/>.
</t> </t>
<section numbered="true" toc="default">
<section title ="Terminology"> <name>Terminology</name>
<t>
<t> This document uses terminologies from the PCE architecture docume
This document uses terminologies from the PCE architecture docume nt <xref target="RFC4655" format="default"/>; the PCEP documents including <xref
nt <xref target="RFC4655"/>, the PCEP documents including <xref target="RFC5440" target="RFC5440" format="default"/>, <xref target="RFC5521" format="default"/>,
/>, <xref target="RFC5521"/>, <xref target="RFC5541"/>, <xref target="RFC5520"/> <xref target="RFC5541" format="default"/>, <xref target="RFC5520" format="defau
, <xref target="RFC7025"/> and <xref target="RFC7449"/>, lt"/>, <xref target="RFC7025" format="default"/>, and <xref target="RFC7449" for
and the GMPLS documents such as <xref mat="default"/>;
target="RFC3471"/>, <xref target="RFC3473"/> and so and the GMPLS documents such as <xref target="RFC3471" format="de
on. Note that it is expected the reader is familiar fault"/>, <xref target="RFC3473" format="default"/>, 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">
<t hangText="ODU"> ODU Optical Channel Data Unit <xref target= <dt>ERO:</dt>
"G.709-v3" /></t> <dd>Explicit Route Object</dd>
<t hangText="OTN"> Optical Transport Network <xref target="G.7 <dt>IRO:</dt>
09-v3" /></t> <dd>Include Route Object</dd>
<t hangText="L2SC"> Layer-2 Switch Capable <xref target="RFC34 <dt>L2SC:</dt>
71" /></t> <dd>Layer 2 Switch Capable <xref target="RFC3471" format="default"/></
<t hangText="TDM"> Time-Division Multiplex Capable <xref targe dd>
t="RFC3471" /></t> <dt>LSC:</dt>
<t hangText="LSC"> Lambda Switch Capable <xref target="RFC3471 <dd>Lambda Switch Capable <xref target="RFC3471" format="default"/></d
" /></t> d>
<t hangText="SONET"> Synchronous Optical Networking </t> <dt>LSP:</dt>
<t hangText="SDH"> Synchronous Digital Hierarchy </t> <dd>Label Switched Path</dd>
<t hangText="PCC"> Path Computation Client</t> <dt>LSPA:</dt>
<t hangText="RSVP-TE"> Resource Reservation Protocol - Traffi <dd>LSP Attribute</dd>
c Engineering</t> <dt>MEF:</dt>
<t hangText="LSP"> Label Switched Path</t> <dd>Metro Ethernet Forum</dd>
<t hangText="TE-LSP">Traffic Engineering LSP</t> <dt>MT:</dt>
<t hangText="IRO">Include Route Object</t> <dd>Multiplier <xref target="RFC4328" format="default"/> <xref target=
<t hangText="ERO">Explicit Route Object</t> "RFC4606" format="default"/></dd>
<t hangText="XRO"> eXclude Route Object</t> <dt>NCC:</dt>
<t hangText="RRO"> Record Route Object</t> <dd>Number of Contiguous Components <xref target="RFC4606" format="def
<t hangText="LSPA"> LSP Attribute</t> ault"/></dd>
<t hangText="SRLG">Shared Risk Link Group</t> <dt>NVC:</dt>
<t hangText="NVC">Number of Virtual Components <xref target="R <dd>Number of Virtual Components <xref target="RFC4328" format="defaul
FC4328" /><xref target="RFC4606" /></t> t"/> <xref target="RFC4606" format="default"/></dd>
<t hangText="NCC">Number of Contiguous Components <xref target <dt>ODU:</dt>
="RFC4328" /><xref target="RFC4606" /></t> <dd>Optical Data Unit <xref target="G.709-v3" format="default"/></dd>
<t hangText="MT">Multiplier <xref target="RFC4328" /><xref tar <dt>OTN:</dt>
get="RFC4606" /></t> <dd>Optical Transport Network <xref target="G.709-v3" format="default"
<t hangText="RCC">Requested Contiguous Concatenation <xref tar /></dd>
get="RFC4606" /></t> <dt>P2MP:</dt>
<t hangText="PCReq">Path Computation Request <xref target="RFC <dd>Point-to-Multipoint</dd>
5440" /></t> <dt>PCC:</dt>
<t hangText="PCRep">Path Computation Reply <xref target="RFC5 <dd>Path Computation Client</dd>
440" /></t> <dt>PCRep:</dt>
<t hangText="MEF">Metro Ethernet Forum</t> <dd>Path Computation Reply <xref target="RFC5440" format="default"/><
<t hangText="SSON">Spectrum-Switched Optical Network</t> /dd>
<t hangText="P2MP">Point to Multi-Point</t> <dt>PCReq:</dt>
<dd>Path Computation Request <xref target="RFC5440" format="default"/>
</list> </dd>
</t> <dt>RCC:</dt>
<dd>Requested Contiguous Concatenation <xref target="RFC4606" format="
default"/></dd>
<dt>RRO:</dt>
<dd>Record Route Object</dd>
<dt>RSVP-TE:</dt>
<dd>Resource Reservation Protocol - Traffic Engineering</dd>
<dt>SDH:</dt>
<dd>Synchronous Digital Hierarchy </dd>
<dt>SONET:</dt>
<dd>Synchronous Optical Network</dd>
<dt>SRLG:</dt>
<dd>Shared Risk Link Group</dd>
<dt>SSON:</dt>
<dd>Spectrum-Switched Optical Network</dd>
<dt>TDM:</dt>
<dd>Time-Division Multiplex Capable <xref target="RFC3471" format="def
ault"/></dd>
<dt>TE-LSP:</dt>
<dd>Traffic Engineered LSP</dd>
<dt>XRO:</dt>
<dd>Exclude Route Object</dd>
<t> </dl>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO <t>
T", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMEND
as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/ ED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
> when, "<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"/> <xref
target="RFC8174" format="default"/> 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="default">
<section title="PCEP Requirements for GMPLS"> <name>PCEP Requirements for GMPLS</name>
<t>The document <xref target="RFC7025" /> describes the set of <t><xref target="RFC7025" format="default"/> describes the set of PCEP
PCEP requirements to support GMPLS TE-LSPs. This document requirements that support GMPLS TE-LSPs. This document assumes a
assumes a significant familiarity with <xref target="RFC7025" significant familiarity with <xref target="RFC7025" format="default"/>
/> and existing PCEP extensions. As a short and existing PCEP extensions. As a short overview, those requirements
overview, those requirements can be broken down into the following categ can be broken down into the following categories.
ories.
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>Which data flow is switched by the LSP: a combination
<t>Which data flow is switched by the LSP: a combination of a switching type (for instance,
of Switching type (for instance L2SC or TDM), an LSP encoding
L2SC or TDM ), 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 a TDM or an LSC switching capability).</li>
Type (e.g., in case of TDM/LSC switching capability).</t> <li>Data-flow-specific traffic parameters, which are
<t>Data flow specific traffic parameters, which are technology specific. For instance, in SDH/SONET and OTN networks <xr
technology specific. For instance, in SDH/SONET and <xref ef target="G.709-v3" format="default"/>, the concatenation type and the concaten
target="G.709-v3" /> OTN networks the Concatenation Type and the Co ation number have an influence on the switched data and on which link it can be
ncatenation Number have an influence on the switched data and on which link it c supported.</li>
an be supported</t> <li>Support for asymmetric bandwidth requests.</li>
<t>Support for asymmetric bandwidth requests.</t> <li>Support for unnumbered interface identifiers, as
<t>Support for unnumbered interface identifiers, as defined in <xref target="RFC3477" format="default"/>.</li>
defined in <xref target="RFC3477"></xref></t> <li>Label information and technology-specific label(s) such
<t>Label information and technology specific label(s) such as wavelength labels as defined in <xref target="RFC6205" format="de
as wavelength labels as defined in <xref target="RFC6205" fault"/>. A PCC should also be able to
/>. 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"/>.</li>
<t>Ability to indicate the requested granularity for the <li>Ability to indicate the requested granularity for the
path ERO: node, link or label. This is to allow the use of the expli path ERO: node, link, or label. This is to allow the use of the expl
cit label control feature of RSVP-TE.</t> icit label control feature of RSVP-TE.</li>
</list> </ul>
The requirements of <xref target="RFC7025" /> apply to several objects <t>
conveyed by PCEP, this is described in <xref target="requirement-map" />. The requirements of <xref target="RFC7025" format="default"/> apply to
Some of the requirements of <xref target="RFC7025" /> are several objects conveyed by PCEP; this is described in <xref target="requiremen
t-map" format="default"/>.
Some of the requirements of <xref target="RFC7025" format="default"/>
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"/>.
</t> </t>
<t> <t>
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="default">
<t> This section follows the organization of <xref target="RFC7025" /> S <name>Requirements Applicability</name>
ection 3 and indicates, for each requirement, the affected piece of information <t> This section follows the organization of <xref target="RFC7025" sect
carried by PCEP and its scope.</t> ionFormat="comma" section="3"/> and indicates, for each requirement, the affecte
<section title="Requirements on Path Computation Request"> d piece of information carried by PCEP and its scope.</t>
<t> <section numbered="true" toc="default">
<list style="hanging" hangIndent="6"><t hangText="(1)"> <name>Requirements on the Path Computation Request</name>
Switching capability/type: as described in <xref
target="RFC3471" /> this piece of information is used <ol spacing="normal" type="(%d)">
with the Encoding Type and Signal Type to fully describe <li>Switching capability/type: As described in <xref target="RFC3471" format="
default"/>, 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"/>) when considering multiple network layers.
tation requirements are addressed in in <xref target="RFC8282" /> which addressi
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)"> Inter-layer path computation requirements are addressed in <xref
Signal type: see (1). target="RFC8282" format="default"/>, which focuses on the TE-LSP itself but
</t> does not address the TE-LSP endpoints.
</li>
<t hangText="(4)"> <li>Encoding type: See (1).
Concatenation type: this parameter and the Concatenation </li>
Number (5) are specific to some TDM (SDH and ODU)
switching technology. They MUST be described together <li>Signal type: See (1).
</li>
<li>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"/>
. See <xref in MPLS networks. See concatenation
target="RFC4606" /> and <xref information in <xref target="RFC4606" format="default"/> and <xref
target="RFC4328" /> about concatenation target="RFC4328" format="default"/>.
information. </li>
</t>
<t hangText="(5)"> <li>Concatenation number: See (4).
Concatenation number: see (4). </li>
</t>
<t hangText="(6)"> <li>Technology-specific label(s): As described in <xref target="RFC3
Technology-specific label(s): as described in <xref target="RFC3471 471" format="default"/>, the GMPLS labels are specific to each switching technol
" /> the GMPLS Labels are specific to each switching technology. They can be spe ogy. They can be specified on each link and also on the TE-LSP endpoints, in WSO
cified on each link and also on the TE-LSP endpoints , in WSON networks for inst N networks, for instance, as described in <xref target="RFC6163" format="default
ance, as described in <xref target="RFC6163" />. The label restriction can apply "/>. The label restriction can apply to endpoints, and on each hop, the related
to endpoints and on each hop, the related PCEP objects are END-POINTS, IRO, XRO PCEP objects are END-POINTS, IRO, XRO, and RRO.
and RRO. </li>
</t>
<t hangText="(7)"> <li>End-to-End (E2E) path protection type: As defined in <xref targe
End-to-End (E2E) path protection type: as defined in <xref target=" t="RFC4872" format="default"/>, this is applicable to the TE-LSP. In MPLS networ
RFC4872"/>, this is applicable to the TE-LSP. In MPLS networks the related PCEP ks, the related PCEP object is LSPA (carrying local protection information).
object is LSPA (carrying local protection information). </li>
</t>
<t hangText="(8)"> <li>Administrative group: As defined in <xref target="RFC3630" format
Administrative group: as defined in <xref target="RFC3630"/>, this ="default"/>, this information is already carried in the LSPA object.
information is already carried in the LSPA object. </li>
</t>
<t hangText="(9)"> <li>Link protection type: As defined in <xref target="RFC4872" forma
Link protection type: as defined in <xref target="RFC4872"/>, this t="default"/>, this is applicable to the TE-LSP and is carried in association wi
is applicable to the TE-LSP and is carried in association with the E2E path prot th the E2E path protection type.
ection type. </li>
</t>
<t hangText="(10)"> <li>Support for unnumbered interfaces: As defined in <xref target="RF
Support for unnumbered interfaces: as defined in <xref target="RFC3 C3477" format="default"/>. Its scope and related objects are the same as labels.
477"/>. Its scope and related objects are the same as labels </li>
</t>
<t hangText="(11)"> <li>Support for asymmetric bandwidth requests: As defined in <xref t
Support for asymmetric bandwidth requests: as defined <xref target= arget="RFC6387" format="default"/>, the scope is similar to (4).
"RFC6387"/>, the scope is similar to (4) </li>
</t>
<t hangText="(12)"> <li>Support for explicit label control during the path
Support for explicit label control during the path computation. Thi computation: This affects the TE-LSP and the amount of information
s affects the TE-LSP and amount of information returned in the ERO. returned in the ERO.
</t> </li>
<t hangText="(13)"> <li> Support of label restrictions in the requests/responses:
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="default">
<t><list style="hanging" hangIndent="5"><t hangText="(1)"> <name>Requirements on the Path Computation Response</name>
Path computation with concatenation: This is related to <ol spacing="normal" type="(%d)">
Path Computation request requirement (4). In addition
there is a specific type of concatenation called virtual <li>Path computation with concatenation: This is related to
concatenation that allows different routes to be used 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)">
Label constraint: The PCE should be able to include Labels in the pat
h returned to the PCC, the related object is the ERO object.
</t>
<t hangText="(3)"> <li>Label constraint: The PCE should be able to include labels in the
Roles of the routes: as defined in <xref target="RFC4872"/>, this is path returned to the PCC; the related object is the ERO object.
applicable to the TE-LSP and is carried in association with the E2E path protec </li>
tion type.
</t> <li>Roles of the routes: As defined in <xref target="RFC4872" format=
</list> "default"/>, this is applicable to the TE-LSP and is carried in association with
</t> the E2E path protection type.
</li>
</ol>
</section> </section>
</section> <!-- End Requirements on Protocol Objects --> </section>
<section title="Existing Support for GMPLS in Base PCEP Objects and its Li
mitations" anchor="existing-support">
<t> The support provided by specifications in <xref target="RFC8282" /
> and <xref target="RFC5440" /> for the
requirements listed in <xref target="RFC7025" /> is summarized in <xre
f target="rfc7025_pcreq_reqss" /> and <xref target="rfc7025_pcrep_reqss"/>. In
some cases the support may not be complete, as noted, and additional s
upport
need to be provided in this specification.
</t> <section anchor="existing-support" numbered="true" toc="default">
<name>Existing Support and Limitations for GMPLS in Base PCEP Objects</n
ame>
<t> The support provided by specifications in <xref target="RFC8282" for
mat="default"/> and <xref target="RFC5440" format="default"/> for the
requirements listed in <xref target="RFC7025" format="default"/> is su
mmarized in Tables <xref target="rfc7025_pcreq_reqss" format="counter"/> and <xr
ef target="rfc7025_pcrep_reqss" format="counter"/>. In
some cases, the support may not be complete, as noted, and additional
support
needs to be provided as indicated in this specification.
</t>
<table anchor="rfc7025_pcreq_reqss" align="center">
<name>Requirements Support per RFC 7025, Section 3.1</name>
<thead>
<tr>
<th align="left">Req.</th>
<th align="left">Name</th>
<th align="left">Support</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"> 1 </td>
<td align="left"> Switching capability/type
</td>
<td align="left"> SWITCH-LAYER (RFC 8282) </td>
</tr>
<tr>
<td align="left"> 2 </td>
<td align="left"> Encoding type
</td>
<td align="left"> SWITCH-LAYER (RFC 8282) </td>
</tr>
<tr>
<td align="left"> 3 </td>
<td align="left"> Signal type
</td>
<td align="left"> SWITCH-LAYER (RFC 8282) </td>
</tr>
<tr>
<td align="left"> 4 </td>
<td align="left"> Concatenation type
</td>
<td align="left"> No </td>
</tr>
<tr>
<td align="left"> 5 </td>
<td align="left"> Concatenation number
</td>
<td align="left"> No </td>
</tr>
<tr>
<td align="left"> 6 </td>
<td align="left"> Technology-specific label
</td>
<td align="left"> (Partial) ERO (RFC 5440)</td>
</tr>
<tr>
<td align="left"> 7 </td>
<td align="left"> End-to-End (E2E) path protection type
</td>
<td align="left"> No </td>
</tr>
<tr>
<td align="left"> 8 </td>
<td align="left"> Administrative group
</td>
<td align="left"> LSPA (RFC 5440) </td>
</tr>
<tr>
<td align="left"> 9 </td>
<td align="left"> Link protection type
</td>
<td align="left"> No </td>
</tr>
<tr>
<td align="left"> 10 </td>
<td align="left"> Support for unnumbered interfaces
</td>
<td align="left"> (Partial) ERO (RFC 5440)</td>
</tr>
<tr>
<td align="left"> 11 </td>
<td align="left"> Support for asymmetric bandwidth requests
</td>
<td align="left"> No </td>
</tr>
<tr>
<td align="left"> 12 </td>
<td align="left"> Support for explicit label control during the pa
th computation </td>
<td align="left"> No</td>
</tr>
<tr>
<td align="left"> 13 </td>
<td align="left"> Support of label restrictions in the requests/re
sponses </td>
<td align="left"> No </td>
</tr>
</tbody>
</table>
<texttable anchor='rfc7025_pcreq_reqss' suppress-title='false' <table anchor="rfc7025_pcrep_reqss" align="center">
style='none' title='RFC7025 Section 3.1 <name>Requirements Support per RFC 7025, Section 3.2</name>
requirements support'> <thead>
<ttcol align='left'></ttcol> <tr>
<ttcol align='left'></ttcol> <th align="left">Req.</th>
<ttcol align='left'></ttcol> <th align="left">Name</th>
<c>Req. </c><c> Name <th align="left">Support</th>
</c><c> Support </c> </tr>
<c> 1 </c><c> Switching capability/type </thead>
</c><c> SWITCH-LAYER (RFC8282) </c> <tbody>
<c> 2 </c><c> Encoding type <tr>
</c><c> SWITCH-LAYER (RFC8282) </c> <td align="left">1</td>
<c> 3 </c><c> Signal type <td align="left">Path computation with concatenation </td>
</c><c> SWITCH-LAYER (RFC8282) </c> <td align="left"> No </td>
<c> 4 </c><c> Concatenation type </tr>
</c><c> No </c> <tr>
<c> 5 </c><c> Concatenation number <td align="left">2</td>
</c><c> No </c> <td align="left">Label constraint </td>
<c> 6 </c><c> Technology-specific label <td align="left"> No </td>
</c><c> (Partial) ERO (RFC5440)</c> </tr>
<c> 7 </c><c> End-to-End (E2E) path protection type <tr>
</c><c> No </c> <td align="left">3</td>
<c> 8 </c><c> Administrative group <td align="left">Roles of the routes </td>
</c><c> LSPA (RFC5440) </c> <td align="left"> No </td>
<c> 9 </c><c> Link protection type </tr>
</c><c> No </c> </tbody>
<c> 10 </c><c> Support for unnumbered interfaces </table>
</c><c> (Partial) ERO (RFC5440)</c> <t>Per <xref target="requirement-map" format="default"/>, PCEP (as
<c> 11 </c><c> Support for asymmetric bandwidth requests described in <xref target="RFC5440" format="default"/>, <xref
</c><c> No </c> target="RFC5521" format="default"/>, and <xref target="RFC8282"
<c> 12 </c><c> Support for explicit label control during the path c format="default"/>) supports the following objects, included in
omputation </c><c> No </c> requests and responses, that are related to the described
<c> 13 </c><c> Support of label restrictions in the requests/respon requirements.</t>
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 <t>From <xref target="RFC5440" format="default"/>:
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'> <ul spacing="normal" empty="true"><li>
<t>SWITCH-LAYER: addresses requirements (1, 2 and 3) for the TE-LSP and <dl newline="false" spacing="normal">
indicates which layer(s) should be considered. The object can be used to repres <dt>END-POINTS:</dt><dd>related to requirements 1, 2, 3, 6, 10, and 13
ent the RSVP-TE generalized label request. It does not address the endpoints cas . The object only supports numbered endpoints. The context specifies whether the
e of requirements (1, 2 and 3).</t> y are node identifiers or numbered interfaces.</dd>
<t>REQ-ADAP-CAP: indicates the adaptation capabilities requested, can al <dt>BANDWIDTH:</dt><dd>related to requirements 4, 5, and 11. The data
so be used for the endpoints in case of mono-layer computation</t> rate is encoded in the BANDWIDTH object (as an IEEE 32-bit float). <xref target=
</list></t> "RFC5440" format="default"/> does not include the ability to convey an encoding
proper to all GMPLS-controlled networks.</dd>
<dt>ERO:</dt><dd>related to requirements 6, 10, 12, and 13. The ERO
content is defined in RSVP in
<xref target="RFC3209" format="default"/>, <xref target="RFC3473" form
at="default"/>, <xref target="RFC3477" format="default"/>, and <xref target="RFC
7570" format="default"/> and
already supports all of the requirements. </dd>
<dt>LSPA:</dt><dd>related to requirements 7, 8, and 9. Requirement 8 (
Administrative group) is already supported.</dd>
</dl></li></ul>
<t>From <xref target="RFC5521" format="default"/>:</t>
<ul spacing="normal" empty="true">
<li>
<t>XRO:
</t>
<ul spacing="normal">
<li>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>When the F bit is set, the request indicates that the
existing path has failed, and the resources present in the RRO can b
e reused.
</li>
</ul>
</li>
</ul>
<t>From <xref target="RFC8282" format="default"/>:</t>
<ul spacing="normal" empty="true"><li>
<dl newline="false" spacing="normal">
<dt>SWITCH-LAYER:</dt><dd>addresses requirements 1, 2, and 3 for the T
E-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 endp
oints case of requirements 1, 2, and 3.</dd>
<dt>REQ-ADAP-CAP:</dt><dd>indicates the adaptation capabilities reques
ted; it can also be used for the endpoints in case of mono-layer computation.</d
d>
</dl></li></ul>
<t> <t>
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">
etails of the traffic request (requirements 4 and 5, for example NVC, multiplier <li>The BANDWIDTH and LOAD-BALANCING objects do not describe the detai
) in the context of GMPLS networks, for instance TDM or OTN networks.</t> ls of the traffic request (requirements 4 and 5, for example, NVC and multiplier
<t>The END-POINTS object does not allow specifying an unnumbered ) in the context of GMPLS networks, for instance, in TDM or OTN networks.</li>
interface, nor potential label restrictions on the interface (requirements 6, 10
and 13). Those parameters are of interest in case of switching constraints.</t>
<t>The Include/eXclude Route Objects (IRO/XRO) do not allow the
inclusion/exclusion of labels (requirements 6, 10 and 13).</t>
<t>Base attributes do not allow expressing the requested link pr
otection level and/or the end-to-end protection attributes.</t>
</list>
</t>
<t>The PCEP extensions defined later in this document to cover the gaps a <li>The END-POINTS object does not allow specifying an unnumbered inte
re: rface, nor potential label restrictions on the interface (requirements 6, 10, an
<list> d 13). Those parameters are of interest in case of switching constraints.</li>
<t>Two new object types are defined for the BANDWIDTH object (G
eneralized bandwidth, Generalized bandwidth of existing TE-LSP for which a reopt
imization is requested).</t>
<t>A new object type is defined for the
LOAD-BALANCING object (Generalized Load Balancing).</t>
<t>A new object type is defined for the END-POINTS object (Gene
ralized Endpoint).</t>
<t>A new TLV is added to the Open message for capability negoti
ation.</t>
<t>A new TLV is added to the LSPA object. </t>
<t>The Label TLV is now allowed in the IRO and XRO objects.</t
>
<t>In order to indicate the used routing granularity in the res
ponse, a new flag in the RP object is added.</t>
</list>
</t>
</section>
<li>The IROs/XROs do not allow the inclusion/exclusion of labels (requ
irements 6, 10, and 13).</li>
<li>Base attributes do not allow expressing the requested link protect
ion level and/or the end-to-end protection attributes.</li>
</ul>
<t>As defined later in this document, the PCEP extensions that cover the
gaps are:
</t>
<ul empty="false" spacing="normal">
<li>Two new object types are defined for the BANDWIDTH object
(Generalized bandwidth and Generalized bandwidth of an existing TE-LSP
for which a reoptimization is requested).</li>
<li>A new object type is defined for the
LOAD-BALANCING object (Generalized Load Balancing).</li>
<li>A new object type is defined for the END-POINTS object (Generalize
d Endpoint).</li>
<li>A new TLV is added to the Open message for capability negotiation.
</li>
<li>A new TLV is added to the LSPA object. </li>
<!-- [mc] TLV -> subobject -->
<li>The Label subobject is now allowed in the IRO and XRO objects.</li
>
<li>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 numbered="true" toc="default">
<section title="PCEP Objects and Extensions"> <name>PCEP Objects and Extensions</name>
<t> <t>
This section describes the necessary PCEP objects and extensions. The PC This section describes the necessary PCEP objects and extensions. The PC
Req and PCRep messages are defined in <xref target="RFC5440"></xref>. This docum Req and PCRep messages are defined in <xref target="RFC5440" format="default"/>.
ent does not change the existing grammars.</t> This document does not change the existing grammar.</t>
<section title="GMPLS Capability Advertisement" anchor="capability"> <section anchor="capability" numbered="true" toc="default">
<t> <name>GMPLS Capability Advertisement</name>
<section anchor="IGP-discovery" numbered="true" toc="default">
</t> <name>GMPLS Computation TLV in the Existing PCE Discovery Protocol</na
<section title="GMPLS Computation TLV in the Existing PCE Discovery Prot me>
ocol" anchor="IGP-discovery"> <t>
<t> IGP-based PCE Discovery (PCED) is defined in <xref target="RFC5088" fo
IGP-based PCE Discovery (PCED) is defined in <xref rmat="default"/> and <xref target="RFC5089" format="default"/> for the
target="RFC5088" /> and <xref target="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"/> to
ort during PCEP session establishment.</t> further qualify the level of support during PCEP session establishment.</t>
</section> </section>
<section title="OPEN Object Extension GMPLS-CAPABILITY TLV" anchor="open <section anchor="open-extensions" numbered="true" toc="default">
-extensions"> <name>OPEN Object Extension GMPLS-CAPABILITY TLV</name>
<t> <t>
In addition to the IGP advertisement, a PCEP speaker MUST be able to d In addition to the IGP advertisement, a PCEP speaker <bcp14>MUST</bcp1
iscover the other peer GMPLS capabilities during the Open message exchange. This 4> be able to discover the other peer GMPLS capabilities during the Open message
capability is also useful to avoid misconfigurations. This document defines a G exchange. This capability is also useful to avoid misconfigurations. This docum
MPLS-CAPABILITY TLV for use in the OPEN object to negotiate the GMPLS capability ent defines a GMPLS-CAPABILITY TLV for use in the OPEN object to negotiate the G
. The inclusion of this TLV in the Open message indicates that the PCEP speaker MPLS capability. The inclusion of this TLV in the Open message indicates that th
support the PCEP extensions defined in the document. 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>
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>
IANA has allocated value TBA-1 from the "PCEP TLV Type Indicators" sub As documented in <xref target="iana-tlvs" format="default"/> ("New
-registry, as documented in <xref target="iana-tlvs" /> ("New PCEP TLVs"). The d PCEP TLVs"), IANA has allocated value 45 (GMPLS-CAPABILITY) from
escription is "GMPLS-CAPABILITY". Its format is shown in the following figure. the "PCEP TLV Type Indicators" sub-registry.
</t> The format for the GMPLS-CAPABILITY TLV is shown in the following figu
<figure > re.
<artwork><![CDATA[ </t>
<artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBA-1 | Length | | Type=45 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>
<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="default">
<t> <name>RP Object Extension</name>
Explicit label control (ELC) is a procedure supported by RSVP-TE, <t>
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"/>.
granularities are inter-dependent, in the sense that link granularity i The possible granularities can be node, link, or label. The
mplies the granularities are interdependent, in the sense that link granularity im
presence of node information in the ERO; similarly, a label granularity plies the
implies that the ERO contains node, link and label information. presence of node information in the ERO; similarly, a label granularity
</t> implies that the ERO contains node, link, and label information.
<t>A new 2-bit routing granularity (RG) flag (Bits TBA-13) is defined i </t>
n <t>A new 2-bit Routing Granularity (RG) flag (bits 15-16) is defined in
the RP object. The values are defined as follows</t> the RP object. The values are defined as follows:</t>
<texttable anchor='rp_bits' suppress-title='false'
style='none' title='RG flag'>
<ttcol align='center'></ttcol>
<ttcol align='left'></ttcol>
<c>0:</c><c>reserved </c>
<c>1:</c><c>node </c>
<c>2:</c><c>link </c>
<c>3:</c><c>label </c>
</texttable>
<t>The flag in the RP object indicates the requested
route granularity. The PCE SHOULD follow this granularity and MAY re
turn a NO-PATH if the requested granularity cannot be provided. The PCE MAY retu
rn any granularity on the route based on its policy. The PCC can decide if the E
RO is acceptable based on its content.
</t>
<t> If a PCE honored the requested routing granularity for a reque
st, it MUST indicate the selected routing
granularity in the RP object included in the response. Otherwise, the
PCE MUST use the reserved RG to leave the check of the ERO to the PCC. The RG f
lag is backward-compatible with <xref target="RFC5440" />: the value sent by an
implementation (PCC or PCE) not supporting it will indicate a reserved value.
</t>
</section>
<section title="BANDWIDTH Object Extensions" anchor="generalized-bandwidt
h">
<t>
From <xref target="RFC5440"/> the object carrying the requested size f
or the TE-LSP is the BANDWIDTH object. The object types 1 and 2 defined in <xref
target="RFC5440"/> do not describe enough information to describe the TE-LSP ba
ndwidth in GMPLS networks. The BANDWIDTH object encoding has to be extended to a
llow the object to express the bandwidth as described in <xref target="RFC7025"
/>.
RSVP-TE extensions for GMPLS provide a set of encodings allowing such re
presentation in an unambiguous way, this is encoded in the RSVP-TE TSpec and Flo
wSpec objects. This document extends the BANDWIDTH object with new object types
reusing the RSVP-TE encoding. </t>
<t>The following possibilities are supported by the extended encoding:
<list style='symbols'>
<t>Asymmetric bandwidth (different bandwidth in forward and reverse d
irection), as described in <xref target="RFC6387"></xref></t>
<t>GMPLS (SDH/SONET, G.709, ATM, MEF, etc.) parameters.</t>
</list>
This corresponds to requirements 3, 4, 5 and 11 of <xref target="RFC702
5" /> Section 3.1.
</t>
<t>
This document defines two Object Types for the BANDWIDTH object:
<list style='hanging'>
<t hangText="TBA-2">Generalized bandwidth</t>
<t hangText="TBA-3">Generalized bandwidth of an existing TE-LSP for w
hich a reoptimization is requested</t>
</list>
The definitions below apply for Object Type TBA-2 and TBA-3. The body i
s as follows:
</t>
<figure> <ul empty="true" spacing="normal"><li>
<artwork><![CDATA[ <dl spacing="normal" >
<dt>0:</dt><dd>reserved</dd>
<dt>1:</dt><dd>node</dd>
<dt>2:</dt><dd>link</dd>
<dt>3:</dt><dd>label</dd>
</dl></li></ul>
<t>The RG flag in the RP object indicates the requested
route granularity. The PCE <bcp14>SHOULD</bcp14> follow this granula
rity and <bcp14>MAY</bcp14> return a NO-PATH if the requested granularity cannot
be provided. The PCE <bcp14>MAY</bcp14> return any granularity on the route bas
ed on its policy. The PCC can decide if the ERO is acceptable based on its conte
nt.
</t>
<t> If a PCE honored the requested routing granularity for a request,
it <bcp14>MUST</bcp14> indicate the selected routing
granularity in the RP object included in the response. Otherwise, the
PCE <bcp14>MUST</bcp14> use the reserved RG to leave the check of the ERO to th
e PCC. The RG flag is backward compatible with <xref target="RFC5440" format="de
fault"/>: the value sent by an implementation (PCC or PCE) not supporting it wil
l indicate a reserved value.
</t>
</section>
<section anchor="generalized-bandwidth" numbered="true" toc="default">
<name>BANDWIDTH Object Extensions</name>
<t>
Per <xref target="RFC5440" format="default"/>, the object carrying
the requested size for the TE-LSP is the BANDWIDTH object. Object
types 1 and 2 defined in <xref target="RFC5440" format="default"/>
do not provide enough information to describe the TE-LSP bandwidth
in GMPLS networks. The BANDWIDTH object encoding has to be extended
to allow the object to express the bandwidth as described in <xref
target="RFC7025" format="default"/>. RSVP-TE extensions for GMPLS
provide a set of encodings that allow such representation in an
unambiguous way; this is encoded in the RSVP-TE Traffic
Specification (TSpec) and Flow Specification (FlowSpec)
objects. This document extends the BANDWIDTH object with new object
types reusing the RSVP-TE encoding. </t>
<t>The following possibilities are supported by the extended encoding:
</t>
<ul spacing="normal">
<li>Asymmetric bandwidth (different bandwidth in forward and reverse d
irection), as described in <xref target="RFC6387" format="default"/>.</li>
<li>GMPLS (SDH/SONET, G.709, ATM, MEF, etc.) parameters.</li>
</ul>
<t>
This corresponds to requirements 3, 4, 5, and 11 in <xref target="RFC70
25" sectionFormat="of" section="3.1"/>.
</t>
<t>
This document defines two object types for the BANDWIDTH object:
</t>
<ul spacing="normal" empty="true"><li>
<dl newline="false" spacing="normal">
<dt>3:</dt>
<dd>Generalized bandwidth</dd>
<dt>4:</dt>
<dd>Generalized bandwidth of an existing TE-LSP for which a
reoptimization is requested</dd>
</dl></li></ul>
<t>
The definitions below apply for object types 3 and 4. The body is as fo
llows:
</t>
<artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>BANDWIDTH object types 3 and 4 have a variable length.
<t>The BANDWIDTH object type TBA-2 and TBA-3 have a variable length.
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
nted by the object.</t> <t>The Bw Spec Type field determines which type of bandwidth is represen
<t>The Bw Spec Type corresponds to the RSVP-TE SENDER_TSPEC (Object Cla ted by the object.</t>
ss 12) C-Types</t> <t>The Bw Spec Type corresponds to the RSVP-TE SENDER_TSPEC (Object Clas
<t> The encoding of the fields Generalized Bandwidth and s 12) C-Types.</t>
Reverse Generalized Bandwidth is the same as the Traffic Parameters carr <t> The encoding of the Generalized Bandwidth and Reverse 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> Note that the RSVP-TE traffic specification <bcp14>MAY</bcp14> also
<texttable anchor='TSpec_encoding' suppress-title='false' include TLVs that are different from the PCEP TLVs (e.g., the TLVs defi
style='none' title='Generalized Bandwidth and Reverse Genera ned in <xref
lized Bandwidth field encoding'> target="RFC6003" format="default"/>).</t>
<ttcol align='left'>Bw Spec Type</ttcol> <table anchor="TSpec_encoding" align="center">
<ttcol align='left'>Name </ttcol> <!-- [mc] Should it say Fields? -->
<ttcol align='left'>Reference</ttcol> <name>Generalized Bandwidth and Reverse Generalized Bandwidth Field En
<c>2</c><c>Intserv</c><c><xref target="RFC2210"></xref></c> coding</name>
<c>4</c><c>SONET/SDH</c><c><xref target="RFC4606"></xref></c> <thead>
<c>5</c><c>G.709</c><c><xref target="RFC4328"></xref></c> <tr>
<c>6</c><c>Ethernet</c><c><xref target="RFC6003"></xref></c> <th align="left">Bw Spec Type</th>
<c>7</c><c>OTN-TDM</c><c><xref target="RFC7139"></xref></c> <th align="left">Name </th>
<c>8</c><c>SSON</c><c><xref target="RFC7792"></xref></c> <th align="left">Reference</th>
</texttable> </tr>
<t> </thead>
When a PCC requests a bi-directional path with symmetric bandwidth, <tbody>
it SHOULD only specify the Generalized Bandwidth field, and set the Reverse B <tr>
andwidth Spec <td align="left">2</td>
<td align="left">Intserv</td>
<td align="left">
<xref target="RFC2210" format="default"/></td>
</tr>
<tr>
<td align="left">4</td>
<td align="left">SONET/SDH</td>
<td align="left">
<xref target="RFC4606" format="default"/></td>
</tr>
<tr>
<td align="left">5</td>
<td align="left">G.709</td>
<td align="left">
<xref target="RFC4328" format="default"/></td>
</tr>
<tr>
<td align="left">6</td>
<td align="left">Ethernet</td>
<td align="left">
<xref target="RFC6003" format="default"/></td>
</tr>
<tr>
<td align="left">7</td>
<td align="left">OTN-TDM</td>
<td align="left">
<xref target="RFC7139" format="default"/></td>
</tr>
<tr>
<td align="left">8</td>
<td align="left">SSON</td>
<td align="left">
<xref target="RFC7792" format="default"/></td>
</tr>
</tbody>
</table>
<t>
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. Length to 0.
When a PCC needs to request a bi-directional path with When a PCC needs to request a bidirectional path with
asymmetric bandwidth, it SHOULD specify the different bandwidth in the f asymmetric bandwidth, it <bcp14>SHOULD</bcp14> specify the different ban
orward and reverse directions with a Generalized Bandwidth and Reverse Generaliz dwidth in the forward and reverse directions with Generalized Bandwidth and Reve
ed Bandwidth fields. rse Generalized Bandwidth fields.
</t> </t>
<t>The procedure described in <xref target="RFC5440" /> for the PCRep i <t>The procedure described in <xref target="RFC5440" format="default"/>
s unchanged: a PCE MAY include the BANDWIDTH objects in the response to indicate for the PCRep is unchanged: a PCE <bcp14>MAY</bcp14> include the BANDWIDTH objec
the BANDWIDTH of the path.</t> ts in the response to indicate the BANDWIDTH of the path.</t>
<t>As specified in <xref target="RFC5440" /> in the case of the reoptimi <t>As specified in <xref target="RFC5440" format="default"/>, in the cas
zation of a TE-LSP, the bandwidth of the e of the reoptimization of a TE-LSP, the bandwidth of the
existing TE-LSP MUST also be included in addition to the requested existing TE-LSP <bcp14>MUST</bcp14> also be included in addition to the reque
bandwidth if and only if the two values differ. The Object Type TBA-3 MAY be sted
used instead of the previously specified object bandwidth if and only if the two values differ. The object type 4 <bcp14>MAY
type 2 to indicate the existing TE-LSP bandwidth originally specified with </bcp14> be used instead of the previously specified object
object type TBA-2. A PCC that requested a path with a BANDWIDTH object of type 2 to indicate the existing TE-LSP bandwidth, which was originally specif
object type 1 MUST use object type 2 to represent the existing TE-LSP ied with
BANDWIDTH. object type 3. A PCC that requested a path with a BANDWIDTH object of
</t> object type 1 <bcp14>MUST</bcp14> use object type 2 to represent the existing
<t>OPTIONAL TLVs MAY be included within the object body to specify TE-LSP
more specific bandwidth requirements. No TLVs for the Object Type TBA-2 bandwidth.
and TBA-3 are defined by this document. </t>
</t>
</section> <!-- Generalized BW-->
<section title="LOAD-BALANCING Object Extensions" anchor="generalized-loa
d-balancing">
<t>
The LOAD-BALANCING object <xref target="RFC5440" /> is used to request
a set of at most Max-LSP TE-LSP having in total the bandwidth specified in BANDW
IDTH, with each TE-LSP having at least a specified minimum bandwidth. The LOAD-B
ALANCING follows the bandwidth encoding of the BANDWIDTH object, and thus the ex
isting definition from <xref target="RFC5440" /> does not describe enough detail
s for the bandwidth specification expected by GMPLS.
</t>
<t>
Similarly to the BANDWIDTH object, a new object type is defined to all
ow a PCC to represent the bandwidth types supported by GMPLS networks.
</t>
<t> <t>Optional TLVs <bcp14>MAY</bcp14> be included within the object body t
This document defines the Generalized Load Balancing object type TBA-4 for o specify
the LOAD-BALANCING object. more specific bandwidth requirements. No TLVs for object types 3 and 4
The Generalized Load Balancing object type has a variable length. are defined by this document.
</t> </t>
<t>The format of the Generalized Load Balancing object type is as follows:</t </section>
>
<figure> <section anchor="generalized-load-balancing" numbered="true" toc="default
<artwork><![CDATA[ ">
<name>LOAD-BALANCING Object Extensions</name>
<t>
The LOAD-BALANCING object <xref target="RFC5440" format="default"/>
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.
The LOAD-BALANCING object follows the bandwidth
encoding of the BANDWIDTH object; thus, the existing definition from
<xref target="RFC5440" format="default"/> does not describe enough
details for the bandwidth specification expected by GMPLS.
</t>
<t>
Similar to the BANDWIDTH object, a new object type is defined to allow
a PCC to represent the bandwidth types supported by GMPLS networks.
</t>
<t>
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>The format of the Generalized Load Balancing object type is as follow
s:</t>
<artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>
<t>Bandwidth Spec Length (16 bits): the total length of
the Min Bandwidth Spec field. The length MUST be strictly greater than
0.</t>
<t>Reverse Bandwidth Spec Length (16 bits): the total
length of the Min Reverse Bandwidth Spec field. It MAY be equal to 0.</
t>
<t>Bw Spec Type (8 bits): the bandwidth specification type, it correspo <dl spacing="normal">
nds to the RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.</t> <dt>Bandwidth Spec Length (16 bits):</dt><dd>the total length of
<t>Max-LSP (8 bits): maximum number of TE-LSPs in the set.</t> the Min Bandwidth Spec field. The length <bcp14>MUST</bcp14> be strictl
<t>Min Bandwidth Spec (variable): specifies the minimum bandwidth specif y greater than 0.</dd>
ication of each
element of the TE-LSP set.</t>
<t>Min Reverse Bandwidth Spec (variable): specifies the minimum reverse
bandwidth specification of each
element of the TE-LSP set.</t>
<t>The encoding of the fields Min Bandwidth Spec and Min
Reverse Bandwidth Spec is the same as in RSVP-TE SENDER_TSPEC
object, it can be found in <xref target="TSpec_encoding"/>
from <xref target="generalized-bandwidth" /> from this document.</t>
<t>
When a PCC requests a bi-directional path with symmetric
bandwidth while specifying load balancing constraints it SHOULD
specify the Min Bandwidth Spec field, and set the Reverse
Bandwidth Spec Length to 0.
When a PCC needs to request a bi-directional path with <dt>Reverse Bandwidth Spec Length (16 bits):</dt><dd>the total
asymmetric bandwidth while specifying load balancing length of the Min Reverse Bandwidth Spec field. It <bcp14>MAY</bcp14> b
constraints, it MUST specify the different bandwidth in e equal to 0.</dd>
forward and reverse directions through a Min Bandwidth Spec
<dt>Bw Spec Type (8 bits):</dt><dd>the bandwidth specification type; it
corresponds to RSVP-TE SENDER_TSPEC (Object Class 12) C-Types.</dd>
<dt>Max-LSP (8 bits):</dt><dd>the maximum number of TE-LSPs in the set.<
/dd>
<dt>Min Bandwidth Spec (variable):</dt><dd>specifies the minimum bandwid
th specification of each
element of the TE-LSP set.</dd>
<dt>Min Reverse Bandwidth Spec (variable):</dt><dd>specifies the minimum
reverse bandwidth specification of each
element of the TE-LSP set.</dd></dl>
<t>The encoding of the Min Bandwidth Spec and Min
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
"/>
in <xref target="generalized-bandwidth" format="default"/> of this docum
ent.</t>
<t>
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>Optional TLVs <bcp14>MAY</bcp14> be included within the object body t
o 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>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"/>.</t>
<t> <t>
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>The BANDWIDTH and LOAD-BALANCING Bw Spec Type can be different depend
ng on the endpoint nodes architecture. When the PCE is not able to handle those ing on the architecture of the endpoint node. When the PCE is not able to handle
two Bw Spec Type, it MUST return a NO-PATH with the bit "LOAD-BALANCING could no those two Bw Spec Types, it <bcp14>MUST</bcp14> return a NO-PATH with the bit "
t be performed with the bandwidth constraits " set in the NO-PATH-VECTOR TLV.</ LOAD-BALANCING could not be performed with the bandwidth constraints" set in the
t> NO-PATH-VECTOR TLV.</t>
</section> <!-- Generalized BW--> </section>
<section title="END-POINTS Object Extensions" anchor='endpoints_extension <section anchor="endpoints_extensions" numbered="true" toc="default">
s'> <name>END-POINTS Object Extensions</name>
<t> <t>
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"/>, the source IP address
ion IP address are used to identify those. and the destination IP address are used to identify those.
A new Object Type is defined to address the following possibilities: A new object type is defined to address the following possibilities:
<list style='symbols'> </t>
<t>Different source and destination endpoint types.</t> <ul spacing="normal">
<t>Label restrictions on the endpoint.</t> <li>Different source and destination endpoint types.</li>
<t>Specification of unnumbered endpoints type as seen in GMPLS netw <li>Label restrictions on the endpoint.</li>
orks.</t> <li>Specification of unnumbered endpoints type as seen in GMPLS networ
</list> ks.</li>
The Object encoding is described in the following sections. </ul>
</t> <t>
The object encoding is described in the following sections.
<t>In path computation within a GMPLS context the endpoints can: </t>
<list style='symbols'> <t>In path computation within a GMPLS context, the endpoints can:
<t>Be unnumbered as described in <xref target="RFC3477" />.</t> </t>
<t>Have labels associated to them, specifying a set of constraints <ul spacing="normal">
on the allocation of labels.</t> <li>Be unnumbered as described in <xref target="RFC3477" format="defau
<t>Have different switching capabilities</t> lt"/>.</li>
</list> <li>Have labels associated to them, specifying a set of constraints on
the allocation of labels.</li>
<li>Have different switching capabilities.</li>
</ul>
<t>
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>
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"
rement. sectionFormat="of" section="3.1"/>.
This corresponds to requirements 6 and 10 of <xref target="RFC7025" / </t>
>. <section anchor="endpoints_generalized" numbered="true" toc="default">
</t> <name>Generalized Endpoint Object Type</name>
<section anchor="endpoints_generalized" title="Generalized Endpoint O <t>
bject Type "> 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"/>.
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">
<t>IPv6 address endpoint.</t> <li>IPV4-ADDRESS</li>
<t>Unnumbered endpoint.</t> <li>IPV6-ADDRESS</li>
<t>Label request.</t> <li>UNNUMBERED-ENDPOINT</li>
<t>Label set.</t> <li>LABEL-REQUEST</li>
</list> <li>LABEL-SET</li>
The Label set TLV is used to restrict or suggest the </ol>
label allocation in the PCE. This TLV expresses the set of <t>
restrictions which may apply to signaling. Label restriction The LABEL-SET TLV is used to restrict or suggest the label
support can be an explicit or a suggested value (Label set describing allocation in the PCE. This TLV expresses the set of restrictions
one label, with that may apply to signaling. Label restriction support can be an
the L bit respectively cleared or set), mandatory range restrictions explicit or a suggested value (LABEL-SET describing one label, with
(Label set with L bit cleared) and optional range restriction (Label the L bit cleared or set, respectively), mandatory range
set restrictions (LABEL-SET with the L bit cleared), and optional range
with L bit set). restriction (LABEL-SET with the L bit set). Endpoints label
restriction may not be part of the RRO or IRO. They can be
Endpoints label restriction may not be part of the RRO or IRO. They c included when following <xref target="RFC4003" format="default"/>
an be included when following <xref target="RFC4003" /> in signaling for egress in signaling for the egress endpoint, but ingress endpoint
endpoint, but ingress endpoint properties can be local to the PCC and not signal properties can be local to the PCC and not signaled. To support
ed. To support this case the label set allows indication which label are used in this case, the LABEL-SET allows indication of which labels are used
case of reoptimization. in case of reoptimization.
The label range restrictions are valid in GMPLS-controlled networks, e
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=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Type | | Reserved | Endpoint Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> <t>Reserved bits <bcp14>SHOULD</bcp14> be set to 0 when a message is s
</figure> ent and ignored when the message is received.</t>
<t>Reserved bits SHOULD be set to 0 when a message is sent and ignore
d when the message is received.</t>
<t>The Endpoint Type is defined as follow:</t>
<texttable anchor='endpoints_generalized_endpoint-type'
suppress-title='false' style='none'
title='Generalized Endpoint endpoint types'>
<ttcol align='left'>Value</ttcol>
<ttcol align='left'>Type</ttcol>
<ttcol align='left'>Meaning</ttcol>
<c>0</c><c>Point-to-Point</c><c></c>
<c>1</c><c>Point-to-Multipoint</c><c>New leaves to add</c>
<c>2</c><c></c><c>Old leaves to remove</c>
<c>3</c><c></c><c>Old leaves whose path can be modified/reoptimized
</c>
<c>4</c><c></c><c>Old leaves whose path has to be</c>
<c></c><c></c><c>left unchanged</c>
<c>5-244</c><c>Reserved </c><c></c>
<c>245-255</c><c>Experimental range</c><c></c>
</texttable>
<t> <t>The values for the Endpoint Type field are defined as follows:</t>
The Endpoint Type is used to cover both point-to-point and different <table anchor="endpoints_generalized_endpoint-type" align="center">
point-to-multipoint endpoints. <name>Generalized Endpoint Types</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Type</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Point-to-Point</td>
A PCE may accept only Endpoint Type 0: Endpoint Types 1-4 apply if t </tr>
he <tr>
PCE implementation supports P2MP path calculation. A PCE not <td align="left">1</td>
supporting a given Endpoint Type SHOULD respond with a PCErr with <td align="left">Point-to-Multipoint with leaf type 1</td>
Error-Type=4 (Not supported object), Error-value=TBA-15 (Unsupported
endpoint type in END-POINTS </tr>
Generalized Endpoint object type). As per <xref <tr>
target="RFC5440" />, a PCE unable to <td align="left">2</td>
<td align="left">Point-to-Multipoint with leaf type 2</td>
</tr>
<tr>
<td align="left">3</td>
<td align="left">Point-to-Multipoint with leaf type 3</td>
</tr>
<tr>
<td align="left">4</td>
<td align="left">Point-to-Multipoint with leaf type 4</td>
</tr>
<tr>
<td align="left">5-244</td>
<td align="left">Unassigned</td>
</tr>
<tr>
<td align="left">245-255</td>
<td align="left">Experimental Use</td>
</tr>
</tbody>
</table>
<t>
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"/>. 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"/>, 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"/>:
</t> </t>
<figure>
<artwork><![CDATA[ <sourcecode type="rbnf"><![CDATA[
<generalized-endpoint-tlvs>::= <generalized-endpoint-tlvs>::=
<p2p-endpoints> | <p2mp-endpoints> <p2p-endpoints> | <p2mp-endpoints>
<p2p-endpoints> ::= <p2p-endpoints> ::=
<endpoint> [<endpoint-restriction-list>] <endpoint> [<endpoint-restriction-list>]
<endpoint> [<endpoint-restriction-list>] <endpoint> [<endpoint-restriction-list>]
<p2mp-endpoints> ::= <p2mp-endpoints> ::=
<endpoint> [<endpoint-restriction-list>] <endpoint> [<endpoint-restriction-list>]
<endpoint> [<endpoint-restriction-list>] <endpoint> [<endpoint-restriction-list>]
[<endpoint> [<endpoint-restriction-list>]]... [<endpoint> [<endpoint-restriction-list>]]...
]]> ]]></sourcecode>
</artwork> <t>For endpoint type Point-to-Point, two endpoint TLVs <bcp14>MUST</bc
</figure> p14>
<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
Y <t>For endpoint type Point-to-Multipoint, several END-POINTS objects <
be present in the message and the exact meaning depending on the bcp14>MAY</bcp14>
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"/> 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>An endpoint is defined as follows:</t>
<figure> <sourcecode type=""><![CDATA[
<artwork><![CDATA[
<endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT> <endpoint>::=<IPV4-ADDRESS>|<IPV6-ADDRESS>|<UNNUMBERED-ENDPOINT>
<endpoint-restriction-list> ::= <endpoint-restriction> <endpoint-restriction-list> ::= <endpoint-restriction>
[<endpoint-restriction-list>] [<endpoint-restriction-list>]
<endpoint-restriction> ::= <endpoint-restriction> ::=
[<LABEL-REQUEST>][<label-restriction-list>] [<LABEL-REQUEST>][<label-restriction-list>]
<label-restriction-list> ::= <label-restriction> <label-restriction-list> ::= <label-restriction>
[<label-restriction-list>] [<label-restriction-list>]
<label-restriction> ::= <LABEL-SET> <label-restriction> ::= <LABEL-SET>
]]></artwork> ]]></sourcecode>
</figure> <t>The different TLVs are described in the following sections. A PCE
<bcp14>MAY</bcp14> support any or all of the IPV4-ADDRESS, IPV6-ADDRESS, and UNN
<t>The different TLVs are described in the following sections. A PCE M UMBERED-ENDPOINT TLVs.
AY support any or all of IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT TLV
s.
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>
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="default">
<name>END-POINTS TLV Extensions</name>
<section title="END-POINTS TLV Extensions" anchor="endpoints_tlvs"> <t>All endpoint TLVs have the standard PCEP TLV header as defined in <
<t>All endpoint TLVs have the standard PCEP TLV header as defined in <x xref target="RFC5440" sectionFormat="comma" section="7.1"/>. For the Generalized
ref target="RFC5440"/> Section 7.1. For the Generalized Endpoint Object Type the Endpoint object type, the TLVs <bcp14>MUST</bcp14> follow the ordering defined
TLVs MUST follow the ordering defined in <xref target="endpoints_generalized" / in <xref target="endpoints_generalized" format="default"/>. </t>
>. </t> <section anchor="endpoints_tlvs_ipv4" numbered="true" toc="default">
<section title="IPV4-ADDRESS TLV" anchor="endpoints_tlvs_ipv4"> <name>IPV4-ADDRESS TLV</name>
<t>This TLV represents a numbered endpoint using IPv4 numbering, <t>The IPV4-ADDRESS TLV (Type 39) represents a numbered endpoint
the format of the IPv4-ADDRESS TLV value (TLV-Type=TBA-6) is as using IPv4 numbering. The format of the TLV value is as follows:
follows:
</t> </t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<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>
<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"/>.
</t> </t>
</section> </section>
<section title="IPV6-ADDRESS TLV" anchor="endpoints_tlvs_ipv6"> <section anchor="endpoints_tlvs_ipv6" numbered="true" toc="default">
<t>This TLV represents a numbered endpoint using IPV6 numbering, <name>IPV6-ADDRESS TLV</name>
the format of the IPv6-ADDRESS TLV value (TLV-Type=TBA-7) is as <t>The IPv6-ADDRESS TLV (Type 40) represents a numbered endpoint
follows: using IPV6 numbering. The format of the TLV value is as follows:
</t> </t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<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>
<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"/>.
</t> </t>
</section> </section>
<section anchor="endpoints_tlvs_unnumbered-if" numbered="true" toc="de
<section title="UNNUMBERED-ENDPOINT TLV" anchor="endpoints_tlvs_unnumb fault">
ered-if"> <name>UNNUMBERED-ENDPOINT TLV</name>
<t>This TLV represents an unnumbered interface. This TLV has the sam <t>The UNNUMBERED-ENDPOINT TLV (Type 41) represents an unnumbered in
e semantic as in <xref target="RFC3477"/>. terface. This TLV has the
The TLV value is encoded as follows (TLV-Type=TBA-8) same semantic as in <xref target="RFC3477" format="default"/>.
The TLV value is encoded as follows:
</t> </t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<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>
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>
</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> <t>
On the path calculation request only the GENERALIZED-BANDWIDTH and S This TLV <bcp14>MAY</bcp14> be ignored, in which case a PCRep with N
WITCH-LAYER need to be coherent, the endpoint labels could be different (support O-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref target="endpoint
ing a different LABEL-REQUEST). Hence the label restrictions include a Generaliz s_generalized" format="default"/>.
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="de
<t>Label or label range restrictions can be specified for the TE-LSP fault">
endpoints. Those are encoded using the LABEL-SET TLV. The label value need to b <name>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
er request, however in case of multilayer it is possible to have more than one o
bject, so it is better to have a dedicated TLV for the label and label request.
These TLVs MAY be ignored, in which case a response with NO-PATH SHO
ULD be returned, as described in <xref target="endpoints_generalized" />.
TLVs are encoded as follows (following <xref target="RFC5440"></xref
>):
</t>
<t><list style='symbols'>
<t>LABEL-SET TLV, Type=TBA-10. The TLV Length is
variable, Encoding follows <xref
target="RFC3471"></xref> Section 3.5 "Label set" with
the addition of a U bit, O bit and L bit. The L bit is
used to represent a suggested set of labels, following
the semantic of SUGGESTED_LABEL defined by <xref
target="RFC3471"></xref>.
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |L|O|U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> <t>The LABEL-REQUEST TLV (Type 42) indicates the switching
</figure></t> capability and encoding type of the following label restriction
</list> list for the endpoint. The value format and encoding is the same
as described in <xref target="RFC3471" sectionFormat="of"
section="3.1"/> 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"/> for the
endpoint. It is not directly related 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
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"/>.
</t> </t>
</section>
<section anchor="endpoints_tlvs_labels" numbered="true" toc="default">
<name>LABEL-SET TLV</name>
<t>Label or label range restrictions can be specified for the
TE-LSP endpoints. Those are encoded using the LABEL-SET TLV. The
label value needs to be interpreted with a description on the
encoding and switching type. The REQ-ADAP-CAP object <xref
target="RFC8282" format="default"/> can be used in case of a
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
a dedicated TLV for the label and label request. These TLVs
<bcp14>MAY</bcp14> be ignored, in which case a response with
NO-PATH <bcp14>SHOULD</bcp14> be returned, as described in <xref
target="endpoints_generalized" format="default"/>. Per <xref
target="RFC5440" format="default"/>, 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"
sectionFormat="of" section="3.5"/>, with
the addition of a U bit, O bit, and L bit.
The L bit is
used to represent a suggested set of labels, following
the semantic of Suggested Label as defined by <xref target="RFC347
1" format="default"/>.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved |L|O|U| Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<t> <t>
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"/>.
</t> </t>
<t> <t>
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'
suppress-title='true' style='none'
title='Labels TLV bits'>
<ttcol align='center'></ttcol>
<ttcol align='left'></ttcol>
<c>U:</c><c>Upstream direction: The U bit is set for upstream (rev
ers) direction in case of bidirectional LSP.</c>
<c>O:</c><c>Old Label: set when the TLV represent the
old (previously allocated) label in case of re-optimization.
The R bit of the RP object MUST be set to 1. If the L bit <ul spacing="normal" empty="true"><li>
is set, this bit SHOULD be set to 0 and ignored on receipt. <dl spacing="normal">
<dt>U:</dt>
<dd>Upstream direction. Set for the upstream (reverse)
direction in case of bidirectional LSP.</dd>
<dt>O:</dt><dd>Old label. Set when the TLV represents the old
(previously allocated) label in case of reoptimization. The R
bit of the RP object <bcp14>MUST</bcp14> be set to 1. If the L
bit is set, this bit <bcp14>SHOULD</bcp14> be set to 0 and
ignored on receipt. When this bit is set, the Action field
<bcp14>MUST</bcp14> be set to 0 (Inclusive List), and the
LABEL-SET <bcp14>MUST</bcp14> contain one subchannel.</dd>
<dt>L:</dt><dd>Loose label. Set when the TLV indicates to the
PCE that a set of preferred (ordered) labels are to be
used. The PCE <bcp14>MAY</bcp14> use those labels for label
allocation. </dd></dl></li></ul>
When this bit is set, the Action field MUST be set to 0
(Inclusive List) and the Label Set MUST contain one
subchannel.</c>
<c>L:</c><c>Loose Label: set when the TLV indicates to the PCE a s
et of
preferred (ordered) labels to be used. The PCE MAY use those
labels for label allocation.
</c>
</texttable>
<t> <t>
Several LABEL_SET TLVs MAY be present with the O bit Several LABEL_SET TLVs <bcp14>MAY</bcp14> be present with the O bi
cleared, LABEL_SET TLVs with L bit set can t
be combined with a LABEL_SET TLV with L bit cleared. 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>
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>
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>If a LABEL-SET TLV is present with the O bit set, the R bit of
bit of the RP object MUST be set, otherwise a PCErr the RP object <bcp14>MUST</bcp14> be set; otherwise, a PCErr
message MUST be sent with Error-Type=10 (Reception of an invalid obj message <bcp14>MUST</bcp14> be sent with Error-Type=10 (Reception
ect) of an invalid object) and Error-value=28 (LABEL-SET TLV
Error-value=TBA-24 (LABEL-SET TLV present with O bit set but without present with O bit set but without R bit set in RP).</t>
R bit set in RP).</t> </section>
</section> <!-- end Label TLV -->
</section> <!-- ENDPOINTS TLVs extensions --> </section>
</section> <!-- ENDPOINTS extensions -->
<!-- IRO extension --> </section>
<section title="IRO Extension" anchor="iro-label">
<t>The IRO as defined in <xref target="RFC5440" /> is used to <section anchor="iro-label" numbered="true" toc="default">
<name>IRO Extension</name>
<t>The IRO as defined in <xref target="RFC5440" format="default"/> is us
ed 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"/>, the IRO needs to support the new subobject
in <xref target="RFC3473" />: type as defined in <xref target="RFC3473" format="default"/>:
</t> </t>
<texttable suppress-title='true' style='none' > <table align="center">
<ttcol align='left'></ttcol> <thead>
<ttcol align='left'></ttcol> <tr>
<c>Type</c><c>Sub-object </c> <th align="left">Type</th>
<c>TBA-38</c><c> LABEL</c> <th align="left">Subobject</th>
</texttable> </tr>
<t>The Label subobject MUST follow a subobject identifying a link, currently a </thead>
n IP address subobject (Type 1 or 2) or an interface ID (type 4) subobject. <tbody>
If an IP address subobject is used, then the given IP address MUST be associat <tr>
ed with a link. <td align="left">10</td>
More than one label subobject MAY follow each link subobject. <td align="left">Label</td>
The procedure associated with this subobject is as follows. </tr>
</t> </tbody>
<t> </table>
If the PCE is able to allocate labels (e.g., via explicit label control) the PC <t>The Label subobject <bcp14>MUST</bcp14> follow a subobject
E MUST allocate one label from within the set of label values for the given link identifying a link, currently an IP address subobject (Type 1 or 2) or
. an interface ID (Type 4) subobject. If an IP address subobject is
If the PCE does not assign labels, then it sends a response with a used, then the given IP address <bcp14>MUST</bcp14> be associated with
NO-PATH object, containing a NO-PATH-VECTOR TLV with the bit 'No label resource a link. More than one Label subobject <bcp14>MAY</bcp14> follow each
in range' set. subobject identifying a link. The procedure associated with this subobj
</t> ect is as
</section> follows.
<!-- End IRO --> </t>
<!-- XRO extension --> <t>
<section title="XRO Extension" anchor="xro-label"> If the PCE is able to allocate labels (e.g., via explicit label control), the
<t>The XRO as defined in <xref target="RFC5521" /> is used to 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="default">
<name>XRO Extension</name>
<t>The XRO as defined in <xref target="RFC5521" format="default"/> is us
ed 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"/>. In order to fulfill requirem
13 of <xref target="RFC7025" /> Section 3.1, the PCEP's XRO needs to ent
13 in <xref target="RFC7025" sectionFormat="of" section="3.1"/>, the PCEP's XR
O needs to
support a new subobject to enable label exclusion.</t> support a new subobject to enable label exclusion.</t>
<t>
<t>
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 /> and the XRO subobject defined in <xref target="RFC5521" format="default"/>. T
XRO Label subobject represent one Label and is defined as follows: he
</t> XRO Label subobject (Type 10) represents one label and is defined as follows:
<figure> </t>
<preamble>XRO Subobject Type TBA-39: Label Subobject.</preamble>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type=TBA-39 | Length |U| Reserved | C-Type | |X| Type=10 | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<t>
<list style='empty'>
<t>X (1 bit): as per <xref target="RFC5521" />.
The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the resource specified MUST be excluded from the
path computed by the PCE. 1 indicates that the resource specified
SHOULD be excluded from the path computed by the PCE, but MAY be
included subject to PCE policy and the absence of a viable path
that meets the other constraints and excludes the resource.
</t>
<t>Type (7 bits): The Type of the XRO Label subobject is TBA-39<!--, sugg
ested value 3-->.</t>
<t>Length (8 bits): see <xref target="RFC5521" />, the total
length of the subobject in bytes (including the Type and Length fields).
The Length is always divisible by 4.</t>
<t>U (1 bit): see <xref target="RFC3471" /> Section 6.1.</t>
<t>C-Type (8 bits): the C-Type of the included Label Object as defined in
<xref target="RFC3473" />.</t>
<t>Label: see <xref target="RFC3471" />.</t>
</list>
The Label subobject MUST follow a subobject identifying a link, <dl newline="false" spacing="normal">
<dt>X (1 bit):</dt><dd>See <xref target="RFC5521"
format="default"/>. The X bit indicates whether the exclusion is
mandatory or desired. 0 indicates that the resource specified
<bcp14>MUST</bcp14> be excluded from the path computed by the PCE. 1
indicates that the resource specified <bcp14>SHOULD</bcp14> be
excluded from the path computed by the PCE, but it
<bcp14>MAY</bcp14> be included subject to the PCE policy and the
absence of a viable path that meets the other constraints and
excludes the resource.</dd>
<dt>Type (7 bits):</dt><dd>The type of the XRO Label subobject is
10.</dd>
<dt>Length (8 bits):</dt><dd>See <xref target="RFC5521"
format="default"/>. The total length of the subobject in bytes
(including the Type and Length fields). The length is always
divisible by 4.</dd>
<dt>U (1 bit):</dt><dd>See <xref target="RFC3471"
sectionFormat="comma" section="6.1"/>.</dd>
<dt>C-Type (8 bits):</dt><dd>The C-Type of the included Label object
as defined in <xref target="RFC3473" format="default"/>.</dd>
<dt>Label:</dt><dd>See <xref target="RFC3471"
format="default"/>.</dd>
</dl>
<t>
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">
<ttcol align='left'></ttcol> <thead>
<ttcol align='left'></ttcol> <tr>
<c>Type</c><c>Sub-object </c> <th align="left">Type</th>
<c>3</c><c>LABEL</c> <th align="left">Subobject</th>
</texttable> </tr>
</section> </thead>
<!-- End XRO--> <tbody>
<tr>
<td align="left">10</td>
<td align="left">Label</td>
</tr>
</tbody>
</table>
</section>
<section title="LSPA Extensions" anchor="lspa"> <section anchor="lspa" numbered="true" toc="default">
<name>LSPA Extensions</name>
<t> <t>
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"/> and requirement 3 in <xref target="RFC7025"
target="RFC7025" /> Section 3.2. This TLV contains the information of sectionFormat="of" section="3.2"/>. This TLV contains the information of the PR
the PROTECTION object defined by <xref target="RFC4872"/> and can be used as a p OTECTION object defined by <xref target="RFC4872" format="default"/> and can be
olicy input. used as a policy input.
The LSPA object MAY carry a PROTECTION-ATTRIBUTE TLV defined as: The LSPA object <bcp14>MAY</bcp14> carry a PROTECTION-ATTRIBUTE TLV
Type TBA-12: PROTECTION-ATTRIBUTE</t> (Type 44), which is defined as follows:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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>The content is as defined in <xref target="RFC4872" sectionFormat="co
Section 14, <xref target="RFC4873"></xref> Section 6.1.</postamble> mma" section="14"/> and <xref target="RFC4873" sectionFormat="comma" section="6.
</figure> 1"/>.</t>
<t>LSP (protection) Flags or Link flags field can be used by a <t>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>This TLV is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY</bcp14> be ignored
PCE, it 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="default">
<section title="NO-PATH Object Extension"> <name>NO-PATH Object Extension</name>
<t> <t>
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="default">
<name>Extensions to NO-PATH-VECTOR TLV</name>
<t> <t>
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 -->
</section> <!-- end NO-PATH -->
</section> <!-- End PCEP Object and Extensions--> <ul empty="true" spacing="normal"><li>
<dl spacing="normal">
<dt>Bit number 18:</dt><dd>Protection Mismatch (1 bit). Specifies th
e mismatch of the protection type in the PROTECTION-ATTRIBUTE TLV in the request
. </dd>
<dt>Bit number 17:</dt><dd>No Resource (1 bit). Specifies that the r
esources are not currently sufficient to provide the path. </dd>
<dt>Bit number 16:</dt><dd>Granularity not supported
(1 bit). Specifies that the PCE is not able to provide a
path with the requested granularity. </dd>
<dt>Bit number 15:</dt><dd>No endpoint label resource (1 bit). Speci
fies that the PCE is not able to provide a path because of the endpoint label re
striction.</dd>
<dt>Bit number 14:</dt><dd>No endpoint label resource in range (1 bi
t). Specifies that the PCE is not able to provide a path because of the endpoint
label set restriction. </dd>
<dt>Bit number 13:</dt><dd>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>Bit number 12:</dt><dd>LOAD-BALANCING could not be performed
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>
<section title="Additional Error-Types and Error-Values Defined" anchor="err </dl></li></ul>
or-codes"> </section>
</section>
</section>
<section anchor="error-codes" numbered="true" toc="default">
<name>Additional Error-Types and Error-Values Defined</name>
<t> <t>
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"
. Additional Error-values are defined for Error-Types 4 and 10. A new Error-Type format="default"/>. Additional Error-values are defined for
is defined (value TBA-27). Error-Types 4 and 10. A new Error-Type 29 (Path computation failure)
is defined in this document.
</t> </t>
<t> <t>
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'>
<ttcol align='center' width="4%">Error-Type</ttcol>
<ttcol align='left' width="14%">Error-value</ttcol>
<ttcol align='left' width="53%"></ttcol>
<c>4</c><c>Not supported object </c><c></c> <table align="center">
<thead>
<tr>
<th align="left">Error-Type</th>
<th align="left">Meaning</th>
<th align="left">Error-value</th>
</tr>
</thead>
<tbody>
<c></c><c>value=TBA-14:</c><c>Bandwidth Object type TBA-2 or TBA-3 not s <tr>
upported</c> <td align="left">4</td>
<c></c><c>value=TBA-15:</c><c>Unsupported endpoint type in </c> <td align="left">Not supported object</td>
<c></c><c></c><c>END-POINTS Generalized Endpoint</c> <td></td>
<c></c><c></c><c>object type</c> </tr>
<c></c><c>value=TBA-16:</c><c>Unsupported TLV present in END-POINTS Gene
ralized Endpoint object type</c>
<c></c><c>value=TBA-17:</c><c>Unsupported granularity in the RP object f
lags</c>
<c>10</c><c>Reception of an invalid object</c><c></c> <tr>
<c></c><c>value=TBA-18:</c><c>Bad Bandwidth Object type <td></td>
TBA-2(Generalized bandwidth) or TBA-3( Generalized bandwidth of <td></td>
existing TE-LSP for which a reoptimization is requested)</c> <td align="left">6: BANDWIDTH object type 3 or 4 not supported</td
<c></c><c>value=TBA-20:</c><c>Unsupported LSP Protection Flags in PROT >
ECTION-ATTRIBUTE TLV</c> </tr>
<c></c><c>value=TBA-21:</c><c>Unsupported Secondary LSP Protection Fla <tr>
gs in PROTECTION-ATTRIBUTE TLV</c> <td></td>
<c></c><c>value=TBA-22:</c><c>Unsupported Link Protection Type in PROT <td></td>
ECTION-ATTRIBUTE TLV</c> <td align="left">7: Unsupported endpoint type in END-POINTS
<c></c><c>value=TBA-24:</c><c>LABEL-SET TLV present with 0 bit set but Generalized Endpoint object type</td>
without R bit set in RP</c> </tr>
<c></c><c>value=TBA-25:</c><c>Wrong LABEL-SET</c> <tr>
<c></c><c></c><c>TLV present with</c> <td></td>
<c></c><c></c><c>0 and L bit set</c> <td></td>
<c></c><c>value=TBA-26:</c><c>Wrong LABEL-SET with O bit <td align="left">8: Unsupported TLV present in END-POINTS
set and wrong format</c> Generalized Endpoint object type</td>
<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> <tr>
<c></c><c>value=0:</c><c>Unassigned</c> <td></td>
<c></c><c>value=TBA-28:</c><c>Unacceptable request message</c> <td></td>
<c></c><c>value=TBA-29:</c><c>Generalized bandwidth value not supporte <td align="left">9: Unsupported granularity 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>
<c></c><c>value=TBA-31:</c><c>Label constraint could not be</c>
<c></c><c></c><c>met</c>
</texttable> <tr>
<td align="left">10</td>
<td align="left">Reception of an invalid object </td>
<td></td>
</tr>
</section> <tr>
<td></td>
<td></td>
<td align="left">24: Bad BANDWIDTH object type 3 or 4</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">25: Unsupported LSP Protection Flags in
PROTECTION-ATTRIBUTE TLV</td>
<section title="Manageability Considerations"> </tr>
<t>This section follows the guidance of <xref target="RFC6123" />.</t> <tr>
<section title="Control of Function through Configuration and Policy"> <td></td>
<td></td>
<td align="left">26: Unsupported Secondary LSP Protection Flags
in PROTECTION-ATTRIBUTE TLV</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">27: Unsupported Link Protection Type in
PROTECTION-ATTRIBUTE TLV</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">28: LABEL-SET TLV present with O bit set but
without R bit set in RP</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">29: Wrong LABEL-SET TLV present with O and L
bits set</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">30: Wrong LABEL-SET TLV present with O bit set an
d wrong
format</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">31: Missing GMPLS-CAPABILITY TLV</td>
</tr>
<tr>
<td align="left">29</td>
<td align="left">Path computation failure</td>
<td></td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">0: Unassigned</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">1: Unacceptable request message</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">2: Generalized bandwidth value not
supported</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">3: Label set constraint could not be met</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">4: Label constraint could not be met</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>This section follows the guidance of <xref target="RFC6123" format="def
ault"/>.</t>
<section numbered="true" toc="default">
<name>Control of Function through Configuration and Policy</name>
<t> <t>
This document makes no change to the basic operation of PCEP and so 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"/> also appl
In addition to those requirements a PCEP implementation may allow the y 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">
<t>Default RG to use (overriding the one present in the PCReq)</t> <li>Accepted RG in the RP object.</li>
<t>Accepted BANDWIDTH object type TBA-2 and TBA-3 parameters in requ <li>Default RG to use (overriding the one present in the PCReq).</li>
est, default mapping to use when not specified in the request</t> <li>Accepted BANDWIDTH object type 3 and 4 parameters in the
<t>Accepted LOAD-BALANCING object type TBA-4 parameters in request.< request and default mapping to use when not specified in the request.</
/t> li>
<t>Accepted endpoint type and allowed TLVs in object END-POINTS with <li>Accepted LOAD-BALANCING object type 2 parameters in request.</li>
object type Generalized Endpoint.</t> <li>Accepted endpoint type and allowed TLVs in object END-POINTS with
<t>Accepted range for label restrictions in label restriction in END the object type Generalized Endpoint.</li>
-POINTS, or IRO or XRO objects</t>
<t>PROTECTION-ATTRIBUTE TLV acceptance and suppression.</t> <li>Accepted range for label restrictions in END-POINTS or IRO/XRO obj
</list> ects.</li>
The configuration of the above parameters is applicable to the differe
nt sessions as described in <xref target="RFC5440" /> Section 8.1 (by default, p <li>Acceptance and suppression of the PROTECTION-ATTRIBUTE TLV.</li>
er PCEP peer, etc.). </ul>
<t>
The configuration of the above parameters is applicable to the differe
nt sessions as described in <xref target="RFC5440" sectionFormat="comma" section
="8.1"/> (by default, per PCEP peer, etc.).
</t> </t>
</section> </section>
<section title="Information and Data Models"> <section numbered="true" toc="default">
<name>Information and Data Models</name>
<t> <t>
This document makes no change to the basic operation of PCEP and so 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"/> also appl
This document does not introduce any new ERO sub objects, so that the y to this document.
, ERO information model is already covered in <xref target="RFC4802"/>. This document does not introduce any new ERO subobjects; the ERO info
rmation model is already covered in <xref target="RFC4802" format="default"/>.
</t> </t>
</section> </section>
<section title="Liveness Detection and Monitoring"> <section numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<t> <t>
This document makes no change to the basic operation of PCEP and so This document makes no change to the basic operation of PCEP, so
there are no changes to the requirements for liveness detection and there are no changes to the requirements for liveness detection and
monitoring set out in <xref target="RFC4657" /> and <xref target="RFC5 440" /> Section 8.3. monitoring in <xref target="RFC4657" format="default"/> and <xref targ et="RFC5440" sectionFormat="comma" section="8.3"/>.
</t> </t>
</section> </section>
<section title="Verifying Correct Operation"> <section numbered="true" toc="default">
<name>Verifying Correct Operation</name>
<t> <t>
This document makes no change to the basic operations of PCEP and cons iderations described in <xref target="RFC5440" /> Section 8.4. This document makes no change to the basic operations of PCEP and the considerations described in <xref target="RFC5440" sectionFormat="comma" section ="8.4"/>.
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="default">
> <name>Requirements on Other Protocols and Functional Components</name>
<t>No new Requirements on Other Protocols and Functional <t>No new requirements on other protocols and functional
Components are made by this document. This document does not 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="default">
<t>This document makes no change to the basic operations of PCEP and con <name>Impact on Network Operation</name>
siderations described in <xref target="RFC5440" /> Section 8.6. <t>This document makes no change to the basic operations of PCEP and the
In addition to the limit on the rate of messages sent by a PCEP speaker, considerations described in <xref target="RFC5440" sectionFormat="comma" sectio
a limit MAY be placed on the size of the PCEP messages. n="8.6"/>.
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="default">
<name>IANA Considerations</name>
<t> <t>
IANA assigns values to the PCEP objects and TLVs. IANA is IANA assigns values to PCEP objects and TLVs. IANA has
requested to make some allocations for the newly defined objects and made allocations for the newly defined objects and
TLVs defined in this document. Also, IANA is requested to manage TLVs defined in this document. In addition, IANA manages
the space of flags that are newly added in the TLVs. the space of flags that have been newly added in the TLVs.
</t> </t>
<section title="PCEP Objects"> <section numbered="true" toc="default">
<t>As described in <xref target="generalized-bandwidth"/>, <xref target="g <name>PCEP Objects</name>
eneralized-load-balancing"/> and <xref target="endpoints_generalized" /> new Obj
ects types are defined. <t>New object types are defined in Sections <xref
IANA is requested to make the following Object-Type target="generalized-bandwidth" format="counter"/>, <xref
allocations from the "PCEP Objects" sub-registry. target="generalized-load-balancing" format="counter"/>, and <xref
target="endpoints_generalized" format="counter"/>. 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'>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<c>Object Class</c><c>5</c>
<c>Name</c><c> BANDWIDTH</c>
<c>Object-Type</c><c>TBA-2: Generalized bandwidth </c>
<c> </c><c>TBA-3: Generalized bandwidth of an existing TE-LS
P for which a reoptimization is requested </c>
<c>Reference</c><c>This document (<xref target="generalized-bandwidth"
></xref>)</c>
<c /><c />
<c>Object Class</c><c>14</c>
<c>Name</c><c> LOAD-BALANCING</c>
<c>Object-Type</c><c>TBA-4: Generalized Load Balancing </c>
<c /><c />
<c>Reference</c><c>This document (<xref target="generalized-load-balan
cing"></xref>)</c>
<c>Object Class</c><c>4</c>
<c>Name</c><c> END-POINTS</c>
<c>Object-Type</c><c>TBA-5: Generalized Endpoint </c>
<c>Reference</c><c>This document (<xref target="endpoints_extensions">
</xref>)</c>
</texttable>
</section> <!-- End New PCEP Objects--> <table anchor="iana_gen_bw" align="center">
<section title="Endpoint type field in Generalized END-POINTS Object"> <thead>
<t>IANA is requested to create a registry to manage the Endpoint Type fie <tr>
ld of the END-POINTS object, Object Type Generalized Endpoint and manage the cod <th align="left">Object-Class Value</th>
e space.</t> <th align="left">Name</th>
<t>New endpoint type in the Reserved range are assigned by <th align="left">Object-Type</th>
Standards Action <xref target="RFC8126"/>. Each endpoint type should <th align="left">Reference</th>
be tracked with the following attributes: </tr>
<list style='symbols'> </thead>
<t>Endpoint type</t> <tbody>
<t>Description</t> <tr>
<t>Defining RFC</t> <td align="left">5</td>
</list> <td align="left">BANDWIDTH</td>
</t> <td align="left">3: Generalized bandwidth</td>
<t>New endpoint type in the Experimental range are for experimental us <td align="left">RFC 8779, <xref target="generalized-bandwidth" fo
e; these will not be registered with IANA and MUST NOT be mentioned by RFCs.</t> rmat="default"/></td>
<t>The following values have been defined by this document. </tr>
(<xref target="endpoints_generalized"></xref>, <xref <tr>
target="endpoints_generalized_endpoint-type" />):</t> <td align="left"></td>
<texttable suppress-title='true' style='none'> <td align="left"></td>
<ttcol align='left'>Value</ttcol> <td align="left">4: Generalized bandwidth of an existing TE-LSP
<ttcol align='left'>Type</ttcol> for which a reoptimization is requested</td>
<ttcol align='left'>Meaning</ttcol> <td align="left">RFC 8779, <xref target="generalized-bandwidth" fo
<c>0</c><c>Point-to-Point</c> <c></c> rmat="default"/></td>
<c>1</c><c>Point-to-Multipoint</c><c>New leaves to add</c> </tr>
<c>2</c><c></c> <c>Old leaves to remove</c> <tr>
<c>3</c><c></c> <c>Old leaves whose path can be m <td align="left">14</td>
odified/reoptimized</c> <td align="left">LOAD-BALANCING</td>
<c>4</c><c></c> <c>Old leaves whose path has to b <td align="left">2: Generalized Load Balancing</td>
e</c> <td align="left">RFC 8779, <xref target="generalized-load-balancin
<c></c><c></c> <c>left unchanged</c> g" format="default"/></td>
<c>5-244</c><c>Unassigned</c><c></c> </tr>
<c>245-255</c> <c>Experimental range</c><c></c> <tr>
</texttable> <td align="left">4</td>
</section> <!-- End END-POINTS object, Object Type Generalized Endpoint--> <td align="left">END-POINTS</td>
<td align="left">5: Generalized Endpoint</td>
<td align="left">RFC 8779, <xref target="endpoints_extensions" for
mat="default"/></td>
</tr>
</tbody>
</table>
</section>
<section title="New PCEP TLVs" anchor='iana-tlvs'> <section numbered="true" toc="default">
<t> <name>Endpoint Type Field in the Generalized END-POINTS Object</name>
IANA manages the PCEP TLV code point registry (see <xref target="RFC544 <t>IANA has created a new "Generalized Endpoint Types" registry to
0"></xref>). This manage the Endpoint Type field of the END-POINTS object, the object
is maintained as the "PCEP TLV Type Indicators" sub-registry of the type Generalized Endpoint, and the code space.</t>
"Path Computation Element Protocol (PCEP) Numbers" registry. <t>New endpoint types in the Unassigned range are assigned by
Standards Action <xref target="RFC8126" format="default"/>. Each
endpoint type should be tracked with the following attributes:
</t>
<ul spacing="normal">
<li>Value</li>
<li>Type</li>
<li>Defining RFC</li>
</ul>
<t>New endpoint types in the Experimental Use range will not be
registered with IANA and <bcp14>MUST NOT</bcp14> be mentioned by any
RFCs.</t>
IANA is requested to do the following allocation. <t>The following values are defined by this document
Note: TBA-11 is not used (see <xref target="endpoints_generalized_endpoint-type" format="defaul
<!-- The values here are suggested for use by IANA. --> t"/> in <xref target="endpoints_generalized" format="default"/>):</t>
</t> <table align="center">
<texttable suppress-title='true' style='none'> <thead>
<ttcol align='center'>Value</ttcol> <tr>
<ttcol align='left'>Meaning</ttcol> <th align="left">Value</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Type</th>
<c>TBA-6</c><c>IPV4-ADDRESS</c><c> This document (<xref tar </tr>
get="endpoints_tlvs_ipv4"></xref>) </c> </thead>
<c>TBA-7</c><c>IPV6-ADDRESS</c><c> This document (<xref tar <tbody>
get="endpoints_tlvs_ipv6"></xref>) </c> <tr>
<c>TBA-8</c><c>UNNUMBERED-ENDPOINT</c><c> This document (<x <td align="left">0</td>
ref target="endpoints_tlvs_unnumbered-if"></xref>) </c> <td align="left">Point-to-Point</td>
<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 </tr>
t="endpoints_tlvs_labels"></xref>) </c> <tr>
<c>TBA-12 </c><c>PROTECTION-ATTRIBUTE</c><c> This document (<xre <td align="left">1</td>
f target="lspa"></xref>) </c> <td align="left">Point-to-Multipoint with leaf type 1</td>
<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 </tr>
pes and Error-values are <tr>
defined. IANA is requested to make the following allocation in the "PCEP <td align="left">2</td>
-ERROR Object Error Types and Values" registry. <td align="left">Point-to-Multipoint with leaf type 2</td>
<!-- 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 </tr>
FC5440" /></c> <tr>
<c>Value=TBA-18:</c><c> Bad Bandwidth Object <td align="left">3</td>
type TBA-2(Generalized bandwidth) or TBA-3(Generalized <td align="left">Point-to-Multipoint with leaf type 3</td>
bandwidth of existing TE-LSP for which a reoptimization is requested)<
/c><c>This Document</c>
<c>Value=TBA-20:</c><c> Unsupported LSP Protection Flags in PROTECTION
-ATTRIBUTE TLV</c><c>This Document</c>
<c>Value=TBA-21:</c><c> Unsupported Secondary LSP Protection Flags in
PROTECTION-ATTRIBUTE TLV</c><c>This Document</c>
<c>Value=TBA-22:</c><c> Unsupported Link Protection Type in PROTECTION
-ATTRIBUTE TLV</c><c>This Document</c>
<c>Value=TBA-24:</c><c> LABEL-SET TLV present with 0 bit set but witho
ut R bit set in RP</c><c>This Document</c>
<c>Value=TBA-25:</c><c> Wrong LABEL-SET TLV present with 0 and L bit s
et</c><c>This Document</c>
<c>Value=TBA-26:</c><c> Wrong LABEL-SET with O bit set and wrong forma
t</c><c>This Document</c>
<c>Value=TBA-42:</c><c> Missing GMPLS-CAPABILITY TLV</c><c>This Docume
nt</c>
<c>Type=TBA-27</c><c>Path computation
failure</c><c>This Document</c>
<c>Value=0</c><c> Unassigned</c><c>This Document</c>
<c>Value=TBA-28:</c><c>Unacceptable request message</c><c>This Documen
t</c>
<c>Value=TBA-29:</c><c>Generalized bandwidth value not supported</c><c
>This Document</c>
<c>Value=TBA-30:</c><c>Label Set constraint could not be met</c><c>Thi
s Document</c>
<c>Value=TBA-31:</c><c>Label constraint could not be met</c><c>This Do
cument</c>
</texttable> </tr>
</section> <tr>
<td align="left">4</td>
<td align="left">Point-to-Multipoint with leaf type 4</td>
<section title="New NO-PATH-VECTOR TLV Fields"> </tr>
<t>As described in <xref target="no-path_bits"></xref>, new NO-PATH-VECT <tr>
OR TLV Flag Fields have been defined. <td align="left">5-244</td>
IANA is requested to do the following allocations in the "NO-PATH-VECTOR TLV Fla <td align="left">Unassigned</td>
g Field" sub-registry.
<!-- The values here are suggested for use by IANA. --> </tr>
<list> <tr>
<t>Bit number TBA-32 - Protection Mismatch (1-bit). Specifies the <td align="left">245-255</td>
mismatch of the protection type of the PROTECTION-ATTRIBUTE TLV in the request. <td align="left">Experimental Use</td>
</t> </tr>
<t>Bit number TBA-33 - No Resource (1-bit). Specifies that the res </tbody>
ources are not currently sufficient to provide the path. </t> </table>
<t>Bit number TBA-34 - Granularity not supported (1-bit). Specifie
s 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>
<t>Bit number TBA-40 - LOAD-BALANCING could not be performed with
the bandwidth constraits (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 t
he LOAD-BALANCING. </t>
</list>
</t>
</section> </section>
<section title="New Subobject for the Include Route Object" >
<t>The "PCEP Parameters" registry contains a subregistry "IRO Subobjects <section anchor="iana-tlvs" numbered="true" toc="default">
" <name>New PCEP TLVs</name>
with an entry for the Include Route Object (IRO).</t>
<t> <t>
IANA is requested to add a further subobject that can be carried in th IANA manages a registry for PCEP TLV code points (see <xref
e IRO as target="RFC5440" format="default"/>), which
follows: is maintained as the "PCEP TLV Type Indicators" subregistry of the
"Path Computation Element Protocol (PCEP) Numbers" registry.
IANA has allocated the following per this document:
</t> </t>
<texttable suppress-title='true' style='none'> <table align="center">
<ttcol align='left'>Subobject</ttcol> <thead>
<ttcol align='left'>type</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="center">Value</th>
<c>TBA-38<!-- , suggested value 3--></c><c>Label <th align="left">Meaning</th>
subobject</c><c>This Document</c> <th align="left">Reference</th>
</texttable> </tr>
</thead>
<tbody>
<tr>
<td align="center">39</td>
<td align="left">IPV4-ADDRESS</td>
<td align="left">RFC 8779, <xref target="endpoints_tlvs_ipv4" form
at="default"/></td>
</tr>
<tr>
<td align="center">40</td>
<td align="left">IPV6-ADDRESS</td>
<td align="left">RFC 8779, <xref target="endpoints_tlvs_ipv6" form
at="default"/></td>
</tr>
<tr>
<td align="center">41</td>
<td align="left">UNNUMBERED-ENDPOINT</td>
<td align="left">RFC 8779, <xref target="endpoints_tlvs_unnumbered
-if" format="default"/></td>
</tr>
<tr>
<td align="center">42</td>
<td align="left">LABEL-REQUEST</td>
<td align="left">RFC 8779, <xref target="endpoints_tlvs_label-requ
est" format="default"/></td>
</tr>
<tr>
<td align="center">43</td>
<td align="left">LABEL-SET</td>
<td align="left">RFC 8779, <xref target="endpoints_tlvs_labels" fo
rmat="default"/></td>
</tr>
<tr>
<td align="center">44 </td>
<td align="left">PROTECTION-ATTRIBUTE</td>
<td align="left">RFC 8779, <xref target="lspa" format="default"/><
/td>
</tr>
<tr>
<td align="center">45</td>
<td align="left">GMPLS-CAPABILITY</td>
<td align="left">RFC 8779, <xref target="open-extensions" format="
default"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section title="New Subobject for the Exclude Route Object" >
<t>The "PCEP Parameters" registry contains a subregistry "XRO Subobjects <section numbered="true" toc="default">
" <name>RP Object Flag Field</name>
with an entry for the XRO object (Exclude Route Object).</t>
<t> <t>
IANA is requested to add a further subobject that can be carried in th A new flag is defined in <xref target="rp-extensions"
e XRO as format="default"/> for the Flags field of the RP object. IANA has
follows: made the following allocation in the "RP Object Flag
Field" subregistry:
</t> </t>
<texttable suppress-title='true' style='none'> <table align="center">
<ttcol align='left'>Subobject</ttcol> <thead>
<ttcol align='left'>type</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="center">Bit</th>
<c>TBA-39<!--, suggested value 3--></c><c>Label subobject</c><c>This D <th align="left">Description</th>
ocument</c> <th align="left">Reference</th>
</texttable> </tr>
</thead>
<tbody>
<tr>
<td align="center">15-16</td>
<td align="left">Routing Granularity (RG)</td>
<td align="left">RFC 8779, <xref target="rp-extensions" format="de
fault"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section title="New GMPLS-CAPABILITY TLV Flag Field" >
<t>IANA is requested to create a sub-registry to manage the Flag field
of the GMPLS-CAPABILITY TLV within the "Path Computation
Element Protocol (PCEP) Numbers" registry.</t>
<t>New bit numbers are to be assigned by Standards Action <xref target="RFC81 <section numbered="true" toc="default">
26"/>. <name>New PCEP Error Codes</name>
Each bit should be tracked with the following qualities: <t>New PCEP Error-Types and Error-values are defined in <xref
<list style="symbols"> target="error-codes" format="default"/>. IANA has made the
following allocations in the "PCEP-ERROR Object Error Types and Values"
registry:
<t>Bit number (counting from bit 0 as the most significant bit)</t> </t>
<table align="center">
<thead>
<tr>
<th align="left">Error-Type</th>
<th align="left">Meaning</th>
<th align="left">Error-value</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<t>Capability description</t> <tr>
<td align="left">4</td>
<td align="left">Not supported object</td>
<td></td>
<td align="left"><xref target="RFC5440" format="default"/></td>
</tr>
<t>Defining RFC</t> <tr>
</list></t> <td></td>
<td></td>
<td align="left">6: BANDWIDTH object type 3 or 4 not supported</td
>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">7: Unsupported endpoint type in END-POINTS
Generalized Endpoint object type</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">8: Unsupported TLV present in END-POINTS
Generalized Endpoint object type</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">9: Unsupported granularity in the RP object flags
</td>
<td align="left">RFC 8779</td>
</tr>
<t>The initial contents of the sub-registry are empty, with all bits <tr>
marked unassigned</t> <td align="left">10</td>
<td align="left">Reception of an invalid object </td>
<td></td>
<td align="left"><xref target="RFC5440" format="default"/></td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">24: Bad BANDWIDTH object type 3 or 4</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">25: Unsupported LSP Protection Flags in
PROTECTION-ATTRIBUTE TLV</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">26: Unsupported Secondary LSP Protection Flags
in PROTECTION-ATTRIBUTE TLV</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">27: Unsupported Link Protection Type in
PROTECTION-ATTRIBUTE TLV</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">28: LABEL-SET TLV present with O bit set but
without R bit set in RP</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">29: Wrong LABEL-SET TLV present with O and L bits
set</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">30: Wrong LABEL-SET TLV present with O bit set an
d wrong format</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">31: Missing GMPLS-CAPABILITY TLV</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td align="left">29</td>
<td align="left">Path computation failure</td>
<td></td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">0: Unassigned</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">1: Unacceptable request message</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">2: Generalized bandwidth value not supported</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">3: Label set constraint could not be met</td>
<td align="left">RFC 8779</td>
</tr>
<tr>
<td></td>
<td></td>
<td align="left">4: Label constraint could not be met</td>
<td align="left">RFC 8779</td>
</tr>
</tbody>
</table>
</section> </section>
</section> <!-- End IANA -->
<section title="Security Considerations"> <section numbered="true" toc="default">
<name>New Bits in NO-PATH-VECTOR TLV</name>
<t>New NO-PATH-VECTOR TLV bits are defined in <xref
target="no-path_bits" format="default"/>. IANA has made the
following allocations in the "NO-PATH-VECTOR TLV Flag Field"
subregistry:
</t>
<table anchor="no-path-vector-iana">
<thead>
<tr>
<th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>18</td>
<td>Protection Mismatch</td>
<td>RFC 8779</td>
</tr>
<tr>
<td>17</td>
<td>No Resource</td>
<td>RFC 8779</td>
</tr>
<tr>
<td>16</td>
<td>Granularity not supported</td>
<td>RFC 8779</td>
</tr>
<tr>
<td>15</td>
<td>No endpoint label resource</td>
<td>RFC 8779</td>
</tr>
<tr>
<td>14</td>
<td>No endpoint label resource in range</td>
<td>RFC 8779</td>
</tr>
<tr>
<td>13</td>
<td>No label resource in range</td>
<td>RFC 8779</td>
</tr>
<tr>
<td>12</td>
<td>LOAD-BALANCING could not be performed with the bandwidth constraints</
td>
<td>RFC 8779</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>New Subobject for the Include Route Object</name>
<t>IANA has added a new subobject in the "IRO Subobjects" subregistry of
the
"Path Computation Element Protocol (PCEP) Numbers" registry.</t>
<t>
IANA has added a new subobject that can be carried in the IRO as
follows:
</t>
<table align="center">
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">10</td>
<td align="left">Label</td>
<td align="left">RFC 8779</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>New Subobject for the Exclude Route Object</name>
<t>IANA has added a new subobject in the "XRO Subobjects" subregistry of
the
"Path Computation Element Protocol (PCEP) Numbers" registry.</t>
<t>
IANA has added a new subobject that can be carried in the XRO as
follows:
</t>
<table align="center">
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">10</td>
<td align="left">Label</td>
<td align="left">RFC 8779</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>New GMPLS-CAPABILITY TLV Flag Field</name>
<t>IANA has created a new "GMPLS-CAPABILITY TLV Flag Field"
subregistry within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the Flag field of the GMPLS-CAPABILITY TLV.<
/t>
<t>New bit numbers are to be assigned by Standards Action <xref target="
RFC8126" format="default"/>.
Each bit should be tracked with the following qualities:
</t>
<ul spacing="normal">
<li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li>
<li>Defining RFC</li>
</ul>
<t>The initial contents of the subregistry are empty, with bits 0-31
marked as Unassigned.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t> <t>
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">
PCE Identity theft: A legitimate PCC could request a path for a GMPLS <li>
LSP to <dl spacing="normal">
<dt>PCE Identity theft:</dt><dd>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>
<t> <dt>
PCC Identity theft: A malicious PCC, acting as a legitimate PCC, requ PCC Identity theft:</dt><dd>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>
Message inspection: As in the previous case, knowledge of an infrastr Message inspection:</dt><dd>As in the previous case, knowledge of an
ucture can infrastructure can
be obtained by sniffing PCEP messages. be obtained by sniffing PCEP messages.
</t> </dd></dl></li>
</list> </ul>
<t>
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"/>
verification, message integrity and replay protection, and ensures 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>
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"/>) to verify the data-plane connectivity and deviation from constraint
plane connectivity and deviation from constraints. s.
</t> </t>
<t> <t>
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"/>. The document describes the initiation
ation of TLS procedures, the TLS handshake mechanisms, the TLS methods for peer
of the TLS procedures, the TLS handshake mechanisms, the TLS methods for
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"/> to protect against mal
icious
PCC and PCE. PCC and PCE.
</t> </t>
<t> <t>
Finally, as mentioned by <xref target="RFC7025" /> the PCEP extensions to Finally, as mentioned by <xref target="RFC7025" format="default"/>, the P
support GMPLS should CEP extensions that support GMPLS should
be considered under the same security as current PCE work and this extens be considered under the same security as current PCE work, and this exten
ion 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"/>.
</t> </t>
</section> </section>
<section title="Contributing Authors">
<t>Elie Sfeir<vspace blankLines='0'/>
Coriant<vspace blankLines='0'/>
St Martin Strasse 76<vspace blankLines='0'/>
Munich, 81541<vspace blankLines='0'/>
Germany<vspace blankLines='1'/>
Email: elie.sfeir@coriant.com<vspace blankLines='0'/>
</t>
<t> </middle>
Franz Rambach<vspace blankLines='0'/>
Nockherstrasse 2-4,<vspace blankLines='0'/> <back>
Munich 81541<vspace blankLines='0'/> <references>
Germany<vspace blankLines='1'/> <name>References</name>
Phone: +49 178 8855738<vspace blankLines='0'/> <references>
Email: franz.rambach@cgi.com<vspace blankLines='0'/> <name>Normative References</name>
</t>
<t> <reference anchor="G.709-v3" target="https://www.itu.int/rec/T-REC-G.709
Francisco Javier Jimenez Chico<vspace blankLines='0'/> -201606-I/en">
Telefonica Investigacion y Desarrollo<vspace blankLines='0'/> <front>
C/ Emilio Vargas 6<vspace blankLines='0'/> <title>
Madrid, 28043<vspace blankLines='0'/> Interfaces for the optical transport network
Spain<vspace blankLines='1'/> </title>
Phone: +34 91 3379037<vspace blankLines='0'/> <author>
Email: fjjc@tid.es<vspace blankLines='0'/> <organization>ITU-T</organization>
</t> </author>
<t> <date year="2016" month="June"/>
Huawei Technologies </front>
<list> <refcontent>Recommendation G.709/Y.1331</refcontent>
<t>Suresh BR<vspace blankLines='0'/> </reference>
Shenzhen<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
China<vspace blankLines='0'/> ence.RFC.2119.xml"/>
Email: sureshbr@huawei.com<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.2210.xml"/>
<t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Young Lee<vspace blankLines='0'/> ence.RFC.3209.xml"/>
1700 Alma Drive, Suite 100<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Plano, TX 75075<vspace blankLines='0'/> ence.RFC.3471.xml"/>
USA<vspace blankLines='1'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Phone: (972) 509-5599 (x2240)<vspace blankLines='0'/> ence.RFC.3473.xml"/>
Email: ylee@huawei.com<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.3477.xml"/>
<t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
SenthilKumar S<vspace blankLines='0'/> ence.RFC.3630.xml"/>
Shenzhen<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
China<vspace blankLines='0'/> ence.RFC.4003.xml"/>
Email: senthilkumars@huawei.com<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.4328.xml"/>
<t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Jun Sun<vspace blankLines='0'/> ence.RFC.4606.xml"/>
Shenzhen<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
China<vspace blankLines='0'/> ence.RFC.4802.xml"/>
Email: johnsun@huawei.com <vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.4872.xml"/>
</list> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.4873.xml"/>
<t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya ence.RFC.5088.xml"/>
<list> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<t>Ramon Casellas<vspace blankLines='0'/> ence.RFC.5089.xml"/>
PMT Ed B4 Av. Carl Friedrich Gauss 7<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
08860 Castelldefels (Barcelona)<vspace blankLines='0'/> ence.RFC.5440.xml"/>
Spain<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Phone: (34) 936452916 <vspace blankLines='0'/> ence.RFC.5511.xml"/>
Email: ramon.casellas@cttc.es<vspace blankLines='0'/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.5520.xml"/>
</list> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</t> ence.RFC.5521.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5541.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6001.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6003.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6205.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6387.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7570.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7139.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7792.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8253.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8282.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8306.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4655.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4657.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5920.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6123.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6163.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7025.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7449.xml"/>
</references>
</references>
<section anchor="appendix" numbered="true" toc="default">
<name>LOAD-BALANCING Usage for SDH Virtual Concatenation</name>
<t>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.
The LOAD-BALANCING with object type 2 with the Bw Spec Type set
to 4 and Max-LSP=5, Min Bandwidth Spec is ST=6, RCC=0, NCC=0, NVC=2, MT=1.
The PCE can respond with a maximum of 5 paths, with each path having a
BANDWIDTH object type 3 and a Generalized Bandwidth field matching the Min
Bandwidth
Spec from the LOAD-BALANCING object of the corresponding request.</t>
</section> </section>
<section title="Acknowledgments"> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t> <t>
The research of Ramon Casellas, Francisco Javier Jimenez Chico, Oscar Go The research of <contact fullname="Ramon Casellas"/>, <contact
nzalez de Dios, Cyril Margaria, and Franz Rambach leading fullname="Francisco Javier Jimenez Chico"/>, <contact fullname="Oscar
to these results Gonzalez de Dios"/>, <contact fullname="Cyril Margaria"/>, and
has received funding from the European Community's Seventh Framework Pro <contact fullname="Franz Rambach"/> that led to the results in this
gram FP7/2007-2013 document received funding from the European Community's Seventh
under grant agreement no 247674 and no 317999. Framework Program FP7/2007-2013 under grant agreement no. 247674 and
no. 317999.
</t> </t>
<t> <t>
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 Roca"/>, <contact fullname="Dhruv Dhody"/>, <contact
fullname="Adrian Farrel"/>, and <contact fullname="Tianran Zhou"/> for
their review and useful comments.
</t> </t>
<t> Thanks to Alisa Cooper, Benjamin Kaduk, Elwun-davies,
Martin Vigoureux, Roman Danyliw, and Suresh Krishnan for the IESG <t> Thanks to <contact fullname="Alisa Cooper"/>, <contact
comments</t> fullname="Benjamin Kaduk"/>, <contact fullname="Elwyn Davies"/>,
<contact fullname="Martin Vigoureux"/>, <contact fullname="Roman
Danyliw"/>, and <contact fullname="Suresh Krishnan"/> for the
IESG-related comments.</t>
</section> </section>
</middle> <section numbered="false" toc="default">
<name>Contributors</name>
<!-- *****BACK MATTER ***** --> <contact fullname="Elie Sfeir" >
<organization>Coriant</organization>
<address>
<postal>
<street>St. Martin Strasse 76</street>
<city>Munich</city>
<region></region><code>81541</code>
<country>Germany</country>
</postal>
<email>elie.sfeir@coriant.com</email>
</address>
</contact>
<back> <contact fullname="Franz Rambach" >
<organization></organization>
<address>
<postal>
<street>Nockherstrasse 2-4</street>
<city>Munich</city>
<region></region><code>81541</code>
<country>Germany</country>
</postal>
<phone>+49 178 8855738</phone>
<email>franz.rambach@cgi.com</email>
</address>
</contact>
<references title="Normative References"> <contact fullname="Francisco Javier Jimenez Chico" >
<reference anchor="G.709-v3" target="https://www.itu.int/rec/T-REC-G.709-20 <organization>Telefonica Investigacion y Desarrollo</organization>
1606-I/en"> <address>
<front> <postal>
<title> <street>C/ Emilio Vargas 6</street>
Interfaces for the optical transport network, Recommendation G.709/Y. <city>Madrid</city>
1331 <region></region><code>28043</code>
</title> <country>Spain</country>
<author> <organization>ITU-T</organization></author> </postal>
<date year="2016" month="June"/> <phone>+34 91 3379037</phone>
</front> <email>fjjc@tid.es</email>
</reference> </address>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119 </contact>
.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2210
.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209
.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.347 <contact fullname="Suresh Babu" >
1.xml"?> <organization></organization>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.347 <address>
3.xml"?> <postal>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.347 <street></street>
7.xml"?> <city></city>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.363 <region></region><code></code>
0.xml"?> <country></country>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.400 </postal>
3.xml"?> <email>sureshhimnish@gmail.com</email>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.432 </address>
8.xml"?> </contact>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.460
6.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.480
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.487
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.487
3.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.508
8.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.508
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.544
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.551
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.552
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.552
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.554
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.600
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.600
3.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.620
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.638
7.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.757
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.713
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.779
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.812
6.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.825
3.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.828
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.830
6.xml"?>
</references> <contact fullname="Young Lee" >
<references title="Informative References"> <organization>Samsung Electronics</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></street>
7.xml"?> <city></city>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.592 <region></region><code></code>
0.xml"?> <country></country>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.612 </postal>
3.xml"?> <phone></phone>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.616 <email>younglee.tx@gmail.com</email>
3.xml"?> </address>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.702 </contact>
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.744 <contact fullname="Senthil Kumar S" >
9.xml"?> <organization></organization>
</references> <address>
<section anchor="appendix" title="LOAD-BALANCING Usage for SDH Virtual Conca <postal>
tenation"> <street></street>
<t>For example a request for one co-signaled n x VC-4 TE-LSP <city></city>
will not use the LOAD-BALANCING. In case the VC-4 components can <region></region><code></code>
use different paths, the BANDWIDTH with object type TBA-2 will <country></country>
contain a traffic specification indicating the complete n x VC-4 </postal>
traffic specification and the LOAD-BALANCING the minimum <email>ssenthilkumar@gmail.com</email>
co-signaled VC-4. For an SDH network, a request to have a TE-LSP </address>
group with 10 VC-4 containers, each path using at minimum 2 x </contact>
VC-4 containers, can be represented with a BANDWIDTH object
with OT=TBA-2, Bw Spec Type set to 4, the content of the <contact fullname="Jun Sun" >
Generalized Bandwidth is ST=6, RCC=0, NCC=0, NVC=10, MT=1. The <organization>Huawei Technologies</organization>
LOAD-BALANCING, OT=TBA-4 with Bw Spec Type set to 4, <address>
Max-LSP=5, Min Bandwidth Spec is (ST=6, RCC=0, NCC=0, NVC=2, MT=1). The PC <postal>
E can respond with a response with maximum 5 paths, each of them having a BANDWI <street></street>
DTH OT=TBA-2 and Generalized Bandwidth matching the Min Bandwidth Spec from the <city>Shenzhen</city>
LOAD-BALANCING object of the corresponding request.</t> <region></region><code></code>
<country>China</country>
</postal>
<email>johnsun@huawei.com</email>
</address>
</contact>
<contact fullname="Ramon Casellas" >
<organization>CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
</organization>
<address>
<postal>
<street>PMT Ed B4 Av. Carl Friedrich Gauss 7</street>
<city>Castelldefels,</city>
<region>Barcelona</region><code>08660</code>
<country>Spain</country>
</postal>
<phone>+34 93 6452916</phone>
<email>ramon.casellas@cttc.e</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 235 change blocks. 
1677 lines changed or deleted 2318 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/