rfc8685xml2.original.xml   rfc8685.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5440.xml">
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5541.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC4105 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4105.xml">
<!ENTITY RFC4216 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4216.xml">
<!ENTITY RFC4655 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4655.xml">
<!ENTITY RFC4726 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4726.xml">
<!ENTITY RFC5152 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5152.xml">
<!ENTITY RFC5376 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5376.xml">
<!ENTITY RFC5394 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5394.xml">
<!ENTITY RFC5520 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5520.xml">
<!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5441.xml">
<!ENTITY RFC5925 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5925.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6805.xml">
<!ENTITY RFC7399 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7399.xml">
<!ENTITY RFC7420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7420.xml">
<!ENTITY RFC7752 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7752.xml">
<!ENTITY RFC7897 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7897.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY I-D.ietf-pce-pcep-yang SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.draft-ietf-pce-pcep-yang-11.xml">
<!ENTITY I-D.ietf-pce-stateful-hpce SYSTEM "https://xml2rfc.ietf.org/public/rfc/
bibxml3/reference.I-D.draft-ietf-pce-stateful-hpce-07.xml">
<!ENTITY I-D.dhodylee-pce-pcep-ls SYSTEM "https://xml2rfc.ietf.org/public/rfc/bi
bxml3/reference.I-D.draft-dhodylee-pce-pcep-ls-13.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-pce-hierarchy-extensions-11" cate
gory="std">
<!-- Generated by id2xml 1.4.4 on 2019-06-26T18:42:07Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="PCEP Extensions for H-PCE">Extensions to Path Computation
Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements
(PCE)</title>
<author fullname="Fatai Zhang" initials="F." surname="Zhang">
<organization>Huawei</organization>
<address><postal><street>Huawei Base, Bantian, Longgang District</street>
<street>Shenzhen 518129</street>
<street>China</street>
</postal>
<email>zhangfatai@huawei.com</email>
</address>
</author>
<author fullname="Quintin Zhao" initials="Q." surname="Zhao">
<organization>Huawei</organization>
<address><postal><street>125 Nagog Technology Park</street>
<street>Acton, MA 01719</street>
<street>USA</street>
</postal>
<email>quintin.zhao@huawei.com</email>
</address>
</author>
<!-- [rfced] please review mismatch in affliation names for Oscar Gonzalez de Di
os in the header and addresses sections -->
<author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez
de Dios">
<organization abbrev="Telefonica I+D">Telefonica</organization>
<address><postal><street>Don Ramon de la Cruz 82-84</street>
<street>Madrid 28045</street>
<street>Spain</street>
</postal>
<email>oscar.gonzalezdedios@telefonica.com</email>
</address>
</author>
<author fullname="Ramon Casellas" initials="R." surname="Casellas"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<organization>CTTC</organization> category="std" consensus="true"
<address><postal><street>Av. Carl Friedrich Gauss n.7</street> docName="draft-ietf-pce-hierarchy-extensions-11" number="8685"
<street>Barcelona, Castelldefels</street> ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="false"
<street>Spain</street> symRefs="true" tocInclude="true" tocDepth="4" version="3">
</postal> <!-- xml2rfc v2v3 conversion 2.32.0 -->
<email>ramon.casellas@cttc.es</email> <!-- Generated by id2xml 1.4.4 on 2019-06-26T18:42:07Z -->
</address> <front>
</author> <title abbrev="PCEP Extensions for H-PCE">Path Computation Element
Communication Protocol (PCEP) Extensions for&nbsp;the&nbsp;Hierarchical
Path Computation Element (H-PCE) Architecture</title>
<seriesInfo name="RFC" value="8685"/>
<author fullname="Fatai Zhang" initials="F." surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<region>Shenzhen</region>
<code>518129</code>
<country>China</country>
</postal>
<email>zhangfatai@huawei.com</email>
</address>
</author>
<author fullname="Quintin Zhao" initials="Q." surname="Zhao">
<organization>Huawei</organization>
<address>
<postal>
<street>125 Nagog Technology Park</street>
<city>Acton</city>
<region>MA</region>
<code>01719</code>
<country>United States of America</country>
</postal>
<email>quintinzhao@gmail.com</email>
</address>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de
Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz 82-84</street>
<city>Madrid</city>
<code>28045</code>
<country>Spain</country>
</postal>
<email>oscar.gonzalezdedios@telefonica.com</email>
</address>
</author>
<author fullname="Ramon Casellas" initials="R." surname="Casellas">
<organization>CTTC</organization>
<address>
<postal>
<street>Av. Carl Friedrich Gauss n.7</street>
<city>Castelldefels</city>
<region>Barcelona</region>
<country>Spain</country>
</postal>
<email>ramon.casellas@cttc.es</email>
</address>
</author>
<author fullname="Daniel King" initials="D." surname="King">
<organization>Old Dog Consulting</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>United Kingdom</country>
</postal>
<email>daniel@olddog.co.uk</email>
</address>
</author>
<date month="December" year="2019"/>
<author fullname="Daniel King" initials="D." surname="King"> <keyword>Traffic Engineering, Inter-domain, Multi-domain</keyword>
<organization>Old Dog Consulting</organization>
<address><postal><street>UK</street>
</postal>
<email>daniel@olddog.co.uk</email>
</address>
</author>
<date month="June" year="2019"/> <abstract>
<workgroup>PCE Working Group</workgroup> <t>
<abstract><t>
The Hierarchical Path Computation Element (H-PCE) architecture is The Hierarchical Path Computation Element (H-PCE) architecture is
defined in RFC 6805. It provides a mechanism to derive an optimum defined in RFC 6805. It provides a mechanism to derive an optimum
end-to-end path in a multi-domain environment by using a hierarchical end-to-end path in a multi-domain environment by using a hierarchical
relationship between domains to select the optimum sequence of relationship between domains to select the optimum sequence of
domains and optimum paths across those domains.</t> domains and optimum paths across those domains.</t>
<t>
<t>
This document defines extensions to the Path Computation Element This document defines extensions to the Path Computation Element
Protocol (PCEP) to support Hierarchical PCE procedures.</t> Communication Protocol (PCEP) to support H-PCE procedures.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sec-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>
<!-- [rfced] original text file has section 7.10. NO-PATH VECTOR TLV Bit Flag i The Path Computation Element Communication Protocol (PCEP) provides
n the table of contents but no corresponding section -->
<section title="Introduction" anchor="section-1"><t>
The Path Computation Element communication Protocol (PCEP) provides
a mechanism for Path Computation Elements (PCEs) and Path Computation a mechanism for Path Computation Elements (PCEs) and Path Computation
Clients (PCCs) to exchange requests for path computation and Clients (PCCs) to exchange requests for path computation and
responses that provide computed paths.</t> responses that provide computed paths.</t>
<t>
<t>
The capability to compute the routes of end-to-end inter-domain MPLS The capability to compute the routes of end-to-end inter-domain MPLS
Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs)
is expressed as requirements in <xref target="RFC4105"/> and <xref target="RF is expressed as requirements in <xref target="RFC4105" format="default"/> and
C4216"/>. This <xref target="RFC4216" format="default"/>. This
capability may be realized by a PCE <xref target="RFC4655"/>. The methods fo capability may be realized by a PCE <xref target="RFC4655" format="default"/>
r . The methods for
establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are
documented in <xref target="RFC4726"/>.</t> documented in <xref target="RFC4726" format="default"/>.</t>
<t><xref target="RFC6805" format="default"/> describes a Hierarchical Path
<t> Computation
<xref target="RFC6805"/> describes a Hierarchical PCE (H-PCE) architecture wh Element (H-PCE) architecture that can be used for computing end-to-end
ich can paths for inter-domain MPLS-TE and GMPLS LSPs.</t>
be used for computing end-to-end paths for inter-domain MPLS Traffic <t>In the H-PCE architecture, the parent PCE is used to compute a
Engineering (TE) and GMPLS Label Switched Paths (LSPs).</t> multi-domain path based on the domain connectivity
<t>
Within the hierarchical PCE architecture, the parent PCE is used to
compute a multi-domain path based on the domain connectivity
information. A child PCE may be responsible for single or multiple information. A child PCE may be responsible for single or multiple
domains and is used to compute the intra-domain path based on its domains and is used to compute the intra-domain path based on its
own domain topology information.</t> own domain topology information.</t>
<t>
<t>
The H-PCE end-to-end domain path computation procedure is described The H-PCE end-to-end domain path computation procedure is described
below: below:
<list style="symbols"><t>A path computation client (PCC) sends the inter- </t>
domain path <ul spacing="normal">
computation requests to the child PCE responsible for its domain;</t> <li>A PCC sends the inter-domain
Path Computation Request (PCReq) messages <xref target="RFC5440" format="def
<t>The child PCE forwards the request to the parent PCE;</t> ault"/> to the
child PCE responsible for its domain.</li>
<t>The parent PCE computes the likely domain paths from the ingress <li>The child PCE forwards the request to the parent PCE.</li>
domain to the egress domain;</t> <li>The parent PCE computes the likely domain paths from the ingress
domain to the egress domain.</li>
<t>The parent PCE sends the intra-domain path computation requests <li>The parent PCE sends the intra-domain PCReq messages
(between the domain border nodes) to the child PCEs which are (between the domain border nodes) to the child PCEs that are
responsible for the domains along the domain path;</t> responsible for the domains along the domain path.</li>
<li>The child PCEs return the intra-domain paths to the parent PCE.</li>
<t>The child PCEs return the intra-domain paths to the parent PCE;</t> <li>The parent PCE constructs the end-to-end inter-domain path based
on the intra-domain paths.</li>
<t>The parent PCE constructs the end-to-end inter-domain path based <li>The parent PCE returns the inter-domain path to the child PCE.</li>
on the intra-domain paths;</t> <li>The child PCE forwards the inter-domain path to the PCC.</li>
</ul>
<t>The parent PCE returns the inter-domain path to the child PCE;</t> <t>
<t>The child PCE forwards the inter-domain path to the PCC.</t>
</list>
</t>
<t>
The parent PCE may be requested to provide only the sequence of The parent PCE may be requested to provide only the sequence of
domains to a child PCE so that alternative inter-domain path domains to a child PCE so that alternative inter-domain path
computation procedures, including Per Domain (PD) <xref target="RFC5152"/> an computation procedures, including per-domain (PD) path computation
d <xref target="RFC5152" format="default"/> and Backward-Recursive PCE-Based Co
Backwards Recursive Path Computation (BRPC) <xref target="RFC5441"/>, may be mputation (BRPC)
used.</t> <xref target="RFC5441" format="default"/>, may be used.</t>
<t>
<t>
This document defines the PCEP extensions for the purpose of This document defines the PCEP extensions for the purpose of
implementing Hierarchical PCE procedures, which are described in implementing H-PCE procedures, which are described in
<xref target="RFC6805"/>.</t> <xref target="RFC6805" format="default"/>.</t>
<section anchor="sec-1.1" numbered="true" toc="default">
<section title="Scope" anchor="section-1.1"><t> <name>Scope</name>
The following functions are out of scope of this document: <t>
The following functions are out of scope for this document:
<list style="symbols">
<t>Determination of Destination Domain (section 4.5 of <xref target="RFC6805
"/>):
<list style="symbols">
<t>via a collection of reachability information from child domain;</t>
<t>via requests to the child PCEs to discover if they contain the destinatio
n node;</t>
<t>or any other methods.</t>
</list>
</t>
<t>Parent Traffic Engineering Database (TED) methods (section 4.4 of
<xref target="RFC6805"/>), although suitable mechanisms include:<list styl
e="symbols"><t>YANG-based management interfaces;</t>
<t>BGP-LS <xref target="RFC7752"/>;</t>
<t>Future extension to PCEP (such as <xref target="I-D.dhodylee-pce-pcep-
ls"/>).</t>
</list>
</t>
<t>Learning of Domain connectivity and boundary nodes (BN) addresses,
methods to achieve this function include:<list style="symbols"><t>YANG-bas
ed management interfaces;</t>
<t>BGP-LS <xref target="RFC7752"/>;</t>
<t>Future extension to PCEP (such as <xref target="I-D.dhodylee-pce-pcep-
ls"/>).</t>
</list>
</t>
<t>Stateful PCE Operations (Refer <xref target="I-D.ietf-pce-stateful-hpc
e"/>)</t>
<t>Applicability of hierarchical PCE to large multi-domain
environments.<list style="symbols"><t>The hierarchical relationship model
is described in <xref target="RFC6805"/>.
It is applicable to environments with small groups of domains
where visibility from the ingress LSRs is limited. As highlighted
in <xref target="RFC7399"/> applying the hierarchical PCE model to very
large
groups of domains, such as the Internet, is not considered
feasible or desirable.</t>
</list>
</t>
</list>
</t>
</section>
<section title="Terminology" anchor="section-1.2"><t>
This document uses the terminology defined in <xref target="RFC4655"/>, <xref
target="RFC5440"/>
and the additional terms defined in Section 1.4 of <xref target="RFC6805"/>.<
/t>
</section>
<section title="Requirements Language" anchor="section-1.3"><t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the
y appear in all
capitals, as shown here.</t>
</section>
</section> </t>
<ul spacing="normal">
<li>
<t>Determination of the destination domain (<xref target="RFC6805" s
ectionFormat="of" section="4.5"/>):
</t>
<ul spacing="normal">
<li>via a collection of reachability information from child domain
s,</li>
<li>via requests to the child PCEs to discover if they contain the
destination node, or</li>
<li>via any other methods.</li>
</ul>
</li>
<li>
<t>Parent Traffic Engineering Database (TED) methods (<xref target="
RFC6805" sectionFormat="of" section="4.4"/>), although suitable mechanisms inclu
de:
</t>
<ul spacing="normal">
<li>YANG-based management interfaces.</li>
<li>BGP - Link State (BGP-LS) <xref target="RFC7752" format="defau
lt"/>.</li>
<li>Future extensions to PCEP (for example, see
<xref target="I-D.dhodylee-pce-pcep-ls" format="default"/>).</li>
</ul>
</li>
<li>
<t>Learning of domain connectivity and border node addresses.
Methods to achieve this function include:
</t>
<ul spacing="normal">
<li>YANG-based management interfaces.</li>
<li>BGP-LS <xref target="RFC7752" format="default"/>.</li>
<li>Future extensions to PCEP (for example, see
<xref target="I-D.dhodylee-pce-pcep-ls" format="default"/>).</li>
</ul>
</li>
<li>Stateful PCE operations. (Refer to <xref target="I-D.ietf-pce-stat
eful-hpce" format="default"/>.)</li>
<li>
<t>Applicability of the H-PCE model to large multi-domain
environments.
</t>
<ul spacing="normal">
<li>The hierarchical relationship model is described in <xref targ
et="RFC6805" format="default"/>. It is applicable to environments with small gr
oups
of domains where visibility from the ingress Label Switching Routers
(LSRs) is limited.
As highlighted in <xref target="RFC7399" format="default"/>, applying
the H-PCE model to very large groups of domains, such as the Internet,
is not considered feasible or desirable.</li>
</ul>
</li>
</ul>
</section>
<section anchor="sec-1.2" numbered="true" toc="default">
<name>Terminology</name>
<t>
This document uses the terminology defined in <xref target="RFC4655" format="
default"/> and
<xref target="RFC5440" format="default"/>, and the additional terms defined i
n
<xref target="RFC6805" sectionFormat="of" section="1.4"/>.</t>
</section>
<section anchor="sec-1.3" numbered="true" toc="default">
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.</t>
<section title="Requirements for H-PCE" anchor="section-2"><t> </section>
This section compiles the set of requirements to the PCEP extensions </section>
<section anchor="sec-2" numbered="true" toc="default">
<name>Requirements for the H-PCE Architecture</name>
<t>
This section compiles the set of requirements for the PCEP extensions
to support the H-PCE architecture and procedures. to support the H-PCE architecture and procedures.
<xref target="RFC6805"/> identifies high-level requirements of PCEP extension <xref target="RFC6805" format="default"/> identifies high-level requirements
s for PCEP
required to support the hierarchical PCE model.</t> extensions that are required for supporting the H-PCE model.</t>
<section anchor="sec-2.1" numbered="true" toc="default">
<section title="Path Computation Request" anchor="section-2.1"><t> <name>Path Computation Requests</name>
The Path Computation Request (PCReq) <xref target="RFC5440"/> messages are us <t>
ed by The PCReq messages <xref target="RFC5440" format="default"/> are used by a PC
a PCC or a PCE to make a path computation request to a PCE. In order C or a PCE to make a path computation request to a PCE. In
to achieve the full functionality of the H-PCE procedures, the PCReq order to achieve the full functionality of the H-PCE procedures, the PCReq
message needs to include: message needs to include:
<list style="symbols"><t>Qualification of PCE Requests (Section 4.8.1. of </t>
<xref target="RFC6805"/>);</t> <ul spacing="normal">
<li>Qualification of PCE requests
<t>Multi-domain Objective Functions (OF);</t> (<xref target="RFC6805" sectionFormat="of" section="4.8.1"/>).</li>
<li>Multi-domain Objective Functions (OFs).</li>
<t>Multi-domain Metrics.</t> <li>Multi-domain metrics.</li>
</ul>
</list> <section anchor="sec-2.1.1" numbered="true" toc="default">
</t> <name>Qualification of PCEP Requests</name>
<t>
<section title="Qualification of PCEP Requests" anchor="section-2.1.1"><t As described in <xref target="RFC6805" sectionFormat="of" section="4.8.1"/>,
> the H-PCE
As described in Section 4.8.1 of <xref target="RFC6805"/>, the H-PCE architec architecture introduces new request qualifications, which are as follows:
ture
introduces new request qualifications, which are:
<list style="symbols"><t>The ability for a child PCE to indicate that a pa
th computation
request sent to a parent PCE should be satisfied by a domain
sequence only, that is, not by a full end-to-end path. This allows
the child PCE to initiate a per-domain (PD) <xref target="RFC5152"/> or a
backward recursive path computation (BRPC) <xref target="RFC5441"/>.</t>
<t>As stated in <xref target="RFC6805"/>, Section 4.5, if a PCC knows the
egress
domain, it can supply this information as the path computation
request. The PCC may also want to specify the destination domain
information in a PCEP request, if it is known.</t>
<t>An inter domain path computed by parent PCE should be capable of
disallowing specific domain re-entry.</t>
</list>
</t>
</section>
<section title="Multi-domain Objective Functions" anchor="section-2.1.2">
<t>
For H-PCE inter-domain path computation, there are three new
Objective Functions defined in this document:
<list style="symbols"><t>Minimize the number of Transit Domains (MTD)</t>
<t>Minimize the number of border nodes (MBN)</t>
<t>Minimize the number of Common Transit Domains (MCTD)</t>
</list>
</t>
<t>
The PCC may specify the multi-domain Objective Function code to
use when requesting inter-domain path computation, it may also
include intra-domain OFs, such as Minimum Cost Path (MCP) <xref target="RFC54
41"/>,
which must be considered by participating child PCEs.</t>
</section> </t>
<ul spacing="normal">
<li>The ability for a child PCE to indicate that a
PCReq message sent to a parent PCE should be satisfied by a
domain sequence only -- that is, not by a full end-to-end path. This allows
the child PCE to initiate a PD path computation per <xref target="RFC5152" fo
rmat="default"/> or a BRPC procedure <xref target="RFC5441" format="default"/>.<
/li>
<li>As stated in <xref target="RFC6805" sectionFormat="comma" sectio
n="4.5"/>, if a PCC knows
the egress domain, it can supply this information as part of the PCReq
message. The PCC may also want to specify the destination
domain information in a PCEP request, if it is known.</li>
<li>An inter-domain path computed by a parent PCE should be capable
of
disallowing re-entry into a specified domain.</li>
</ul>
</section>
<section anchor="sec-2.1.2" numbered="true" toc="default">
<name>Multi-domain Objective Functions</name>
<t>For H-PCE inter-domain path computation, there are three new
OFs defined in this document:
<section title="Multi-domain Metrics" anchor="section-2.1.3"><t> </t>
For inter-domain path computation, there are several path metrics of <ul spacing="normal">
<li>Minimize the number of Transit Domains (MTD)</li>
<li>Minimize the number of Border Nodes (MBN)</li>
<li>Minimize the number of Common Transit Domains (MCTD)</li>
</ul>
<t>
The PCC may specify the multi-domain OF code to
use when requesting inter-domain path computation. It may also
include intra-domain OFs, such as Minimum Cost Path (MCP) <xref target="RFC55
41" format="default"/>, which must be considered by participating child
PCEs.</t>
</section>
<section anchor="sec-2.1.3" numbered="true" toc="default">
<name>Multi-domain Metrics</name>
<t>
For inter-domain path computation, there are two path metrics of
interest.</t> interest.</t>
<ul spacing="normal">
<t><list style="symbols"><t>Domain count (number of domains crossed);</t> <li>Domain Count (number of domains crossed).</li>
<li>Border Node Count.</li>
<t>Border Node count.</t> </ul>
<t>
</list>
</t>
<t>
A PCC may be able to limit the number of domains crossed by applying A PCC may be able to limit the number of domains crossed by applying
a limit on these metrics. Details in <xref target="section-3.4"/>.</t> a limit on these metrics. See <xref target="sec-3.4" format="default"/> for
details.</t>
</section> </section>
</section>
</section> <section anchor="sec-2.2" numbered="true" toc="default">
<name>Parent PCE Capability Advertisement</name>
<section title="Parent PCE Capability Advertisement" anchor="section-2.2" <t>
><t> A PCEP speaker (parent PCE or child PCE) that supports and wishes
A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes
to use the procedures described in this document must advertise to use the procedures described in this document must advertise
the fact and negotiate its role with its PCEP peers. It does this this fact and negotiate its role with its PCEP peers. It does this
using the "H-PCE Capability" TLV, described in <xref target="section-3.2.1"/> using the "H-PCE Capability" TLV, as described in <xref target="sec-3.2.1" fo
, in the rmat="default"/>, in the OPEN object <xref target="RFC5440" format="default"/> t
OPEN Object to advertise its support for PCEP extensions for H-PCE o
Capability.</t> advertise its support for PCEP extensions for the H-PCE capability.</t>
<t>
<t>
During the PCEP session establishment procedure, the child PCE needs During the PCEP session establishment procedure, the child PCE needs
to be capable of indicating to the parent PCE whether it requests the to be capable of indicating to the parent PCE whether it requests the
parent PCE capability or not.</t> parent PCE capability or not.</t>
</section>
</section> <section anchor="sec-2.3" numbered="true" toc="default">
<name>PCE Domain Identification</name>
<section title="PCE Domain Identification" anchor="section-2.3"><t> <t>
A PCE domain is a single domain with an associated PCE. Although it A PCE domain is a single domain with an associated PCE, although it
is possible for a PCE to manage multiple domains simultaneously. The is possible for a PCE to manage multiple domains simultaneously. The
PCE domain could be an IGP area or AS.</t> PCE domain could be an IGP area or Autonomous System (AS).</t>
<t>
<t> The PCE domain identifiers <bcp14>MAY</bcp14> be provided during the PCEP ses
The PCE domain identifiers MAY be provided during the PCEP session sion
establishment procedure.</t> establishment procedure.</t>
</section>
<section anchor="sec-2.4" numbered="true" toc="default">
<name>Domain Diversity</name>
<t>"Domain diversity" in the context of a multi-domain environment
is defined in <xref target="RFC6805" format="default"/> and described as fol
lows:
</t>
<blockquote>
A pair of paths are domain-diverse if
they do not transit any of the same domains. A pair of paths that
share a common ingress and egress are domain-diverse if they only
share the same domains at the ingress and egress (the ingress and
egress domains). Domain diversity may be maximized for a pair of
paths by selecting paths that have the smallest number of shared
domains.
</blockquote>
</section> <t>The main motivation behind domain diversity is to avoid
fate-sharing. However, domain diversity may also be requested to avoid
<section title="Domain Diversity" anchor="section-2.4"> specific transit domains due to security, geopolitical, and commercial reasons.
<t>In a multi-domain environment, Domain Diversity is defined in For
<xref target="RFC6805"/> and described as "A pair of paths are domain-diverse if example, a pair of paths should choose different transit ASes because of
they do not transit any of the same domains. A pair of paths that certain policy considerations.</t>
share a common ingress and egress are domain-diverse if they only <t>In the case when full domain diversity could not be achieved, it is
share the same domains at the ingress and egress (the ingress and
egress domains). Domain diversity may be maximized for a pair of
paths by selecting paths that have the smallest number of shared
domains."</t>
<t>The main motivation behind domain diversity is to avoid fate sharing,
but it can also be because of some geo-political reasons and
commercial relationships that would require domain diversity. For
example, a pair of paths should choose different transit Autonomous
System (AS) because of some policy considerations.</t>
<t> In the case when full domain diversity could not be achieved, it is
helpful to minimize the commonly shared domains. Also, it is helpful to minimize the commonly shared domains. Also, it is
interesting to note that other scope of diversity (node, link, SRLG interesting to note that other domain-diversity techniques (node, link,
etc.) can still be applied inside the commonly shared domains.</t> Shared Risk Link Group (SRLG), etc.) can still be applied inside the
commonly shared domains.</t>
</section> </section>
</section>
</section> <section anchor="sec-3" numbered="true" toc="default">
<name>PCEP Extensions</name>
<section title="PCEP Extensions" anchor="section-3"><t> <t>
This section defines extensions to PCEP <xref target="RFC5440"/> to support t This section defines extensions to PCEP <xref target="RFC5440" format="defaul
he t"/> to support
H-PCE procedures.</t> the H-PCE procedures.</t>
<section anchor="sec-3.1" numbered="true" toc="default">
<section title="Applicability to PCC-PCE Communications" anchor="section- <name>Applicability to PCC-PCE Communications</name>
3.1"><t> <t>
Although the extensions defined in this document are intended Although the extensions defined in this document are intended
primarily for use between a child PCE and a parent PCE, they are primarily for use between a child PCE and a parent PCE, they are
also applicable for communications between a PCC and its PCE.</t> also applicable for communications between a PCC and its PCE.</t>
<t>
<t>
Thus, the information that may be encoded in a PCReq can be sent Thus, the information that may be encoded in a PCReq can be sent
from a PCC towards the child PCE. This includes the RP object from a PCC towards the child PCE. This includes the
(<xref target="section-3.3"/>) and the Objective Function (OF) codes and obje Request Parameters (RP) object (<xref target="RFC5440" format="default"/> and
cts <xref target="sec-3.3" format="default"/>), the OF codes
(<xref target="section-3.4"/>). A PCC and a child PCE could also exchange the (<xref target="sec-3.4.1" format="default"/>), and the OF object
capability (<xref target="section-3.2.1"/>) during its session.</t> (<xref target="sec-3.4.2" format="default"/>). A PCC and a child PCE
could also exchange the H-PCE capability (<xref target="sec-3.2.1" format="de
<t> fault"/>) during
its session.</t>
<t>
This allows a PCC to request paths that transit multiple This allows a PCC to request paths that transit multiple
domains utilizing the capabilities defined in this document.</t> domains utilizing the capabilities defined in this document.</t>
</section>
</section> <section anchor="sec-3.2" numbered="true" toc="default">
<name>OPEN Object</name>
<section title="OPEN Object" anchor="section-3.2"><t> <t>
Two new TLVs are defined in this document to be carried within an This document defines two new TLVs to be carried in an
OPEN object. This way, during the PCEP session establishment, the OPEN object. This way, during the PCEP session establishment, the
H-PCE capability and Domain information can be advertised.</t> H-PCE capability and domain information can be advertised.</t>
<section anchor="sec-3.2.1" numbered="true" toc="default">
<section title="H-PCE Capability TLV" anchor="section-3.2.1"><t> <name>H-PCE-CAPABILITY TLV</name>
The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN <t>
Object <xref target="RFC5440"/> to exchange H-PCE capability of PCEP speakers The H-PCE-CAPABILITY TLV is an optional TLV associated with the
.</t> OPEN object <xref target="RFC5440" format="default"/> to exchange the H-PCE c
apability of
<t>Its format is shown in the following figure:</t> PCEP speakers.</t>
<t>Its format is shown in the following figure:</t>
<figure title="H-PCE-CAPABILITY TLV format" anchor="ref-h-pce-capability- <figure anchor="ref-h-pce-capability-tlv-format">
tlv-format"><artwork><![CDATA[ <name>H-PCE-CAPABILITY TLV Format</name>
<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= TBD1 | Length=4 | | Type=13 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |P| | Flags |P|
+---------------------------------------------------------------+ +---------------------------------------------------------------+ ]]></artwork>
]]></artwork> </figure>
</figure>
<t>
The type of the TLV is TBD1 (to be assigned by IANA), and it has a
fixed length of 4 octets.</t>
<t>The value comprises a single field - Flags (32 bits):
<list style="hanging" hangIndent="6"> <t hangText="P (Parent PCE Request
bit):">if set, will signal that the child PCE wishes to use the peer PCE as a pa
rent PCE.
</t>
</list> <t>The type of the TLV is 13, and it has a fixed length of
</t> 4 octets.</t>
<t> <t>The value comprises a single field -- Flags (32 bits):</t>
Unassigned bits MUST be set to 0 on transmission and MUST be ignored <ul empty="true"><li>
<dl newline="true" spacing="normal">
<dt>P (Parent PCE Request bit):</dt>
<dd>If set, will signal that the child
PCE wishes to use the peer PCE as a parent PCE.</dd>
</dl></li></ul>
<t>Unassigned bits <bcp14>MUST</bcp14> be set to 0 on transmission and
<bcp14>MUST</bcp14> be ignored
on receipt.</t> on receipt.</t>
<t>The inclusion of this TLV in an OPEN object indicates that the H-PC
<t> E
The inclusion of this TLV in an OPEN object indicates that the H-PCE extensions are supported by the PCEP speaker. The child PCE <bcp14>MUST</bcp
extensions are supported by the PCEP speaker. The child PCE MUST 14>
include this TLV and set the P flag. The parent PCE MUST include include this TLV and set the P-flag. The parent PCE <bcp14>MUST</bcp14> incl
this TLV and unset the P flag.</t> ude
this TLV and unset the P-flag.</t>
<t> <t>The setting of the P-flag (Parent PCE Request bit) would mean that
The setting of the P flag (parent PCE request bit) would mean that
the PCEP speaker wants the peer to be a parent PCE, so in the case the PCEP speaker wants the peer to be a parent PCE, so in the case
of a PCC to Child-PCE relationship, neither entity would set the P of a PCC-to-child-PCE relationship, neither entity would set the
flag.</t> P-flag.</t>
<t>If both peers attempt to set the P-flag, then the session establish
<t> ment
If both peers attempt to set the P flag then the session <bcp14>MUST</bcp14> fail, and the PCEP speaker <bcp14>MUST</bcp14> respond wi
establishment MUST fail, and the PCEP speaker MUST respond with PCErr th a PCErr message using
message using Error-Type 1: "PCEP Session Establishment Failure" as Error-Type 1 (PCEP session establishment failure) as per <xref target="RFC544
per <xref target="RFC5440"/>.</t> 0" format="default"/>.</t>
<t>If the PCE understands the H-PCE PCReq message but did not
<t> advertise its H-PCE capability, it <bcp14>MUST</bcp14> send a PCErr message w
If the PCE understands the H-PCE path computation request but did not ith
advertise its H-PCE capability, it MUST send a PCErr message with Error-Type=28 (H-PCE Error) and Error-Value=1
Error-Type=TBD8 ("H-PCE error") and Error-Value=1 ("H-PCE Capability not adve (H-PCE Capability not advertised).</t>
rtised").</t> <section anchor="sec-3.2.1.1" numbered="true" toc="default">
<name>Backwards Compatibility</name>
<section title="Backwards Compatibility" anchor="section-3.2.1.1"><t> <t>
Section 7.1 of <xref target="RFC5440"/> requires that "Unrecognized TLVs MUST <xref target="RFC5440" sectionFormat="of" section="7.1"/> specifies the follo
be ignored.</t> wing
requirement: "Unrecognized TLVs <bcp14>MUST</bcp14> be ignored."</t>
<t> <t>The OPEN object <xref target="RFC5440" format="default"/> contain
That means that a PCE that does not support this document but that s the necessary PCEP
receives an Open Message containing an Open Object that includes information between the PCE entities, including session information and PCE
an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to capabilities via TLVs (including if H-PCE is supported). If the PCE does
attempt to establish a PCEP session. It will, however, not include not support this document but receives an Open message containing an OPEN
object that includes an H-PCE-CAPABILITY TLV, it will ignore that TLV
and continue to attempt to establish a PCEP session.
However, it will not include
the TLV in the Open message that it sends, so the H-PCE relationship the TLV in the Open message that it sends, so the H-PCE relationship
will not be created.</t> will not be created.</t>
<t>
<t>
If a PCE does not support the extensions defined in this document but If a PCE does not support the extensions defined in this document but
receives them in a PCEP message (notwithstanding the fact that the receives them in a PCEP message (notwithstanding the fact that the
session was not established as supporting a H-PCE relationship), the session was not established as supporting an H-PCE relationship), the
receiving PCE will ignore the H-PCE related parameters because they receiving PCE will ignore the H-PCE related parameters because they
are all encoded in TLVs within standard PCEP objects.</t> are all encoded in TLVs in standard PCEP objects.</t>
</section>
</section> </section>
<section anchor="sec-3.2.2" numbered="true" toc="default">
</section> <name>Domain-ID TLV</name>
<t>
<section title="Domain-ID TLV" anchor="section-3.2.2"><t>
The Domain-ID TLV, when used in the OPEN object, identifies the The Domain-ID TLV, when used in the OPEN object, identifies the
domains served by the PCE. The child PCE uses this mechanism to domains served by the PCE. The child PCE uses this mechanism to
inform the domain information to the parent PCE.</t> provide the domain information to the parent PCE.</t>
<t>The Domain-ID TLV is defined below:</t>
<t>The Domain-ID TLV is defined below:</t> <figure anchor="ref-domain-id-tlv-format">
<name>Domain-ID TLV Format</name>
<figure title="Domain-ID TLV format" anchor="ref-domain-id-tlv-format"><a <artwork name="" type="" align="left" alt=""><![CDATA[
rtwork><![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= TBD2 | Length | | Type=14 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Type | Reserved | | Domain Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Domain ID // // Domain ID //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> The type of the TLV is 14, and it has a variable Length of the value
The type of the TLV is TBD2 (to be assigned by IANA), and it has a portion. The value part comprises the following:
variable Length of the value portion. The value part comprises:
<list style="hanging">
<t hangText="Domain Type (8 bits):">Indicates the domain type. Four
types of domain are currently defined:
<list style="hanging" hangIndent="9">
<t hangText="Type=1:">the Domain ID field carries a 2-byte AS number.
Padded with trailing zeros to a 4-byte boundary. </t>
<t hangText="Type=2:">the Domain ID field carries a 4-byte AS
number. </t>
<t hangText="Type=3:">the Domain ID field carries a 4-byte OSPF area
ID. </t>
<t hangText="Type=4:">the Domain ID field carries (2-byte Area-Len,
variable length IS-IS area ID). Padded with trailing zeros to
a4-byte boundary. </t>
</list> </t>
<t hangText="Reserved:">Zero at transmission; ignored at the receipt. </t>
<t hangText="Domain ID (variable):">Indicates an IGP Area ID or AS number as
per the Domain Type field. It can be 2 bytes, 4 bytes or
variable length depending on the domain identifier used. It is
padded with trailing zeros to a 4-byte boundary. In case of
IS-IS it includes the Area-Len as well.</t>
</list>
</t> </t>
<ul empty="true"><li><dl newline="false" spacing="normal">
<t> <dt>Domain Type (8 bits):</dt>
In the case a PCE serves more than one domain, multiple Domain-ID <dd><t>Indicates the domain type. Four
TLVs are included for each domain it serves.</t> types of domains are currently defined:</t>
<dl newline="false" spacing="normal" indent="10">
</section> <dt>Type=1:</dt>
<dd>The Domain ID field carries a 2-byte AS number.
</section> Padded with trailing zeros to a 4-byte boundary.</dd>
<dt>Type=2:</dt>
<section title="RP Object" anchor="section-3.3"><section title="H-PCE-FLA <dd>The Domain ID field carries a 4-byte AS number.</dd>
G TLV" anchor="section-3.3.1"><t> <dt>Type=3:</dt>
The H-PCE-FLAG TLV is an optional TLV associated with the RP Object <dd>The Domain ID field carries a 4-byte OSPF area ID.</dd>
<xref target="RFC5440"/> to indicate the H-PCE path computation request and o <dt>Type=4:</dt>
ptions.</t> <dd>The Domain ID field carries a 2-byte Area-Len and a
variable-length IS-IS area ID. Padded with trailing zeros to
<t>Its format is shown in the following figure:</t> a 4-byte boundary.</dd>
</dl>
<figure title="H-PCE-FLAG TLV format" anchor="ref-h-pce-flag-tlv-format"> </dd>
<artwork><![CDATA[ <dt>Reserved:</dt>
<dd>Zero at transmission; ignored on receipt.</dd>
<dt>Domain ID (variable):</dt>
<dd>Indicates an IGP area ID or AS number as
per the Domain Type field. It can be 2 bytes, 4 bytes, or
variable length, depending on the domain identifier used. It is
padded with trailing zeros to a 4-byte boundary. In the case of
IS-IS, it includes the Area-Len as well.</dd>
</dl></li></ul>
<t>In the case where a PCE serves more than one domain, multiple
Domain-ID TLVs are included for each domain it serves.</t>
</section>
</section>
<section anchor="sec-3.3" numbered="true" toc="default">
<name>RP Object</name>
<section anchor="sec-3.3.1" numbered="true" toc="default">
<name>H-PCE-FLAG TLV</name>
<t>
The H-PCE-FLAG TLV is an optional TLV associated with the RP object
<xref target="RFC5440" format="default"/> to indicate the H-PCE PCReq message
and
options.</t>
<t>Its format is shown in the following figure:</t>
<figure anchor="ref-h-pce-flag-tlv-format">
<name>H-PCE-FLAG TLV Format</name>
<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= TBD3 | Length=4 | | Type=15 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |D|S| | Flags |D|S|
+---------------------------------------------------------------+ +---------------------------------------------------------------+ ]]></artwork>
]]></artwork> </figure>
</figure> <t>
<t> The type of the TLV is 15, and it has a fixed length of 4 octets.</t>
The type of the TLV is TBD3 (to be assigned by IANA), and it has a <t> The value comprises a single field -- Flags (32 bits):
fixed length of 4 octets.</t> </t>
<ul empty="true"><li>
<t> The value comprises a single field - Flags (32 bits): <dl newline="true" spacing="normal">
<dt>D (Disallow Domain Re-entry bit):</dt>
<list style="hanging"> <dd>If set, will signal that the
<t hangText="S (Domain Sequence bit):">if set, will signal that the child PCE computed path does not enter a domain more than once.</dd>
wishes to get only the domain sequence in the path computation <dt>S (Domain Sequence bit):</dt>
reply. Refer to Section 3.7 of <xref target="RFC7897"/> for details. </t> <dd>If set, will signal that the child PCE
wishes to get only the domain sequence in the
<t hangText="D (Disallow Domain Re-entry bit):"> if set, will signal that the Path Computation Reply (PCRep) message <xref target="RFC5440" format="default
computed path does not enter a domain more than once.</t> "/>. Refer to
</list></t> <xref target="RFC7897" sectionFormat="of" section="3.7"/> for details.</dd>
</dl></li></ul>
<t> Unassigned bits MUST be set to 0 on transmission and MUST be ignored <t> Unassigned bits <bcp14>MUST</bcp14> be set to 0 on transmission an
d <bcp14>MUST</bcp14> be ignored
on receipt.</t> on receipt.</t>
<t>
<t> The presence of the TLV indicates that the H-PCE-based path
The presence of the TLV indicates that the H-PCE based path
computation is requested as per this document.</t> computation is requested as per this document.</t>
</section>
</section> <section anchor="sec-3.3.2" numbered="true" toc="default">
<name>Domain-ID TLV</name>
<section title="Domain-ID TLV" anchor="section-3.3.2"><t> <t>
The Domain-ID TLV, carried in an OPEN object, is used to indicate a The Domain-ID TLV, carried in an OPEN object, is used to indicate a
(list of) managed domains and is described in <xref target="section-3.3.1"/>. managed domain (or a list of managed domains) and is described in <xref targe
This t="sec-3.2.2" format="default"/>. This TLV, when carried in an RP object,
TLV, when carried in an RP object, indicates the destination domain indicates the destination domain ID. If a PCC knows the egress domain, it
ID. If a PCC knows the egress domain, it can supply this information can supply this information in the PCReq message. <xref target="sec-3.2.2" f
in the PCReq message. The format and procedure of this TLV are ormat="default"/> also defines the format for this TLV and the
defined in <xref target="section-3.2.2"/>.</t> procedure for using it.</t>
<t>If a Domain-ID TLV is used in the RP object and the destination is
<t>If a Domain-id TLV is used in the RP object, and the destination is not actually in the indicated domain, then the parent PCE should
not actually in the indicated domain, then the parent respond with a NO-PATH object and the NO-PATH-VECTOR TLV should be used.
PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV A new bit number is assigned to indicate "Destination is not found in the
should be used. A new bit number is assigned to indicate indicated domain" (see <xref target="sec-3.8" format="default"/>).</t>
"Destination not found in the indicated domain" (see Section 3.7).</t> </section>
</section>
</section> <section anchor="sec-3.4" numbered="true" toc="default">
<name>Objective Functions</name>
</section> <section anchor="sec-3.4.1" numbered="true" toc="default">
<name>OF Codes</name>
<section title="Objective Functions" anchor="section-3.4"><section title= <t><xref target="RFC5541" format="default"/> defines a mechanism to sp
"OF Codes" anchor="section-3.4.1"><t> ecify an
<xref target="RFC5541"/> defines a mechanism to specify an Objective Function OF that is used by a PCE when it computes a path.
that Three new OFs are defined for the H-PCE model; these are:</t>
is used by a PCE when it computes a path. Three new Objective
Functions are defined for H-PCE, these are:
<list style="symbols">
<t> "MTD"
<list style="symbols">
<t>Name: Minimize the number of Transit Domains (MTD)</t>
<t>Objective Function Code - TBD4 (to be assigned by IANA)</t>
<t>Description: Find a path P such that it passes through the
least number of transit domains.</t>
<t>Objective functions are formulated using the following
terminology:
<list style="symbols">
<t>A network comprises a set of N domains {Di, (i=1...N)}.</t>
<t>A path P passes through K unique domains {Dpi,(i=1...K)}.</t>
<t>Find a path P such that the value of K is minimized.</t>
</list>
</t>
</list>
</t>
<t> MBN
<list style="symbols">
<t>Name: Minimize the number of border nodes.</t>
<t>Objective Function Code - TBD5 (to be assigned by IANA)</t>
<t>Description: Find a path P such that it passes through the
least number of border nodes.</t>
<t>Objective functions are formulated using the following
terminology:
<list style="symbols">
<t>A network comprises a set of N links {Li, (i=1...N)}.</t>
<t>A path P is a list of K links {Lpi,(i=1...K)}.</t>
<t>D(Lpi) if a function that determines if the links Lpi and
Lpi+1 belong to different domains, D(Li) = 1 if link Li and
Li+1 belong to different domains, D(Lk) = 0 if link Lk and
Lk+1 belong to the same domain.</t>
<t>The number of border node in a path P is denoted by B(P),
where B(P) = sum{D(Lpi),(i=1...K-1)}.</t>
<t>Find a path P such that B(P) is minimized.</t>
</list>
</t>
</list>
</t>
</list>
</t>
<t>
There is one objective function that applies to a set of
synchronized path computation requests to increase the domain
diversity:
<list style="symbols"><t>MCTD<list style="symbols"><t>Name: Minimize the
number of Common Transit Domains</t>
<t>Objective Function Code - TBD13 (to be assigned by IANA)</t>
<t>Description: Find a set of paths such that it passes through
the least number of common transit domains.<list style="symbols"><t>A n
etwork comprises a set of N domains {Di, (i=1...N)}.</t>
<t>A path P passes through K unique domains {Dpi,(i=1...K)}.</t>
<t>A set of paths {P1...Pm} have L transit domains that are
common to more than one path {Dpi,(i=1...L)}.</t>
<t>Find a set of paths such that the value of L is minimized.</t>
</list>
</t>
</list>
</t>
</list> <ul spacing="normal">
</t> <li>
<t>MTD</t>
<dl spacing="normal">
<dt>Name:</dt><dd>Minimize the number of Transit Domains (MTD)</dd>
<dt>OF code:</dt><dd>12</dd>
<dt>Description:</dt><dd>Find a path P such that it passes through the least
number of transit domains.</dd>
</dl>
</section> <ul>
<li>
<t>OFs are formulated using the following
terminology:</t>
<ul spacing="normal">
<li>A network comprises a set of N domains {Di, (i=1...N)}.</li>
<li>A path P passes through K unique domains {Dpi, (i=1...K)}.</li>
<li>Find a path P such that the value of K is minimized.</li>
</ul>
</li>
</ul>
</li>
</ul>
<section title="OF Object" anchor="section-3.4.2"><t> <ul spacing="normal">
The OF (Objective Function) object <xref target="RFC5541"/> is carried within <li>
a <t>MBN</t>
PCReq message so as to indicate the desired/required objective <dl spacing="normal">
function to be applied by the PCE during path computation. As per <dt>Name:</dt><dd>Minimize the number of Border Nodes (MBN)</dd>
Section 3.2 of <xref target="RFC5541"/> a single OF object may be included in <dt>OF code:</dt><dd>13</dd>
a path <dt>Description:</dt><dd>Find a path P such that it passes through the least
computation request.</t> number of border nodes.</dd>
</dl>
<ul>
<li>
<t>OFs are formulated using the following terminology:</t>
<ul spacing="normal">
<li>A network comprises a set of N links {Li, (i=1...N)}.</li>
<li>A path P is a list of K links {Lpi, (i=1...K)}.</li>
<li>D(Lpi) is a function that determines if the links Lpi and
Lpi+1 belong to different domains. D(Li) = 1 if link Li and
Li+1 belong to different domains; D(Lk) = 0 if link Lk and
Lk+1 belong to the same domain.</li>
<li>The number of border nodes in a path P is denoted by B(P),
where B(P) = sum{D(Lpi), (i=1...K-1)}.</li>
<li>Find a path P such that B(P) is minimized.</li>
</ul>
</li>
</ul>
</li>
</ul>
<t> <t>There is one OF that applies to a set of
The new OF codes described in <xref target="section-3.4.1"/> are applicable a synchronized PCReq messages to increase the domain diversity:
t the </t>
inter-domain path computation performed by the parent PCE, it is <ul spacing="normal">
also necessary to specify the OF code that may be applied for the <li>
<t>MCTD</t>
<dl spacing="normal">
<dt>Name:</dt><dd>Minimize the number of Common Transit Domains (MCTD)</dd>
<dt>OF code:</dt><dd>14</dd>
<dt>Description:</dt><dd>Find a set of paths such that it passes through the
least number of common transit domains.</dd>
</dl>
<ul spacing="normal">
<li>A network comprises a set of N domains {Di, (i=1...N)}.<
/li>
<li>A path P passes through K unique domains {Dpi, (i=1...K)
}.</li>
<li>A set of paths {P1...Pm} has L transit domains that are
common to more than one path {Dpi, (i=1...L)}.</li>
<li>Find a set of paths such that the value of L is minimize
d.</li>
</ul>
</li>
</ul>
</section>
<section anchor="sec-3.4.2" numbered="true" toc="default">
<name>OF Object</name>
<t>
The OF object <xref target="RFC5541" format="default"/> is carried in a
PCReq message so as to indicate the desired/required OF
to be applied by the PCE during path computation. As per
<xref target="RFC5541" sectionFormat="of" section="3.2"/>, a single OF object
may be
included in a PCReq message.</t>
<t>The new OF codes described in <xref target="sec-3.4.1" format="defa
ult"/> are
applicable to the inter-domain path computation performed by the parent
PCE. It is also necessary to specify the OF code that may be applied for the
intra-domain path computation performed by the child PCE. To intra-domain path computation performed by the child PCE. To
accommodate this, the OF-List TLV (described in Section 2.1. of accommodate this, the OF-List TLV (described in <xref target="RFC5541" sectio
<xref target="RFC5541"/>) is included in the OF object as an optional TLV.</t nFormat="of" section="2.1"/>) is included in the OF object as an
> optional TLV.</t>
<t>The OF-List TLV allows the encoding of multiple OF codes. When thi
<t> s TLV
The OF-List TLV allows encoding of multiple OF codes. When this TLV is included inside the OF object, only the first OF code in the
is included inside the OF object, only the first OF-code in the OF-List TLV is considered. The parent PCE <bcp14>MUST</bcp14> use this OF co
OF-LIST TLV is considered. The parent PCE MUST use this OF code in de in
the OF object when sending the intra domain path computation request the OF object when sending the intra-domain PCReq message
to the child PCE. If the OF list TLV is included in the OF Object, to the child PCE. If the OF-List TLV is included in the OF object,
the OF Code inside the OF Object MUST include one of the H-PCE the OF code inside the OF object <bcp14>MUST</bcp14> include one of the H-PCE
Objective Functions defined in this document, the OF Code inside the OFs defined in this document. The OF code inside the
OF List TLV MUST NOT include an H-PCE Objective Function. If this OF-List TLV <bcp14>MUST NOT</bcp14> include an H-PCE OF. If this
condition is not met, the PCEP speaker MUST respond with a PCErr condition is not met, the PCEP speaker <bcp14>MUST</bcp14> respond with a PCE
rr
message with Error-Type=10 (Reception of an invalid object) and message with Error-Type=10 (Reception of an invalid object) and
Error-Value=TBD15 (Incompatible OF codes in H-PCE).</t> Error-Value=23 (Incompatible OF codes in H-PCE).</t>
<t>If the OFs defined in this document are unknown or
<t> unsupported by a PCE, then the procedure as defined in <xref target="RFC5440"
If the Objective Functions defined in this document are unknown or format="default"/> is followed.</t>
unsupported by a PCE, then the procedure as defined in <xref target="RFC5541" </section>
/> </section>
is followed.</t> <section anchor="sec-3.5" numbered="true" toc="default">
<name>METRIC Object</name>
</section> <t>
The METRIC object is defined in <xref target="RFC5440" sectionFormat="of" sec
</section> tion="7.8"/>
and is comprised of the metric-value field, the metric type (the T field),
<section title="Metric Object" anchor="section-3.5"><t> and flags (the Flags field). This document defines the following types for
The METRIC object is defined in Section 7.8 of <xref target="RFC5440"/>, comp the METRIC object for the H-PCE model:
rising
of metric-value, metric-type (T field) and flags. This document
defines the following types for the METRIC object for H-PCE:
<list style="symbols">
<t>T=TBD6: Domain count metric (number of domains crossed);</t>
<t>T=TBD7: Border Node count metric (number of border nodes crossed).</t>
</list>
</t>
<t> </t>
The domain count metric type of the METRIC object encodes the number <ul empty="true"><li>
of domains crossed in the path. The border node count metric type of <dl newline="false" spacing="normal">
<dt>T=20:</dt>
<dd>Domain Count metric (number of domains crossed).</dd>
<dt>T=21:</dt>
<dd>Border Node Count metric (number of border nodes crossed).</dd>
</dl></li></ul>
<t>The Domain Count metric type of the METRIC object encodes the number
of domains crossed in the path. The Border Node Count metric type of
the METRIC object encodes the number of border nodes in the path. If the METRIC object encodes the number of border nodes in the path. If
a domain is re-entered, then domain should be double counted.</t> a domain is re-entered, then the domain should be double counted.</t>
<t>A PCC or child PCE <bcp14>MAY</bcp14> use the metric in a PCReq messa
<t> ge for an
A PCC or child PCE MAY use the metric in a PCReq message for an inter-domain path computation, meeting the requirement for the number of
inter-domain path computation, meeting the number of domain or border domains or border nodes being crossed. As per <xref target="RFC5440" format="
nodes crossing requirement. As per <xref target="RFC5440"/>, in this case, th default"/>, in
e B bit this case, the B-bit is set to suggest a bound (a maximum) for the
is set to suggest a bound (a maximum) for the metric that must not be metric that must not be exceeded for the PCC to consider the computed path
exceeded for the PCC to consider the computed path as acceptable.</t> acceptable.</t>
<t>A PCC or child PCE <bcp14>MAY</bcp14> also use this metric to ask the
<t> PCE to
A PCC or child PCE MAY also use this metric to ask the PCE to
optimize the metric during inter-domain path computation. In this optimize the metric during inter-domain path computation. In this
case, the B flag is cleared, and the C flag is set.</t> case, the B-flag is cleared, and the C-flag is set.</t>
<t>The parent PCE <bcp14>MAY</bcp14> use the metric in a PCRep message a
<t> long with a
The Parent PCE MAY use the metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path that
NO-PATH object in the case where the PCE cannot compute a path meets this constraint. A PCE <bcp14>MAY</bcp14> also use this metric to send
meeting this constraint. A PCE MAY also use this metric to send the the computed
computed end to end metric value in a reply message.</t> end-to-end metric value in a reply message.</t>
</section>
</section> <section anchor="sec-3.6" numbered="true" toc="default">
<name>SVEC Object</name>
<section title="SVEC Object" anchor="section-3.6"><t> <t>
<xref target="RFC5440"/> defines SVEC object which includes flags for the pot <xref target="RFC5440" format="default"/> defines the Synchronization Vector
ential (SVEC) object,
dependency between the set of path computation requests (Link, Node which includes flags for the potential dependency between the set of
and SRLG diverse). This document defines a new flag O for domain PCReq messages (Link, Node, and SRLG diverse). This document defines
diversity.</t> a new flag (the O-bit) for domain diversity.</t>
<t>The following new bit is added to the Flags field:
<t>
The following new bit is added to the Flags field:
<list style="hanging" hangIndent="3"><t hangText="Domain Diverse O-bit-TB
D14:"> when set, this indicates that the computed paths corresponding to the req
uests specified by the following RP objects MUST NOT have any transit domains in
common.</t>
</list>
</t>
<t>
The Domain Diverse O-bit can be used in Hierarchical PCE path
computation to compute synchronized domain diverse end to end path or
diverse domain sequences.</t>
<t>
When domain diverse O bit is set, it is applied to the transit
domains. The other bit in SVEC object (N, L, S etc.) MAY be set and
MUST still be applied in the ingress and egress shared domain.</t>
</section>
<section title="PCEP-ERROR Object" anchor="section-3.7"><section title="H
ierarchy PCE Error-Type" anchor="section-3.7.1"><t>
A new PCEP Error-Type <xref target="RFC5440"/> is used for the H-PCE extensio
n as
defined below:</t>
<figure title="H-PCE error" anchor="ref-h-pce-error"><artwork><![CDATA[ </t>
+------------+-----------------------------------------+ <ul empty="true"><li>
| Error-Type | Meaning | <dl newline="true" spacing="normal">
+------------+-----------------------------------------+ <dt>Domain Diverse O-bit - 18:</dt>
| TBD8 | H-PCE error | <dd>When set, this indicates that the
| | Error-value=1: H-PCE capability | computed paths corresponding to the requests specified by
| | was not advertised | any RP objects that might be provided <bcp14>MUST NOT</bcp14> have any tran
| | Error-value=2: parent PCE capability | sit domains in common.</dd>
| | cannot be provided | </dl></li></ul>
+------------+-----------------------------------------+ <t>The Domain Diverse O-bit can be used in H-PCE path
]]></artwork> computation to compute synchronized domain-diverse end-to-end
</figure> paths or diverse domain sequences.</t>
</section> <t>When the Domain Diverse O-bit is set, it is applied to the transit
domains. The other bit in SVEC object L (Link diverse),
N (Node diverse), S (SRLG diverse), etc.&nbsp;<bcp14>MAY</bcp14> be set
and <bcp14>MUST</bcp14> still be applied in the ingress and egress shared dom
ain.</t>
</section>
<section anchor="sec-3.7" numbered="true" toc="default">
<name>PCEP-ERROR Object</name>
<section anchor="sec-3.7.1" numbered="true" toc="default">
<name>Hierarchical PCE Error-Type</name>
<t>A new PCEP Error-Type <xref target="RFC5440" format="default"/> is
used for the H-PCE
extension as defined below:</t>
</section> <table anchor="tab-1">
<name>H-PCE Error</name>
<thead>
<tr>
<th>Error-Type</th>
<th>Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td align='left'>28</td>
<td align='left'> <ul empty="true" spacing="compact" indent="0">
<li><t>H-PCE Error</t>
<t>Error-Value=1: H-PCE Capability</t>
<t>not advertised</t>
<t>Error-Value=2: Parent PCE Capability</t>
<t>cannot be provided</t></li>
</ul>
</td>
</tr>
</tbody>
</table>
<section title="NO-PATH Object" anchor="section-3.8"><t> </section>
To communicate the reason(s) for not being able to find a multi-domain path o </section>
r domain sequence, the NO-PATH object can be used in the <section anchor="sec-3.8" numbered="true" toc="default">
PCRep message. <xref target="RFC5440"/> defines the format of the NO-PATH ob <name>NO-PATH Object</name>
ject. <t>
The object may contain a NO-PATH-VECTOR TLV to provide additional To communicate the reason(s) for not being able to find a multi-domain
path or domain sequence, the NO-PATH object can be used in the PCRep
message. <xref target="RFC5440" format="default"/> defines the format of the
NO-PATH
object. The object may contain a NO-PATH-VECTOR TLV to provide additional
information about why a path computation has failed.</t> information about why a path computation has failed.</t>
<t>
This document defines four new bit flags in the "NO-PATH-VECTOR TLV Flag
Field" subregistry. These flags are to be carried in the Flags field
in the NO-PATH-VECTOR TLV carried in the NO-PATH object.
</t>
<t> <ul empty="true"><li>
Three new bit flags are defined to be carried in the Flags field in <dl newline="false" spacing="normal" indent="15">
the NO-PATH-VECTOR TLV carried in the NO-PATH Object. <dt>Bit number 22:</dt>
<dd>When set, the parent PCE indicates that the
<list style="hanging"> destination domain is unknown.</dd>
<dt>Bit number 21:</dt>
<t hangText="Bit number TBD9:">When set, the parent PCE indicates that <dd>When set, the parent PCE indicates that one or more
destination domain unknown;</t> child PCEs are unresponsive.</dd>
<dt>Bit number 20:</dt>
<t hangText="Bit number TBD10:">When set, the parent PCE indicates unresponsive <dd>When set, the parent PCE indicates that no
child PCE(s);</t> resources are available in one or more domains.</dd>
<dt>Bit number 19:</dt>
<t hangText="Bit number TBD11:"> When set, the parent PCE indicates no <dd>When set, the parent PCE indicates that
available the destination is not found in the indicated domain.</dd>
resource available in one or more domains.</t> </dl></li></ul>
</section>
<t hangText="Bit number TBD12:"> When set, the parent PCE indicates that </section>
the destination is not found in the indicated domain.</t> <section anchor="sec-4" numbered="true" toc="default">
<name>H-PCE Procedures</name>
</list> <t>The H-PCE path computation procedure is described in <xref target="RFC6
</t> 805" format="default"/>.</t>
</section> <section anchor="sec-4.1" numbered="true" toc="default">
<name>OPEN Procedure between Child PCE and Parent PCE</name>
</section> <t>If a child PCE wants to use the peer PCE as a parent, it <bcp14>MUST<
/bcp14> set the
<section title="H-PCE Procedures" anchor="section-4"><t> P-flag (Parent PCE Request flag) in the H-PCE-CAPABILITY TLV inside the
The H-PCE path computation procedure is described in <xref target="RFC6805"/>.</
t>
<section title="OPEN Procedure between Child PCE and Parent PCE" anchor="
section-4.1"><t>
If a child PCE wants to use the peer PCE as a parent, it MUST set the
P (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the
OPEN object carried in the Open message during the PCEP session OPEN object carried in the Open message during the PCEP session
initialization procedure.</t> initialization procedure.</t>
<t>The child PCE <bcp14>MAY</bcp14> also report its list of domain IDs t
<t> o the parent
The child PCE MAY also report its list of domain IDs, to the parent PCE by specifying them in the Domain-ID TLVs in the OPEN object.
PCE, by specifying them in the Domain-ID TLVs in the OPEN object. This object is carried in the Open message during the PCEP session
This object is carried in the OPEN message during the PCEP session initialization procedure.</t>
initialization procedure</t> <t>The OF codes defined in this document can be carried in the OF-List
TLV of the OPEN object. If the OF-List TLV carries the OF codes, it
<t>
The OF codes defined in this document can be carried in the OF-list
TLV of the OPEN object. If the OF-list TLV carries the OF codes, it
means that the PCE is capable of implementing the corresponding means that the PCE is capable of implementing the corresponding
objective functions. This information can be used for selecting a OFs. This information can be used for selecting a
proper parent PCE when a child PCE wants to get a path that satisfies proper parent PCE when a child PCE wants to get a path that satisfies
a certain Objective Function.</t> a certain OF.</t>
<t>When a child PCE sends a PCReq to a peer PCE that requires parental
<t> activity and the H-PCE-CAPABILITY TLV but these items were not
When a child PCE sends a PCReq to a peer PCE, which requires parental taken into account in the session establishment procedure described
activity and H-PCE capability flags TLV but which were not included above, the peer PCE <bcp14>SHOULD</bcp14> send a PCErr message to the child PCE
in the session establishment procedure described above, the peer PCE and
SHOULD send a PCErr message to the child PCE and MUST specify the <bcp14>MUST</bcp14> specify Error-Type=28 (H-PCE Error) and Error-Value=1
error-type=TBD8 (H-PCE error) and error-value=1 (H-PCE capability was (H-PCE Capability not advertised) in the PCEP-ERROR object.</t>
not advertised) in the PCEP-ERROR object.</t> <t>When a specific child PCE sends a PCReq to a peer PCE that requires
<t>
When a specific child PCE sends a PCReq to a peer PCE, that requires
parental activity and the peer PCE does not want to act as the parent parental activity and the peer PCE does not want to act as the parent
for it, the peer PCE SHOULD send a PCErr message to the child PCE and for it, the peer PCE <bcp14>SHOULD</bcp14> send a PCErr message to the child
MUST specify the error-type=TBD8 (H-PCE error) and error-value=2 PCE and
(Parent PCE capability cannot be provided) in the PCEP-ERROR object.</t> <bcp14>MUST</bcp14> specify Error-Type=28 (H-PCE Error) and Error-Value=2
(Parent PCE Capability cannot be provided) in the PCEP-ERROR object.</t>
</section> </section>
<section anchor="sec-4.2" numbered="true" toc="default">
<section title="Procedure to Obtain Domain Sequence" anchor="section-4.2" <name>Procedure for Obtaining the Domain Sequence</name>
><t> <t>If a child PCE only wants to get the domain sequence for a
If a child PCE only wants to get the domain sequence for a multi-domain path multi-domain path computation from a parent PCE, it can set the Domain
computation from a parent PCE, it can set the Domain Path Path Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq
Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq message. The parent PCE that receives the PCReq message tries to compute
message. The parent PCE which receives the PCReq message tries to a domain sequence for it (instead of the end-to-end path). If the domain
compute a domain sequence for it (instead of the E2E path). If the path computation succeeds, the parent PCE sends a PCRep message that
domain path computation succeeds the parent PCE sends a PCRep message carries the domain sequence in the Explicit Route Object (ERO) to the child
which carries the domain sequence in the Explicit Route Object (ERO) PCE. Refer to <xref target="RFC7897" format="default"/> for more details abou
to the child PCE. Refer to <xref target="RFC7897"/> for more details about d t domain
omain subobjects in the ERO. Otherwise, it sends a PCReq message that carries
sub-objects in the ERO. Otherwise, it sends a PCReq message which the NO-PATH object to the child PCE.</t>
carries the NO-PATH object to the child PCE.</t> </section>
</section>
</section> <section anchor="sec-5" numbered="true" toc="default">
<name>Error Handling</name>
</section> <t>A PCE that is capable of acting as a parent PCE might not be
<section title="Error Handling" anchor="section-5"><t>
A PCE that is capable of acting as a parent PCE might not be
configured or willing to act as the parent for a specific child PCE. configured or willing to act as the parent for a specific child PCE.
This fact could be determined when the child sends a PCReq that When the child PCE sends a PCReq that requires parental activity,
requires parental activity, and could result in a negative response a negative response in the form of a PCEP Error (PCErr) message
in a PCEP Error (PCErr) message and indicate the hierarchy PCE error-type=TBD that includes H-PCE Error-Type=28 (H-PCE Error) and
8 (H-PCE error) and suitable error-value. (<xref target="section-3.7"/>)</t> an applicable Error-Value (<xref target="sec-3.7" format="default"/>) might r
esult.
<t> </t>
Additionally, the parent PCE may fail to find the multi-domain path <t>Additionally, the parent PCE may fail to find the multi-domain path
or domain sequence due to one or more of the following reasons: or domain sequence for one or more of the following reasons:
<list style="symbols"><t>A child PCE cannot find a suitable path to the e
gress;</t>
<t>The parent PCE does not hear from a child PCE for a specified
time;</t>
<t>The Objective Functions specified in the path request cannot be
met.</t>
</list>
</t>
<t>
In this case, the parent PCE MAY need to send a negative path
computation reply specifying the reason. This can be achieved by
including NO-PATH object in the PCRep message. Extension to NO-PATH
object is needed to include the aforementioned reasons described in
<xref target="section-3.7"/>.</t>
</section>
<section title="Manageability Considerations" anchor="section-6"><t>
General PCE and PCEP management considerations are discussed in
<xref target="RFC4655"/> and <xref target="RFC5440"/>. There are additional
management
considerations for H-PCE which are described in <xref target="RFC6805"/>, and
repeated in this section.</t>
<t> </t>
<ul spacing="normal">
<li>A child PCE cannot find a suitable path to the
egress.</li>
<li>The parent PCE does not hear from a child PCE for a specified
time.</li>
<li>The OFs specified in the path request cannot
be met.</li>
</ul>
<t>In this case, the parent PCE <bcp14>MAY</bcp14> need to send a negative
PCRep message
specifying the reason for the failure. This can be
achieved by including the NO-PATH object in the PCRep message.
An extension to the NO-PATH object is needed in order to include the
reasons defined in <xref target="sec-3.8" format="default"/>.</t>
</section>
<section anchor="sec-6" numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>
General PCE and PCEP management/manageability considerations are discussed
in <xref target="RFC4655" format="default"/> and <xref target="RFC5440" forma
t="default"/>. There are
additional management considerations for the H-PCE model; these are
described in <xref target="RFC6805" format="default"/> and repeated in this s
ection.</t>
<t>
The administrative entity responsible for the management of the The administrative entity responsible for the management of the
parent PCEs must be determined for the following cases: parent PCEs must be determined for the following cases:
<list style="symbols"><t>multi-domains (e.g., IGP areas or multiple ASes) </t>
within a single <ul spacing="normal">
service provider network, the management responsibility for the <li>Multiple domains (e.g., IGP areas or multiple
parent PCE would most likely be handled by the service provider,</t> ASes) in a single service provider network. The management responsibility
for the parent PCE would most likely be handled by the service
<t>multiple ASes within different service provider networks, it may provider.</li>
<li>Multiple ASes in different service provider networks. It may
be necessary for a third party to manage the parent PCEs according be necessary for a third party to manage the parent PCEs according
to commercial and policy agreements from each of the participating to commercial and policy agreements from each of the participating
service providers.</t> service providers.</li>
</ul>
</list> <section anchor="sec-6.1" numbered="true" toc="default">
</t> <name>Control of Function and Policy</name>
<t>Control of H-PCE function will need to be carefully managed via
<section title="Control of Function and Policy" anchor="section-6.1"><t> configuration and interaction policies, which may be controlled via a policy
Control and function will need to be carefully managed in an H-PCE module on the H-PCE. A child PCE will need to be configured with the
network. A child PCE will need to be configured with the address of address of its parent PCE. It is expected that there will only be one or
its parent PCE. It is expected that there will only be one or two two parents of any child.</t>
parents of any child.</t> <t>
<t>
The parent PCE also needs to be aware of the child PCEs for all child The parent PCE also needs to be aware of the child PCEs for all child
domains that it can see. This information is most likely to be domains that it can see. This information is most likely to be
configured (as part of the administrative definition of each domain).</t> configured (as part of the administrative definition of each domain).</t>
<t>
<t>
Discovery of the relationships between parent PCEs and child PCEs Discovery of the relationships between parent PCEs and child PCEs
do not form part of the hierarchical PCE architecture. Mechanisms does not form part of the H-PCE architecture. Mechanisms
that rely on advertising or querying PCE locations across domain or that rely on advertising or querying PCE locations across domain or
provider boundaries are undesirable for security, scaling, provider boundaries are undesirable for security, scaling,
commercial, and confidentiality reasons. The specific behaviour of commercial, and confidentiality reasons. The specific behavior of
the child and parent PCE are described in the following sub-sections.</t> the child and parent PCEs is described in the following subsections.</t>
<section anchor="sec-6.1.1" numbered="true" toc="default">
<section title="Child PCE" anchor="section-6.1.1"><t> <name>Child PCE</name>
<t>
Support of the hierarchical procedure will be controlled by the Support of the hierarchical procedure will be controlled by the
management organization responsible for each child PCE. A child PCE management organization responsible for each child PCE. A child PCE
must be configured with the address of its parent PCE in order for it must be configured with the address of its parent PCE in order for it
to interact with its parent PCE. The child PCE must also be to interact with its parent PCE. The child PCE must also be
authorized to peer with the parent PCE.</t> authorized to peer with the parent PCE.</t>
</section>
</section> <section anchor="sec-6.1.2" numbered="true" toc="default">
<name>Parent PCE</name>
<section title="Parent PCE" anchor="section-6.1.2"><t> <t>
The parent PCE MUST only accept path computation requests from The parent PCE <bcp14>MUST</bcp14> only accept PCReq messages from
authorized child PCEs. If a parent PCE receives requests from an authorized child PCEs. If a parent PCE receives requests from an
unauthorized child PCE, the request SHOULD be dropped. This means unauthorized child PCE, the request <bcp14>SHOULD</bcp14> be dropped. This m
that a parent PCE MUST be able to cryptographically authenticate eans
that a parent PCE <bcp14>MUST</bcp14> be able to cryptographically authentica
te
requests from child PCEs.</t> requests from child PCEs.</t>
<t>Multi-party shared key authentication schemes are not recommended f
<t> or
Multi-party shared key authentication schemes are not recommended for inter-domain relationships because of (1) the potential for
inter-domain relationships because of the potential for impersonation impersonation and repudiation and (2) operational difficulties should
and repudiation and for the operational difficulties should
revocation be required.</t> revocation be required.</t>
<t>The choice of authentication schemes to employ may be left to
<t> implementers of the H-PCE architecture and are not discussed further in
The choice of authentication schemes to employ may be left to this document.</t>
implementers of H-PCE and are not discussed further in this document.</t> </section>
<section anchor="sec-6.1.3" numbered="true" toc="default">
</section> <name>Policy Control</name>
<t>It may be necessary to maintain H-PCE policy <xref target="RFC5394"
<section title="Policy Control" anchor="section-6.1.3"><t> format="default"/>
It may be necessary to maintain a policy module on the parent PCE via a policy control module on the parent PCE.
<xref target="RFC5394"/>. This would allow the parent PCE to apply commercia This would allow the parent PCE to apply
lly commercially relevant constraints such as SLAs, security, peering
relevant constraints such as SLAs, security, peering preferences, and preferences, and monetary costs.</t>
monetary costs.</t> <t>
<t>
It may also be necessary for the parent PCE to limit the It may also be necessary for the parent PCE to limit the
end-to-end path selection by including or excluding specific domains end-to-end path selection by including or excluding specific domains
based on commercial relationships, security implications, and based on commercial relationships, security implications, and
reliability.</t> reliability.</t>
</section>
</section>
<section anchor="sec-6.2" numbered="true" toc="default">
<name>Information and Data Models</name>
<t><xref target="RFC7420" format="default"/> provides a MIB module for P
CEP and describes
managed objects for the modeling of PCEP communication. A
YANG module for PCEP has also been proposed <xref target="PCEP-YANG" format="
default"/>.</t>
<t>An H-PCE MIB module or an additional data model will also be
required for reporting parent PCE and child PCE information, including:
</section> </t>
<ul spacing="normal">
</section> <li>parent PCE configuration and status,</li>
<li>child PCE configuration and information,</li>
<section title="Information and Data Models" anchor="section-6.2"><t> <li>notifications to indicate session changes between parent PCEs and
A MIB module for PCEP was published as RFC 7420 <xref target="RFC7420"/> that child PCEs, and</li>
describes managed objects for modelling of PCEP communication. A <li>notification of parent PCE TED updates and changes.</li>
YANG module for PCEP has also been proposed <xref target="I-D.ietf-pce-pcep-y </ul>
ang"/>.</t> </section>
<section anchor="sec-6.3" numbered="true" toc="default">
<t> <name>Liveness Detection and Monitoring</name>
Additionally, H-PCE MIB module, or additional data model, will be <t>The hierarchical procedure requires interaction with multiple PCEs.
required to report parent PCE and child PCE information, including:
<list style="symbols"><t>parent PCE configuration and status,</t>
<t>child PCE configuration and information,</t>
<t>notifications to indicate session changes between parent PCEs and
child PCEs, and</t>
<t>notification of parent PCE TED updates and changes.</t>
</list>
</t>
</section>
<section title="Liveness Detection and Monitoring" anchor="section-6.3"><
t>
The hierarchical procedure requires interaction with multiple PCEs.
Once a child PCE requests an end-to-end path, a sequence of events Once a child PCE requests an end-to-end path, a sequence of events
occurs that requires interaction between the parent PCE and each occurs that requires interaction between the parent PCE and each
child PCE. If a child PCE is not operational, and an alternate child PCE. If a child PCE is not operational and an alternate
transit domain is not available, then the failure must be reported.</t> transit domain is not available, then the failure must be reported.</t>
</section>
</section> <section anchor="sec-6.4" numbered="true" toc="default">
<name>Verifying Correct Operations</name>
<section title="Verify Correct Operations" anchor="section-6.4"><t> <t>
Verifying the correct operation of a parent PCE can be performed by Verifying the correct operation of a parent PCE can be performed by
monitoring a set of parameters. The parent PCE implementation should monitoring a set of parameters. The parent PCE implementation should
provide the following parameters monitored at the parent PCE: provide the following parameters monitored at the parent PCE:
<list style="symbols"><t>number of child PCE requests,</t> </t>
<ul spacing="normal">
<t>number of successful hierarchical PCE procedures completions on a <li>number of child PCE requests,</li>
per-PCE-peer basis,</t> <li>number of successful H-PCE procedure completions on a
per-PCE-peer basis,</li>
<t>number of hierarchical PCE procedure completion failures on a per-PCE- <li>number of H-PCE procedure-completion failures on a per-PCE-peer ba
peer basis, and</t> sis,
and</li>
<t>number of hierarchical PCE procedure requests from unauthorized <li>number of H-PCE procedure requests from unauthorized child PCEs.</
child PCEs.</t> li>
</ul>
</list> </section>
</t> <section anchor="sec-6.5" numbered="true" toc="default">
<name>Requirements on Other Protocols</name>
</section> <t>
<section title="Requirements On Other Protocols" anchor="section-6.5"><t>
Mechanisms defined in this document do not imply any new requirements Mechanisms defined in this document do not imply any new requirements
on other protocols.</t> on other protocols.</t>
</section>
</section> <section anchor="sec-6.6" numbered="true" toc="default">
<name>Impact on Network Operations</name>
<section title="Impact On Network Operations" anchor="section-6.6"><t> <t>
The hierarchical PCE procedure is a multiple-PCE path computation The H-PCE procedure is a multiple-PCE path computation
scheme. Subsequent requests to and from the child and parent PCEs do scheme. Subsequent requests to and from the child and parent PCEs do
not differ from other path computation requests and should not have not differ from other path computation requests and should not have
any significant impact on network operations.</t> any significant impact on network operations.</t>
</section>
</section> </section>
<section anchor="sec-7" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>
<section title="IANA Considerations" anchor="section-7"><t>
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry. This document requests IANA actions to allocate code registry. IANA has allocated code points for the protocol elements
points for the protocol elements defined in this document.</t> defined in this document.</t>
<section anchor="sec-7.1" numbered="true" toc="default">
<section title="PCEP TLV Type Indicators" anchor="section-7.1"><t> <name>PCEP TLV Type Indicators</name>
IANA Manages the PCEP TLV code point registry (see <xref target="RFC5440"/>). <t>IANA maintains the "PCEP TLV Type Indicators"
This subregistry (see <xref target="RFC5440" format="default"/>) within the
is maintained as the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.</t>
"Path Computation Element Protocol (PCEP) Numbers" registry.</t> <t>IANA has allocated the following three new PCEP TLVs:</t>
<t>
This document defines three new PCEP TLVs. IANA is requested to make
the following allocation:</t>
<figure><artwork><![CDATA[
Type TLV name References
-----------------------------------------------
TBD1 H-PCE-CAPABILITY TLV This I-D
TBD2 Domain-ID TLV This I-D
TBD3 H-PCE-FLAG TLV This I-D
]]></artwork>
</figure>
</section>
<section title="H-PCE-CAPABILITY TLV Flags" anchor="section-7.2"><t>
This document requests that a new sub-registry, named "H-PCE-CAPABILITY TLV F
lag Field", is created within the "Path Computation Element Protocol (PCEP) Numb
ers" registry to manage the Flag field in
the H-PCE-CAPABILITY TLV of the PCEP OPEN object.</t>
<t>
New values are to be assigned by Standards Action <xref target="RFC8126"/>.
Each
bit should be tracked with the following qualities:
<list style="symbols"><t>Bit number (counting from bit 0 as the most sign
ificant bit)</t>
<t>Capability description</t>
<t>Defining RFC</t>
</list>
</t>
<t>The following values are defined in this document:</t>
<figure><artwork><![CDATA[
Bit Description Reference
--------------------------------------------------
31 P (Parent PCE Request bit) This I.D.
]]></artwork>
</figure>
</section>
<section title="Domain-ID TLV Domain type" anchor="section-7.3"><t>
This document requests that a new sub-registry, named "Domain-ID TLV Domain t
ype", is created within the "Path Computation Element Protocol (PCEP) Numbers" r
egistry to manage the Domain-Type field of
the Domain-ID TLV. The allocation policy for this new sub-registry is
IETF Review <xref target="RFC8126"/>.</t>
<figure><artwork><![CDATA[
Value Meaning
-----------------------------------------------
1 2-byte AS number
2 4-byte AS number
3 4-byte OSPF area ID
4 Variable length IS-IS area ID
]]></artwork>
</figure>
</section>
<section title="H-PCE-FLAG TLV Flags" anchor="section-7.4"><t>
This document requests that a new sub-registry, named "H-PCE-FLAG TLV Flag Fi
eld", is created within the "Path Computation Element Protocol (PCEP) Numbers" r
egistry to manage the Flag field in the H-PCE-FLAGS TLV of the PCEP RP object.
New values are to be assigned
by Standards Action <xref target="RFC8126"/>. Each bit should be tracked wit
h the
following qualities:
<list style="symbols"><t>Bit number (counting from bit 0 as the most sign
ificant bit)</t>
<t>Capability description</t>
<t>Defining RFC</t> <table anchor="tab-2">
</list> <name>New PCEP TLVs</name>
</t> <thead>
<tr>
<th>Type</th>
<th>TLV Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>13</td>
<td>H-PCE-CAPABILITY</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>14</td>
<td>Domain-ID</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>15</td>
<td>H-PCE-FLAG</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec-7.2" numbered="true" toc="default">
<name>H-PCE-CAPABILITY TLV Flags</name>
<t>IANA has created the "H-PCE-CAPABILITY TLV Flag Field" subregistry wi
thin the
"Path Computation Element Protocol (PCEP) Numbers" registry to manage
the Flag field in the H-PCE-CAPABILITY TLV of the
PCEP OPEN object.</t>
<t>New values are assigned by Standards Action <xref target="RFC8126"
format="default"/>. Each registered bit should include the following inf
ormation:
</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 following value is defined in this document:</t>
<table anchor="tab-3">
<name>Parent PCE Request Bit</name>
<thead>
<tr>
<th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>31</td>
<td>P (Parent PCE Request bit)</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec-7.3" numbered="true" toc="default">
<name>Domain-ID TLV Domain Type</name>
<t>
IANA has created the "Domain-ID TLV Domain Type" subregistry
within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the Domain Type field of
the Domain-ID TLV. The allocation policy for this new subregistry is
IETF Review <xref target="RFC8126" format="default"/>.</t>
<t>The following values are defined in this document:</t> <t>The following values are defined in this document:</t>
<figure><artwork><![CDATA[ <table anchor="tab-4">
Bit Description Reference <name>Parameters for Domain-ID TLV Domain Type</name>
----------------------------------------------- <thead>
31 S (Domain This I.D. <tr>
Sequence bit) <th>Value</th>
30 D (Disallow Domain This I.D. <th>Meaning</th>
Re-entry bit) </tr>
]]></artwork> </thead>
</figure> <tbody>
</section> <tr>
<td>0</td>
<section title="OF Codes" anchor="section-7.5"><t> <td>Reserved</td>
IANA maintains a registry of Objective Function (described in </tr>
<xref target="RFC5541"/>) at the sub-registry "Objective Function". Three ne <tr>
w <td>1</td>
Objective Functions have been defined in this document.</t> <td>2-byte AS number</td>
</tr>
<t>IANA is requested to make the following allocations:</t> <tr>
<td>2</td>
<figure><artwork><![CDATA[ <td>4-byte AS number</td>
Code </tr>
Point Name Reference <tr>
------------------------------------------------------ <td>3</td>
TBD4 Minimum number of Transit This I.D. <td>4-byte OSPF area ID</td>
Domains (MTD) </tr>
TBD5 Minimize number of Border This I.D. <tr>
Nodes (MBN) <td>4</td>
TBD13 Minimize the number of This I.D. <td>Variable-length IS-IS area ID</td>
Common Transit Domains </tr>
(MCTD) <tr>
]]></artwork> <td>5-255</td>
</figure> <td>Unassigned</td>
</section> </tr>
</tbody>
<section title="METRIC Types" anchor="section-7.6"><t> </table>
IANA maintains one sub-registry for "METRIC object T field". Two new
metric types are defined in this document for the METRIC object
(specified in <xref target="RFC5440"/>). </t>
<t>IANA is requested to make the following allocations:</t>
<figure><artwork><![CDATA[
Value Description Reference
----------------------------------------------------------
TBD6 Domain Count metric This I.D.
TBD7 Border Node Count metric This I.D.
]]></artwork>
</figure>
</section>
<section title="New PCEP Error-Types and Values" anchor="section-7.7"><t>
IANA maintains a registry of Error-Types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and
Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" r
egistry.</t>
<t>IANA is requested to make the following allocations:"</t>
<!-- [rfced] Please review the table alignment of text to column headers -->
<figure><artwork><![CDATA[
Error-Type Meaning and error values Reference
------------------------------------------------------
TBD8 H-PCE Error This I.D.
Error-value=1 H-PCE
Capability not advertised
Error-value=2 Parent PCE
Capability cannot be provided
10 Reception of an invalid object [RFC5440] </section>
<section anchor="sec-7.4" numbered="true" toc="default">
<name>H-PCE-FLAG TLV Flags</name>
<t>
IANA has created the "H-PCE-FLAG TLV Flag Field" subregistry within the
"Path Computation Element Protocol (PCEP) Numbers" registry to manage the Fla
g field in the
H-PCE-FLAG TLV of the PCEP RP object.
New values are to be assigned by Standards Action <xref target="RFC8126"
format="default"/>. Each registered bit should include the following
information:
</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 following values are defined in this document:</t>
Error-value=TBD15: Incompatible This I.D. <table anchor="tab-5">
OF codes in H-PCE <name>New H-PCE-FLAG TLV Flag Field Entries</name>
<thead>
<tr>
<th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>30</td>
<td>D (Disallow Domain Re-entry bit)</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>31</td>
<td>S (Domain Sequence bit)</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec-7.5" numbered="true" toc="default">
<name>OF Codes</name>
<t>
IANA maintains a list of OFs (described in
<xref target="RFC5541" format="default"/>) in the "Objective Function"
subregistry within the "Path Computation Element Protocol (PCEP) Numbers" reg
istry.</t>
<t>IANA has allocated the following OFs:</t>
<table anchor="tab-6">
<name>New OF Codes</name>
<thead>
<tr>
<th>Code Point</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>12</td>
<td>Minimize the number of Transit Domains (MTD)</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>13</td>
<td>Minimize the number of Border Nodes (MBN)</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>14</td>
<td>Minimize the number of Common Transit Domains (MCTD)</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
]]></artwork> </section>
</figure> <section anchor="sec-7.6" numbered="true" toc="default">
</section> <name>METRIC Object Types</name>
<t>
IANA maintains the "METRIC Object T Field" subregistry <xref
target="RFC5440" format="default"/> within the "Path
Computation Element Protocol (PCEP) Numbers" registry. </t>
<t>The following two new metric types for the
METRIC object are defined in this document:</t>
<section title="New NO-PATH-VECTOR TLV Bit Flag" anchor="section-7.8"><t> <table anchor="tab-7">
IANA maintains a sub-registry "NO-PATH-VECTOR TLV Flag Field" of <name>New METRIC Object Types</name>
bit flags carried in the PCEP NO-PATH-VECTOR TLV in the PCEP NO-PATH <thead>
object as defined in <xref target="RFC5440"/>. IANA is requested to assign th <tr>
ree <th>Value</th>
new bit flag as follows:</t> <th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>20</td>
<td>Domain Count metric</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>21</td>
<td>Border Node Count metric</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
<figure><artwork><![CDATA[ </section>
Bit Number Name Flag Reference <section anchor="sec-7.7" numbered="true" toc="default">
------------------------------------------------------ <name>New PCEP Error-Types and Values</name>
TBD9 Destination Domain unknown This I.D. <t>IANA maintains a list of Error-Types and Error-Values for use in
TBD10 Unresponsive child PCE(s) This I.D. PCEP messages. This list is maintained in the
TBD11 No available resource in This I.D. "PCEP-ERROR Object Error Types and Values" subregistry within the "Path
one or more domain Computation Element Protocol (PCEP) Numbers" registry.</t>
TBD12 Destination is not found This I.D. <t>IANA has allocated the following:</t>
in the indicated domain.
]]></artwork>
</figure>
</section>
<section title="SVEC Flag" anchor="section-7.9"><t> <table anchor="tab-8">
IANA maintains a sub-registry "SVEC Object Flag Field" of bit flags <name>New PCEP Error-Types and Values</name>
carried in the PCEP SVEC object as defined in <xref target="RFC5440"/>. IANA <thead>
is <tr>
requested to assign one new bit flag as follows:</t> <th>Error-Type</th>
<th>Meaning and Error Values</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align='left'>28</td>
<td align='left'><ul empty="true" spacing="compact">
<li><t>H-PCE Error</t>
<t>Error-Value=1: H-PCE Capability</t>
<t>not advertised</t>
<t>Error-Value=2: Parent PCE Capability</t>
<t>cannot be provided</t>
</li>
</ul>
</td>
<td>RFC 8685</td>
</tr>
<tr>
<td align='left'>10</td>
<td align='left'> <ul empty="true" spacing="compact" indent="0">
<li><t>Reception of an invalid object</t>
<t>Error-Value=23: Incompatible OF codes</t>
<t>in H-PCE</t></li>
</ul>
</td>
<td><t>RFC 5440</t>
<t>RFC 8685</t></td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec-7.8" numbered="true" toc="default">
<name>New NO-PATH-VECTOR TLV Bit Flag</name>
<t>IANA maintains the "NO-PATH-VECTOR TLV Flag Field" subregistry,
which contains a list of bit flags carried in the PCEP NO-PATH-VECTOR TLV
in the PCEP NO-PATH object as defined in <xref target="RFC5440"
format="default"/>.</t>
<t>IANA has allocated the following four new bit flags:</t>
<figure><artwork><![CDATA[ <table anchor="tab-9">
Bit Number Name Flag Reference <name>PCEP NO-PATH Object Flags</name>
------------------------------------------------------ <thead>
TBD14 Domain Diverse O-bit This I.D. <tr>
]]></artwork> <th>Bit Number</th>
</figure> <th>Description</th>
</section> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>22</td>
<td>Destination domain unknown</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>21</td>
<td>Unresponsive child PCE(s)</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>20</td>
<td>No available resource in one or more domains</td>
<td>RFC 8685</td>
</tr>
<tr>
<td>19</td>
<td>Destination is not found in the indicated domain</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec-7.9" numbered="true" toc="default">
<name>SVEC Flag</name>
<t>IANA maintains the "SVEC Object Flag Field" subregistry, which
contains a list of bit flags carried in the PCEP SVEC object as defined
in <xref target="RFC5440" format="default"/>. </t>
<t>IANA has allocated the following new bit flag:</t>
<section title="Security Considerations" anchor="section-8"><t> <table anchor="tab-10">
The hierarchical PCE procedure relies on PCEP and inherits the <name>Domain Diverse O-Bit</name>
security considerations defined in <xref target="RFC5440"/>. As PCEP operate <thead>
s over <tr>
TCP, it may also make use of TCP security mechanisms, such as TCP <th>Bit Number</th>
Authentication Option (TCP-AO) <xref target="RFC5925"/> or Transport Layer <th>Description</th>
Security (TLS) <xref target="RFC8253"/>.</t> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>18</td>
<td>Domain Diverse O-bit</td>
<td>RFC 8685</td>
</tr>
</tbody>
</table>
<t> </section>
</section>
<section anchor="sec-8" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The H-PCE procedure relies on PCEP and inherits the
security considerations defined in <xref target="RFC5440" format="default"/>.
As PCEP
operates over TCP, it may also make use of TCP security mechanisms, such as
the TCP Authentication Option (TCP-AO) <xref target="RFC5925" format="default
"/> or
Transport Layer Security (TLS) <xref target="RFC8253" format="default"/>
<xref target="RFC8446" format="default"/>.</t>
<t>
Any multi-domain operation necessarily involves the exchange of Any multi-domain operation necessarily involves the exchange of
information across domain boundaries. This may represent a information across domain boundaries. This may represent a
significant security and confidentiality risk especially when the significant security and confidentiality risk, especially when the
child domains are controlled by different commercial concerns. PCEP child domains are controlled by different commercial concerns. PCEP
allows individual PCEs to maintain the confidentiality of their allows individual PCEs to maintain the confidentiality of their
domain path information using path-keys <xref target="RFC5520"/>, and the H-P domain path information using path-keys <xref target="RFC5520" format="defaul
CE t"/>, and the
architecture is specifically designed to enable as much isolation of H-PCE architecture is specifically designed to enable as much
domain topology and capabilities information as is possible.</t> isolation of information related to domain topology and capabilities
as possible.</t>
<t> <t>
For further considerations of the security issues related to inter-AS For further considerations regarding the security issues related to
path computation, see <xref target="RFC5376"/>.</t> inter-AS path computation, see <xref target="RFC5376" format="default"/>.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.ietf-pce-stateful-hpce" to="STATEFUL-HPCE"/>
<displayreference target="I-D.dhodylee-pce-pcep-ls" to="PCEP-LS"/>
<!-- [rfced] Should contributors authors be in an artwork tag?? --> <references>
<name>References</name>
<references>
<name>Normative References</name>
<section title="Contributing Authors" anchor="section-9"><figure><artwork <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
><![CDATA[ xml"/>
Xian Zhang <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.
Huawei xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4105.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4216.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4726.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5152.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5376.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5394.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5520.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5441.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6805.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7399.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7897.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
xml"/>
EMail: zhang.xian@huawei.com <!-- draft-ietf-pce-pcep-yang; "long way" because of role="editor" -->
<reference anchor='PCEP-YANG' target="https://tools.ietf.org/html/draft-ietf-pce
-pcep-yang-13">
<front>
<title>A YANG Data Model for Path Computation Element Communications Protocol (P
CEP)</title>
<author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
<organization />
</author>
<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
<organization />
</author>
<author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
<organization />
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization />
</author>
<date month='October' day='31' year='2019' />
</front>
<seriesInfo name='Work in Progress, Internet-Draft,' value='draft-ietf-pce-pcep-
yang-13' />
</reference>
Dhruv Dhody <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
Huawei Technologies -pce-stateful-hpce.xml"/>
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.dhod
]]></artwork> ylee-pce-pcep-ls.xml"/>
</figure>
</section>
<section title="Acknowledgements" anchor="section-10"><t> </references>
The authors would like to thank Mike McBride, Kyle Rose, Roni Even </references>
for their detailed review, comments and suggestions which helped <section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors would like to thank Mike McBride, Kyle Rose, and Roni Even
for their detailed review, comments, and suggestions, which helped
improve this document.</t> improve this document.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The following people contributed substantially to the content of this
document and should be considered coauthors:</t>
</section> <artwork name="" type="" align="left" alt=""><![CDATA[
Xian Zhang
</middle> Huawei
Email: zhang.xian@huawei.com ]]></artwork>
<back>
<references title="Normative References">
&RFC2119;
&RFC5440;
&RFC5541;
&RFC8174;
</references>
<references title="Informative References">
&RFC4105;
&RFC4216;
&RFC4655;
&RFC4726;
&RFC5152;
&RFC5376;
&RFC5394;
&RFC5520;
&RFC5441;
&RFC5925;
&RFC6805;
&RFC7399;
&RFC7420;
&RFC7752;
&RFC7897;
&RFC8126;
&RFC8253;
&I-D.ietf-pce-pcep-yang;
&I-D.ietf-pce-stateful-hpce;
&I-D.dhodylee-pce-pcep-ls;
</references>
</back>
</rfc> <artwork name="" type="" align="left" alt=""><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com ]]></artwork>
</section>
</back>
</rfc>
 End of changes. 112 change blocks. 
1318 lines changed or deleted 1399 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/