rfc8694xml2.original.xml   rfc8694.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3209.xml">
<!ENTITY RFC3473 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3473.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 RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5440.xml">
<!ENTITY RFC5441 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5441.xml">
<!ENTITY RFC5520 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5520.xml">
<!ENTITY RFC5541 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5541.xml">
<!ENTITY RFC6805 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6805.xml">
<!ENTITY RFC3060 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3060.xml">
<!ENTITY RFC3460 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3460.xml">
<!ENTITY RFC3630 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3630.xml">
<!ENTITY RFC4090 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4090.xml">
<!ENTITY RFC4203 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4203.xml">
<!ENTITY RFC4920 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4920.xml">
<!ENTITY RFC5088 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5088.xml">
<!ENTITY RFC5089 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5089.xml">
<!ENTITY RFC5305 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5305.xml">
<!ENTITY RFC5307 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5307.xml">
<!ENTITY RFC5316 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5316.xml">
<!ENTITY RFC5392 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5392.xml">
<!ENTITY RFC5394 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5394.xml">
<!ENTITY RFC5521 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5521.xml">
<!ENTITY RFC5886 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5886.xml">
<!ENTITY RFC6007 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6007.xml">
<!ENTITY RFC6952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6952.xml">
<!ENTITY RFC7334 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7334.xml">
<!ENTITY RFC7420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7420.xml">
<!ENTITY RFC7525 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7525.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 RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC8453 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8453.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-pce-inter-area-as-applicability-0
8" category="info" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2019-10-01T23:58:47Z -->
<?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="Applicability of the Path Computation El">Applicability of
the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic
Engineering</title>
<author fullname="D. King" initials="D." surname="King">
<organization>Old Dog Consulting</organization>
</author>
<author fullname="H. Zheng" initials="H." surname="Zheng"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<organization>Huawei Technologies</organization>
</author>
<date month="September" year="2019"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<workgroup>PCE Working Group</workgroup> info" consensus="true" docName="draft-ietf-pce-inter-area-as-applicability-08" n
<abstract><t> umber="8694" ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="f
The Path Computation Element (PCE) may be used for computing services alse" symRefs="true" tocInclude="true" version="3">
that traverse multi-area and multi-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.</t>
<t> <!-- xml2rfc v2v3 conversion 2.31.0 -->
<!-- Generated by id2xml 1.5.0 on 2019-10-01T23:58:47Z -->
<front>
<title abbrev="Applicability of of PCE to MPLS and GMPLS">Applicability of t
he Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic En
gineering</title>
<seriesInfo name="RFC" value="8694"/>
<author fullname="Daniel King" initials="D." surname="King">
<organization>Old Dog Consulting</organization>
<address>
<email>daniel@olddog.co.uk</email>
</address>
</author>
<author fullname="郑好棉" asciiFullname="Haomian Zheng">
<organization ascii="Huawei Technologies">华为技术有限公司</organization>
<address>
<postal>
<street ascii="H1, Huawei Xiliu Beipo Village, Songshan Lake">松山湖华为溪流背
坡村H1</street>
<city ascii="Dongguan">东莞</city>
<region ascii="Guangdong">广东</region>
<code>523808</code>
<country ascii="China">中国</country>
</postal>
<email>zhenghaomian@huawei.com</email>
</address>
</author>
<date month="December" year="2019"/>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>
The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotoco
l Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.</t>
<t>
This document examines the applicability of the PCE architecture, This document examines the applicability of the PCE architecture,
protocols, and protocol extensions for computing multi-area and protocols, and protocol extensions for computing multi-area and
multi-AS paths in MPLS and GMPLS networks.</t> multi-AS paths in MPLS and GMPLS networks.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
Computing paths across large multi-domain environments may Computing paths across large multi-domain environments may
require special computational components and cooperation between require special computational components and cooperation between
entities in different domains capable of complex path computation.</t> entities in different domains capable of complex path computation.</t>
<t>
<t> Issues that may exist when routing in multi-domain networks include the
Issues that may exist when routing in multi-domain networks include:</t> following:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Often there is a lack of full topology and TE <li>There is often a lack of full topology and TE information across
information across domains.</li>
domains;</t> <li>No single node has the full visibility to determine an optimal or
even feasible end-to-end path across domains.</li>
<t>No single node has the full visibility to determine an optimal or <li>Knowing how to evaluate and select the exit point and next domain
even feasible end-to-end path across domains;</t> boundary from a domain.</li>
<li>Understanding how the ingress node determines which domains should
<t>How to evaluate and select the exit point and next domain boundary be used for the end-to-end path.</li>
from a domain?</t> </ul>
<t>
<t>How might the ingress node determine which domains should be used An information exchange across multiple domains is often limited due to
for the end-to-end path?</t>
</list>
</t>
<t>
Often information exchange across multiple domains is limited due to
the lack of trust relationship, security issues, or scalability the lack of trust relationship, security issues, or scalability
issues even if there is a trust relationship between domains.</t> issues, even if there is a trust relationship between domains.</t>
<t>
<t> The Path Computation Element (PCE) <xref target="RFC4655" format="default"/>
The Path Computation Element (PCE) <xref target="RFC4655"/> provides an archi provides an architecture
tecture and a set of functional components to address the problem space and the
and a set of functional components to address the problem space, and
issues highlighted above.</t> issues highlighted above.</t>
<t>
<t>
A PCE may be used to compute end-to-end paths across multi-domain A PCE may be used to compute end-to-end paths across multi-domain
environments using a per-domain path computation technique <xref target="RFC5 environments using a per-domain path computation technique <xref
152"/>. target="RFC5152" format="default"/>.
The so called backward recursive path computation (BRPC) mechanism
<xref target="RFC5441"/> defines a PCE-based path computation procedure to co The so-called backward recursive PCE-based computation (BRPC) mechanism
mpute <xref target="RFC5441" format="default"/> defines a path computation procedur
e to compute
inter-domain constrained Multiprotocol Label Switching (MPLS) and inter-domain constrained Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. However, Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.
However,
both per-domain and BRPC techniques assume that the sequence of both per-domain and BRPC techniques assume that the sequence of
domains to be crossed from source to destination is known, either domains to be crossed from source to destination is known, either
fixed by the network operator or obtained by other means.</t> fixed by the network operator or obtained by other means.</t>
<t>
<t> In more advanced deployments (including multi-area and multi-Autonomous Syste
In more advanced deployments (including multi-area and multi- m (multi-AS) environments), the sequence of domains
Autonomous System (multi-AS) environments) the sequence of domains may not be known in advance, and the choice of domains in the end-to-end
may not be known in advance and the choice of domains in the end-to- domain sequence might be critical to the determination of an
end domain sequence might be critical to the determination of an optimal end-to-end path. In this case, the use of the hierarchical PCE
optimal end-to-end path. In this case the use of the Hierarchical PCE <xref target="RFC6805" format="default"/> architecture and mechanisms may be
<xref target="RFC6805"/> architecture and mechanisms may be used to discover used to discover the
the
intra-area path and select the optimal end-to-end domain sequence.</t> intra-area path and select the optimal end-to-end domain sequence.</t>
<t>
<t>
This document describes the processes and procedures available when This document describes the processes and procedures available when
using the PCE architecture and protocols, for computing inter-area using the PCE architecture and protocols for computing inter-area
and inter-AS MPLS and GMPLS Traffic Engineered paths.</t> and inter-AS MPLS and GMPLS Traffic-Engineered paths.</t>
<t>
<t> The scope of this document does not include discussions of deployment
This document scope does not include discussion on stateful PCE, scenarios for stateful PCE, active PCE, remotely initiated PCE, or
active PCE, remotely initiated PCE, or PCE as a central controller PCE as a central controller (PCECC).
(PCECC) deployment scenarios.</t> </t>
<section anchor="sect-1.1" numbered="true" toc="default">
<section title="Domains" anchor="sect-1.1"><t> <name>Domains</name>
<t>
Generally, a domain can be defined as a separate administrative, Generally, a domain can be defined as a separate administrative,
geographic, or switching environment within the network. A domain geographic, or switching environment within the network. A domain
may be further defined as a zone of routing or computational ability. may be further defined as a zone of routing or computational ability.
Under these definitions a domain might be categorized as an Under these definitions, a domain might be categorized as an
Autonomous System (AS) or an Interior Gateway Protocol (IGP) area Autonomous System (AS) or an Interior Gateway Protocol (IGP) area
(as per <xref target="RFC4726"/> and <xref target="RFC4655"/>).</t> (as per <xref target="RFC4726" format="default"/> and <xref target="RFC4655"
format="default"/>).</t>
<t> <t>
For the purposes of this document, a domain is considered to be a For the purposes of this document, a domain is considered to be a
collection of network elements within an area or AS that has a collection of network elements within an area or AS that has a
common sphere of address management or path computational common sphere of address management or path computational
responsibility. Wholly or partially overlapping domains are not responsibility. Wholly or partially overlapping domains are not
within the scope of this document.</t> within the scope of this document.</t>
<t>
<t>
In the context of GMPLS, a particularly important example of a domain In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork is the Automatically Switched Optical Network (ASON) subnetwork
<xref target="G-8080"/>. In this case, computation of an end-to-end path requ ires <xref target="G-8080" format="default"/>. In this case, computation of an end -to-end path requires
the selection of nodes and links within a parent domain where some the selection of nodes and links within a parent domain where some
nodes may, in fact, be subnetworks. Furthermore, a domain might be an nodes may, in fact, be subnetworks. Furthermore, a domain might be an
ASON routing area <xref target="G-7715"/>. A PCE may perform the path computa ASON routing area <xref target="G-7715" format="default"/>. A PCE may perform
tion the path computation
function of an ASON routing controller as described in <xref target="G-7715-2 function of an ASON Routing Controller as described in <xref target="G-7715-2
"/>.</t> " format="default"/>.</t>
<t>
<t>
It is assumed that the PCE architecture is not applied to a large It is assumed that the PCE architecture is not applied to a large
group of domains, such as the Internet.</t> group of domains, such as the Internet.</t>
</section>
</section> <section anchor="sect-1.2" numbered="true" toc="default">
<name>Path Computation</name>
<section title="Path Computation" anchor="sect-1.2"><t> <t>
For the purpose of this document, it is assumed that the For the purpose of this document, it is assumed that path computation is the
path computation is the sole responsibility of the PCE as per the sole responsibility of the PCE as per the
architecture defined in <xref target="RFC4655"/>. When a path is required the architecture defined in <xref target="RFC4655" format="default"/>. When a pat
Path h is required, the Path
Computation Client (PCC) will send a request to the PCE. The PCE Computation Client (PCC) will send a request to the PCE. The PCE
will apply the required constraints and compute a path and return a will apply the required constraints, compute a path, and return a
response to the PCC. In the context of this document it may be response to the PCC. In the context of this document, it may be
necessary for the PCE to co-operate with other PCEs in adjacent necessary for the PCE to cooperate with other PCEs in adjacent
domains (as per BRPC <xref target="RFC5441"/>) or cooperate with a Parent PCE domains (as per BRPC <xref target="RFC5441" format="default"/>) or with a par
(as per <xref target="RFC6805"/>).</t> ent PCE
(as per <xref target="RFC6805" format="default"/>).</t>
<t> <t>
It is entirely feasible that an operator could compute a path across It is entirely feasible that an operator could compute a path across
multiple domains without the use of a PCE if the relevant domain multiple domains without the use of a PCE if the relevant domain
information is available to the network planner or network management information is available to the network planner or network management
platform. The definition of what relevant information is required to platform. The definition of what relevant information is required to
perform this network planning operation and how that information is perform this network planning operation and how that information is
discovered and applied is outside the scope of this document.</t> discovered and applied is outside the scope of this document.</t>
<section anchor="sect-1.2.1" numbered="true" toc="default">
<section title="PCE-based Path Computation Procedure" anchor="sect-1.2.1" <name>PCE-Based Path Computation Procedure</name>
><t> <t>
As highlighted, the PCE is an entity capable of computing an As highlighted, the PCE is an entity capable of computing an
inter-domain TE path upon receiving a request from a PCC. There could inter-domain TE path upon receiving a request from a PCC. There could
be a single PCE per domain, or single PCE responsible for all be a single PCE per domain or a single PCE responsible for all
domains. A PCE may or may not reside on the same node as the domains. A PCE may or may not reside on the same node as the
requesting PCC. A path may be computed by either a single PCE node requesting PCC. A path may be computed by either a single PCE node
or a set of distributed PCE nodes that collaborate during path or a set of distributed PCE nodes that collaborate during path
computation.</t> computation.</t>
<t> <t>
<xref target="RFC4655"/> defines that a PCC should send a path computation re According to <xref target="RFC4655" format="default"/>, a PCC should send a p
quest ath computation request
to a particular PCE, using <xref target="RFC5440"/> (PCC-to-PCE communication to a particular PCE using <xref target="RFC5440" format="default"/> (PCC-to-P
). CE communication).
This negates the need to broadcast a request to all the PCEs. Each This negates the need to broadcast a request to all the PCEs. Each
PCC can maintain information about the computation capabilities PCC can maintain information about the computation capabilities
of the PCEs, it is aware of. The PCC-PCE capability awareness can be of the PCEs it is aware of. The PCC-PCE capability awareness can be
configured using static configurations or by automatic and dynamic configured using static configurations or by automatic and dynamic
PCE discovery procedures.</t> PCE discovery procedures.</t>
<t>
<t>
If a network path is required, the PCC will send a path computation If a network path is required, the PCC will send a path computation
request to the PCE. A PCE may then compute the end-to-end path request to the PCE. A PCE may then compute the end-to-end path
if it is aware of the topology and TE information required to if it is aware of the topology and TE information required to
compute the entire path. If the PCE is unable to compute the compute the entire path. If the PCE is unable to compute the
entire path, the PCE architecture provides co-operative PCE entire path, the PCE architecture provides cooperative PCE
mechanisms for the resolution of path computation requests when an mechanisms for the resolution of path computation requests when an
individual PCE does not have sufficient TE visibility.</t> individual PCE does not have sufficient TE visibility.</t>
<t> <t>
End-to-end path segments may be kept confidential through the End-to-end path segments may be kept confidential through the
application of path keys, to protect partial or full path application of Path-Keys to protect partial or full path
information. A path key that is a token that replaces a path segment information. A Path-Key is a token that replaces a path segment
in an explicit route. The path key mechanism is described in in an explicit route. The Path-Key mechanism is described in
<xref target="RFC5520"/></t> <xref target="RFC5520" format="default"/>.</t>
</section>
</section> </section>
<section anchor="sect-1.3" numbered="true" toc="default">
</section> <name>Traffic Engineering Aggregation and Abstraction</name>
<section title="Traffic Engineering Aggregation and Abstraction" anchor=" sect-1.3"><t> <t>
Networks are often constructed from multiple areas or ASes that are Networks are often constructed from multiple areas or ASes that are
interconnected via multiple interconnect points. To maintain interconnected via multiple interconnect points. To maintain
network confidentiality and scalability TE properties of each area network confidentiality and scalability, the TE properties of each area
and AS are not generally advertized outside each specific area or AS.</t> and AS are not generally advertised outside each specific area or AS.</t>
<t>
<t> TE aggregation or abstraction provide a mechanism to hide information
TE aggregation or abstraction provide mechanism to hide information but may cause failed path setups or the selection of suboptimal end-
but may cause failed path setups or the selection of suboptimal to-end paths <xref target="RFC4726" format="default"/>. The aggregation proce
end-to-end paths <xref target="RFC4726"/>. The aggregation process may also h ss may also have
ave
significant scaling issues for networks with many possible routes significant scaling issues for networks with many possible routes
and multiple TE metrics. Flooding TE information breaks and multiple TE metrics. Flooding TE information breaks
confidentiality and does not scale in the routing protocol.</t> confidentiality and does not scale in the routing protocol.</t>
<t>
<t>
The PCE architecture and associated mechanisms provide a solution The PCE architecture and associated mechanisms provide a solution
to avoid the use of TE aggregation and abstraction.</t> to avoid the use of TE aggregation and abstraction.</t>
</section>
</section> <section anchor="sect-1.4" numbered="true" toc="default">
<name>Traffic-Engineered Label Switched Paths</name>
<section title="Traffic Engineered Label Switched Paths" anchor="sect-1.4 <t>
"><t>
This document highlights the PCE techniques and mechanisms that exist This document highlights the PCE techniques and mechanisms that exist
for establishing TE packet and optical LSPs across multiple areas for establishing TE packet and optical Label Switched Paths (LSPs) across mul tiple areas
(inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and (inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and
within the remainder of this document, we consider all LSPs to be within the remainder of this document, we consider all LSPs to be
constraint-based and traffic engineered.</t> constraint based and traffic engineered.</t>
<t>
<t>
Three signaling options are defined for setting up an inter-area or Three signaling options are defined for setting up an inter-area or
inter-AS LSP <xref target="RFC4726"/>:</t> inter-AS LSP <xref target="RFC4726" format="default"/>:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Contiguous LSP</t> <li>Contiguous LSP</li>
<li>Stitched LSP</li>
<t>Stitched LSP</t> <li>Nested LSP</li>
</ul>
<t>Nested LSP</t> <t>
</list>
</t>
<t>
All three signaling methods are applicable to the architectures and All three signaling methods are applicable to the architectures and
procedures discussed in this document.</t> procedures discussed in this document.</t>
</section>
</section> <section anchor="sect-1.5" numbered="true" toc="default">
<name>Inter-area and Inter-AS-capable PCE Discovery</name>
<section title="Inter-area and Inter-AS Capable PCE Discovery" anchor="se <t>
ct-1.5"><t>
When using a PCE-based approach for inter-area and inter-AS path When using a PCE-based approach for inter-area and inter-AS path
computation, a PCE in one area or AS may need to learn information computation, a PCE in one area or AS may need to learn information
related to inter-AS capable PCEs located in other ASes. The PCE related to inter-AS-capable PCEs located in other ASes. The PCE
discovery mechanism defined in <xref target="RFC5088"/> and <xref target="RFC discovery mechanism defined in <xref target="RFC5088" format="default"/> and
5089"/> facilitates <xref target="RFC5089" format="default"/> facilitates
the discovery of PCEs, and disclosure of information related to the discovery of PCEs and disclosure of information related to
inter-area and inter-AS capable PCEs.</t> inter-area and inter-AS-capable PCEs.</t>
</section>
</section> <section anchor="sect-1.6" numbered="true" toc="default">
<name>Objective Functions</name>
<section title="Objective Functions" anchor="sect-1.6"><t> <t>
An Objective Function (OF) <xref target="RFC5541"/>, or set of OFs, specifies An Objective Function (OF) <xref target="RFC5541" format="default"/> or a set
the of OFs specifies the
intentions of the path computation and so defines the "optimality", intentions of the path computation and so defines the "optimality"
in the context of the computation request.</t> in the context of the computation request.</t>
<t>
<t> An OF specifies the desired outcome of a computation. It does not
An OF specifies the desired outcome of a computation. An OF does not
describe or specify the algorithm to use. Also, an implementation describe or specify the algorithm to use. Also, an implementation
may apply any algorithm, or set of algorithms, to achieve the result may apply any algorithm or set of algorithms to achieve the result
indicated by the OF. A number of general OFs are specified in indicated by the OF. A number of general OFs are specified in
<xref target="RFC5541"/>.</t> <xref target="RFC5541" format="default"/>.</t>
<t>
<t>
Various OFs may be included in the PCE computation request to Various OFs may be included in the PCE computation request to
satisfy the policies encoded or configured at the PCC, and a PCE satisfy the policies encoded or configured at the PCC, and a PCE
may be subject to policy in determining whether it meets the OFs may be subject to policy in determining whether it meets the OFs
included in the computation request or applies its own OFs.</t> included in the computation request or whether it applies its own OFs.</t>
<t>
<t>
During inter-domain path computation, the selection of a domain During inter-domain path computation, the selection of a domain
sequence, the computation of each (per-domain) path fragment, and sequence, the computation of each (per-domain) path fragment, and the
the determination of the end-to-end path may each be subject to determination of the end-to-end path may each be subject to different
different OFs and policy.</t> OFs and policies.
</t>
</section> </section>
</section>
</section> <section anchor="sect-2" numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology" anchor="sect-2"><t> <t>
This document also uses the terminology defined in <xref target="RFC4655"/> a This document also uses the terminology defined in <xref target="RFC4655" for
nd mat="default"/> and
<xref target="RFC5440"/>. Additional terminology is defined below: <xref target="RFC5440" format="default"/>. Additional terminology is defined
below:
<list style="hanging" hangIndent="6">
<t hangText="ABR:"> IGP Area Border Router, a router that is attached to
more than
one IGP area. </t>
<t hangText="ASBR:"> Autonomous System Border Router, a router used to co </t>
nnect <dl newline="false" spacing="normal" indent="6">
<dt>ABR:</dt>
<dd> IGP Area Border Router -- a router that is attached to more than
one IGP area. </dd>
<dt>ASBR:</dt>
<dd> Autonomous System Border Router -- a router used to connect
together ASes of a different or the same Service Provider via one or more inter-AS links. together ASes of a different or the same Service Provider via one or more inter-AS links.
</t> </dd>
<dt>Inter-area TE LSP:</dt>
<t hangText="Inter-area TE LSP:"> A TE LSP whose path transits through tw <dd> A TE LSP whose path transits through two or more
o or more IGP areas. </dd>
IGP areas. </t> <dt>Inter-AS MPLS TE LSP:</dt>
<dd> A TE LSP whose path transits through two or
<t hangText="Inter-AS MPLS TE LSP:"> A TE LSP whose path transits through more ASes or sub-ASes (BGP confederations) </dd>
two or <dt>SRLG:</dt>
more ASes or sub-ASes (BGP confederations </t> <dd> Shared Risk Link Group.</dd>
<dt>TED:</dt>
<t hangText="SRLG:"> Shared Risk Link Group.</t> <dd> Traffic Engineering Database, which contains the
<t hangText="TED:"> Traffic Engineering Database, which contains the
topology and resource information of the domain. The TED may be fed topology and resource information of the domain. The TED may be fed
by Interior Gateway Protocol (IGP) extensions or potentially by other by Interior Gateway Protocol (IGP) extensions or potentially by other
means. </t> means. </dd>
</dl>
</list> </section>
</t> <section anchor="sect-3" numbered="true" toc="default">
<name>Issues and Considerations</name>
</section> <section anchor="sect-3.1" numbered="true" toc="default">
<name>Multihoming</name>
<section title="Issues and Considerations" anchor="sect-3"><section title <t>
="Multi-homing" anchor="sect-3.1"><t>
Networks constructed from multi-areas or multi-AS environments Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path may have multiple interconnect points (multihoming). End-to-end path
computations may need to use different interconnect points to avoid computations may need to use different interconnect points to avoid
a single point failure disrupting both primary and backup services.</t> a single-point failure disrupting both the primary and backup services.</t>
</section>
</section> <section anchor="sect-3.2" numbered="true" toc="default">
<name>Destination Location</name>
<section title="Destination Location" anchor="sect-3.2"><t> <t>
The PCC asking for an inter-domain path computation is typically A PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. If the PCC is aware aware of the identity of the destination node. If the PCC is aware
of the destination domain, it may supply the destination domain of the destination domain, it may supply the destination domain
information as part of the path computation request. However, if the information as part of the path computation request. However, if the
PCC does not know the destination domain this information must be PCC does not know the destination domain, this information must be
determined by another method.</t> determined by another method.</t>
</section>
</section> <section anchor="sect-3.3" numbered="true" toc="default">
<name>Domain Confidentiality</name>
<section title="Domain Confidentiality" anchor="sect-3.3"><t> <t>
Where the end-to-end path crosses multiple domains, it may be When the end-to-end path crosses multiple domains, it may be possible that
possible that each domain (AS or area) are administered by separate each domain (AS or area) is administered by separate Service Providers.
Service Providers, it would break confidentiality rules for a PCE Thus, if a PCE supplies a path segment to a PCE in another domain, it may
to supply a path segment to a PCE in another domain, thus disclosing break confidentiality rules and could disclose AS-internal topology
AS-internal topology information.</t> information.</t>
<t>
<t>
If confidentiality is required between domains (ASes and areas) If confidentiality is required between domains (ASes and areas)
belonging to different Service Providers, then cooperating PCEs belonging to different Service Providers, then cooperating PCEs
cannot exchange path segments or else the receiving PCE or PCC will cannot exchange path segments; otherwise, the receiving PCE or PCC will
be able to see the individual hops through another domain.</t> be able to see the individual hops through another domain.</t>
<t>
<t> This topic is discussed further in <xref target="sect-8"/> of this document.<
This topic is discussed further in Section 8 of this document.</t> /t>
</section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
</section> <name>Domain Topologies</name>
<t>
<section title="Domain Topologies" anchor="sect-4"><t>
Constraint-based inter-domain path computation is a fundamental Constraint-based inter-domain path computation is a fundamental
requirement for operating traffic engineered MPLS <xref target="RFC3209"/> an requirement for operating traffic-engineered MPLS <xref target="RFC3209" form
d at="default"/> and
GMPLS <xref target="RFC3473"/> networks, in inter-area and inter-AS (multi-do GMPLS <xref target="RFC3473" format="default"/> networks in inter-area and in
main) ter-AS (multi-domain)
environments. Path computation across multi-domain networks is environments. Path computation across multi-domain networks is
complex and requires computational co-operational entities like the complex and requires computational cooperational entities like the
PCE.</t> PCE.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="Selecting Domain Paths" anchor="sect-4.1"><t> <name>Selecting Domain Paths</name>
<t>
Where the sequence of domains is known a priori, various techniques Where the sequence of domains is known a priori, various techniques
can be employed to derive an optimal multi-domain path. If the can be employed to derive an optimal multi-domain path. If the
domains are connected to a simple path with no branches and single domains are connected to a simple path with no branches and single
links between all domains, or if the preferred points of links between all domains or if the preferred points of
interconnection is also known, the Per-Domain Path Computation interconnection are also known, the per-domain path computation
<xref target="RFC5152"/> technique may be used. Where there are multiple conn <xref target="RFC5152" format="default"/> technique may be used. Where there
ections are multiple connections
between domains and there is no preference for the choice of points between domains and there is no preference for the choice of points
of interconnection, BRPC <xref target="RFC5441"/> can be used to derive an op timal of interconnection, BRPC <xref target="RFC5441" format="default"/> can be use d to derive an optimal
path.</t> path.</t>
<t>
<t> When the sequence of domains is not known in advance or the
When the sequence of domains is not known in advance, or the
end-to-end path will have to navigate a mesh of small domains end-to-end path will have to navigate a mesh of small domains
(especially typical in optical networks), the optimum path may be (especially typical in optical networks), the optimum path may be
derived through the application of a Hierarchical PCE <xref target="RFC6805"/ derived through the application of a hierarchical PCE <xref target="RFC6805"
>.</t> format="default"/>.</t>
</section>
</section> <section anchor="sect-4.2" numbered="true" toc="default">
<name>Domain Sizes</name>
<section title="Domain Sizes" anchor="sect-4.2"><t> <t>
Very frequently network domains are composed of dozens or hundreds of Very frequently, network domains are composed of dozens or hundreds of
network elements. These network elements are usually interconnected network elements. These network elements are usually interconnected
in a partial-mesh fashion, to provide survivability against dual in a partial-mesh fashion to provide survivability against dual
failures, and to benefit from the traffic engineering capabilities failures and to benefit from the traffic-engineering capabilities
from MPLS and GMPLS protocols. Network operator feedback in the of MPLS and GMPLS protocols. Network operator feedback in the
development of the document highlighted that node degree (the number development of the document highlighted that the node degree (the number
of neighbors per node) typically ranges from 3 to 10 (4-5 is quite of neighbors per node) typically ranges from 3 to 10 (4-5 is quite
common).</t> common).</t>
</section>
</section> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Domain Diversity</name>
<section title="Domain Diversity" anchor="sect-4.3"><t> <t>
Domain and path diversity may also be required when computing Domain and path diversity may also be required when computing
end-to-end paths. Domain diversity should facilitate the selection end-to-end paths. Domain diversity should facilitate the selection
of paths that share ingress and egress domains, but do not share of paths that share ingress and egress domains but do not share
transit domains. Therefore, there must be a method allowing the transit domains. Therefore, there must be a method allowing the
inclusion or exclusion of specific domains when computing end-to-end inclusion or exclusion of specific domains when computing end-to-end paths.</
paths.</t> t>
</section>
</section> <section anchor="sect-4.4" numbered="true" toc="default">
<name>Synchronized Path Computations</name>
<section title="Synchronized Path Computations" anchor="sect-4.4"><t> <t>
In some scenarios, it would be beneficial for the operator to rely on In some scenarios, it would be beneficial for the operator to rely on
the capability of the PCE to perform synchronized path computation.</t> the capability of the PCE to perform synchronized path computation.</t>
<t>
<t>
Synchronized path computations, known as Synchronization VECtors Synchronized path computations, known as Synchronization VECtors
(SVECs) are used for dependent path computations. SVECs are (SVECs), are used for dependent path computations. SVECs are
defined in <xref target="RFC5440"/> and <xref target="RFC6007"/> provides an defined in <xref target="RFC5440" format="default"/>, and <xref target="RFC60
overview for the 07" format="default"/> provides an overview of the
use of the PCE SVEC list for synchronized path computations when use of the PCE SVEC list for synchronized path computations when
computing dependent requests.</t> computing dependent requests.</t>
<t>
<t> In hierarchical PCE (H-PCE) deployments, a child PCE will be able to request
In H-PCE deployments, a child PCE will be able to request both both
dependent and synchronized domain diverse end to end paths from its dependent and synchronized domain-diverse end-to-end paths from its
parent PCE.</t> parent PCE.</t>
</section>
</section> <section anchor="sect-4.5" numbered="true" toc="default">
<name>Domain Inclusion or Exclusion</name>
<section title="Domain Inclusion or Exclusion" anchor="sect-4.5"><t> <t>
A domain sequence is an ordered sequence of domains traversed to A domain sequence is an ordered sequence of domains traversed to
reach the destination domain. A domain sequence may be supplied reach the destination domain. A domain sequence may be supplied
during path computation to guide the PCEs or derived via the use of during path computation to guide the PCEs or are derived via the use of
Hierarchical PCE (H-PCE).</t> hierarchical PCE (H-PCE).</t>
<t>
<t>
During multi-domain path computation, a PCC may request During multi-domain path computation, a PCC may request
specific domains to be included or excluded in the domain sequence specific domains to be included or excluded in the domain sequence
using the Include Route Object (IRO) <xref target="RFC5440"/> and Exclude Rou using the Include Route Object (IRO) <xref target="RFC5440" format="default"/
te > and Exclude Route
Object (XRO) <xref target="RFC5521"/>. The use of Autonomous Number (AS) as a Object (XRO) <xref target="RFC5521" format="default"/>. The use of Autonomous
n Number (AS) as an
abstract node representing a domain is defined in <xref target="RFC3209"/>. abstract node representing a domain is defined in <xref target="RFC3209" form
<xref target="RFC7897"/> specifies new sub-objects to include or exclude doma at="default"/>.
ins <xref target="RFC7897" format="default"/> specifies new subobjects to include
such as an IGP area or a 4-Byte AS number.</t> or exclude domains
such as an IGP area or a 4-byte AS number.</t>
<t> <t>
An operator may also need to avoid a path that uses specified nodes An operator may also need to avoid a path that uses specified nodes
for administrative reasons, or if a specific connectivity for administrative reasons. If a specific connectivity service is
service required to have a 1+1 protection capability, two required to have a 1+1 protection capability, two separate disjoint
completely disjoint paths must be established. A mechanism known as paths must be established.
A mechanism known as
Shared Risk Link Group (SRLG) information may be used to ensure Shared Risk Link Group (SRLG) information may be used to ensure
path diversity.</t> path diversity.</t>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
</section> <name>Applicability of the PCE to Inter-area Traffic Engineering</name>
<t>
<section title="Applicability of the PCE to Inter-area Traffic Engineerin
g" anchor="sect-5"><t>
As networks increase in size and complexity, it may be required to As networks increase in size and complexity, it may be required to
introduce scaling methods to reduce the amount of information introduce scaling methods to reduce the amount of information
flooded within the network and make the network more manageable. An flooded within the network and make the network more manageable. An
IGP hierarchy is designed to improve IGP scalability by dividing the IGP hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of information to within area boundaries. This restricts visibility of
the area to routers in a single area. If a router needs to compute the area to routers in a single area. If a router needs to compute
the route to a destination located in another area, a method would the route to a destination located in another area, a method would
be required to compute a path across area boundaries.</t> be required to compute a path across area boundaries.</t>
<t>
<t> In order to support multiple vendors in a network in cases where
In order to support multiple vendors in a network, in cases where data or control-plane technologies cannot interoperate, it is useful
data or control plane technologies cannot interoperate, it is useful
to divide the network into vendor domains. Each vendor domain is to divide the network into vendor domains. Each vendor domain is
an IGP area, and the flooding scope of the topology (as well as any an IGP area, and the flooding scope of the topology (as well as any
other relevant information) is limited to the area boundaries.</t> other relevant information) is limited to the area boundaries.</t>
<t>
<t> Per-domain path computation <xref target="RFC5152" format="default"/> exists
Per-domain path computation <xref target="RFC5152"/> exists to provide a meth to provide a method of
od of
inter-area path computation. The per-domain solution is based on inter-area path computation. The per-domain solution is based on
loose hop routing with an Explicit Route Object (ERO) expansion on loose hop routing with an Explicit Route Object (ERO) expansion on
each Area Border Router (ABR). This allows an LSP to be established each Area Border Router (ABR). This allows an LSP to be established
using a constrained path, however at least two issues exist:</t> using a constrained path. However, at least two issues exist:</t>
<ul spacing="normal">
<t><list style="symbols"><t>This method does not guarantee an optimal con <li>This method does not guarantee an optimal constrained path.</li>
strained path.</t> <li>The method may require several crankback signaling messages, as per
<xref target="RFC4920" format="default"/>, increasing signaling traffic and
<t>The method may require several crankback signaling messages, as per delaying the LSP setup.</li>
<xref target="RFC4920"/>, increasing signaling traffic and delaying the LSP </ul>
setup.</t> <t>
PCE-based architecture <xref target="RFC4655" format="default"/> is designed
</list> to solve inter-area
</t>
<t>
The PCE-based architecture <xref target="RFC4655"/> is designed to solve inte
r-area
path computation problems. The issue of limited topology visibility path computation problems. The issue of limited topology visibility
is resolved by introducing path computation entities that are able to is resolved by introducing path computation entities that are able to
cooperate in order to establish LSPs with source and destinations cooperate in order to establish LSPs with the source and destinations
located in different areas.</t> located in different areas.</t>
<section anchor="sect-5.1" numbered="true" toc="default">
<section title="Inter-area Routing" anchor="sect-5.1"><t> <name>Inter-area Routing</name>
<t>
An inter-area TE-LSP is an LSP that transits through at least two An inter-area TE-LSP is an LSP that transits through at least two
IGP areas. In a multi-area network, topology visibility remains IGP areas. In a multi-area network, topology visibility remains
local to a given area for scaling and privacy purposes, a node local to a given area for scaling and privacy purposes. A node
in one area will not be able to compute an end-to-end path across in one area will not be able to compute an end-to-end path across
multiple areas without the use of a PCE.</t> multiple areas without the use of a PCE.</t>
<section anchor="sect-5.1.1" numbered="true" toc="default">
<section title="Area Inclusion and Exclusion" anchor="sect-5.1.1"><t> <name>Area Inclusion and Exclusion</name>
The BRPC method <xref target="RFC5441"/> of path computation provides a more <t>
optimal The BRPC method <xref target="RFC5441" format="default"/> of path computation
provides a more optimal
method to specify inclusion or exclusion of an ABR. Using the BRPC method to specify inclusion or exclusion of an ABR. Using the BRPC
procedure an end-to-end path is recursively computed in reverse from procedure, an end-to-end path is recursively computed in reverse from
the destination domain, towards the source domain. Using this method, the destination domain towards the source domain. Using this method,
an operator might decide if an area must be included or excluded from an operator might decide if an area must be included or excluded from
the inter-area path computation.</t> the inter-area path computation.</t>
</section>
</section> <section anchor="sect-5.1.2" numbered="true" toc="default">
<name>Strict Explicit Path and Loose Path</name>
<section title="Strict Explicit Path and Loose Path" anchor="sect-5.1.2"> <t>
<t> A strict explicit path is defined as a set of strict hops, while a
A strict explicit Path is defined as a set of strict hops, while a
loose path is defined as a set of at least one loose hop and zero or loose path is defined as a set of at least one loose hop and zero or
more strict hops. It may be useful to indicate, during the more strict hops. It may be useful to indicate whether a strict explicit pat
path computation request, if a strict explicit path is required or h is required during the path computation request. An inter-area path may be str
not. An inter-area path may be strictly explicit or loose (e.g., a ictly explicit or loose (e.g., a
list of ABRs as loose hops).</t> list of ABRs as loose hops).</t>
<t>
<t> A PCC request to a PCE does allow indication of whether a strict
A PCC request to a PCE does allow the indication of whether a strict explicit path across specific areas (<xref target="RFC7897" format="default"/
explicit path across specific areas (<xref target="RFC7897"/>) is required or >) is required or
desired, or if the path request is loose.</t> desired or whether the path request is loose.</t>
</section>
</section> <section anchor="sect-5.1.3" numbered="true" toc="default">
<name>Inter-Area Diverse Path Computation</name>
<section title="Inter-Area Diverse Path Computation" anchor="sect-5.1.3"> <t>
<t>
It may be necessary to compute a path that is partially or entirely It may be necessary to compute a path that is partially or entirely
diverse, from a previously computed path, to avoid fate sharing of diverse from a previously computed path to avoid fate sharing of
a primary service with a corresponding backup service. There are a primary service with a corresponding backup service. There are
various levels of diversity in the context of an inter-area network:</t> various levels of diversity in the context of an inter-area network:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Per-area diversity (intra-area path segments <li>Per-area diversity (the intra-area path segments are a link, nod
are link, node or e, or
SRLG disjoint.</t> SRLG disjoint).</li>
<li>Inter-area diversity (the end-to-end inter-area paths are a link
<t>Inter-area diversity (end-to-end inter-area paths are link, ,
node or SRLG disjoint).</t> node, or SRLG disjoint).</li>
</ul>
</list> <t>
</t> Note that two paths may be disjointed in the backbone area but non-disjointed
in peripheral areas. Also, two paths may be node disjointed
<t>
Note that two paths may be disjoint in the backbone area but non-
disjoint in peripheral areas. Also, two paths may be node disjoint
within areas but may share ABRs, in which case path segments within within areas but may share ABRs, in which case path segments within
an area is node disjoint, but end-to-end paths are not node-disjoint. an area are node disjointed but end-to-end paths are not node disjointed.
Per-Domain <xref target="RFC5152"/>, BRPC <xref target="RFC5441"/> and H-PCE Per-domain <xref target="RFC5152" format="default"/>, BRPC <xref target="RFC5
<xref target="RFC6805"/> mechanisms 441" format="default"/>, and H-PCE <xref target="RFC6805" format="default"/> mec
hanisms
all support the capability to compute diverse paths across multi-area all support the capability to compute diverse paths across multi-area
topologies.</t> topologies.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>Applicability of the PCE to Inter-AS Traffic Engineering</name>
</section> <t>
As discussed in <xref target="sect-5" format="default"/> (<xref target="sect-
<section title="Applicability of the PCE to Inter-AS Traffic Engineering" 5" format="title" />), it is necessary to divide the network into
anchor="sect-6"><t>
As discussed in section 4 (Applicability of the PCE to Inter-area
Traffic Engineering) it is necessary to divide the network into
smaller administrative domains, or ASes. If an LSR within an AS needs smaller administrative domains, or ASes. If an LSR within an AS needs
to compute a path across an AS boundary, it must also use an inter-AS to compute a path across an AS boundary, it must also use an inter-AS
computation technique. <xref target="RFC5152"/> defines mechanisms for the computation technique. <xref target="RFC5152" format="default"/> defines mech anisms for the
computation of inter-domain TE LSPs using network elements along the computation of inter-domain TE LSPs using network elements along the
signaling paths to compute per-domain constrained path segments.</t> signaling paths to compute per-domain constrained path segments.</t>
<t>
<t>
The PCE was designed to be capable of computing MPLS and GMPLS paths The PCE was designed to be capable of computing MPLS and GMPLS paths
across AS boundaries. This section outlines the features of a across AS boundaries. This section outlines the features of a
PCE-enabled solution for computing inter-AS paths.</t> PCE-enabled solution for computing inter-AS paths.</t>
<section anchor="sect-6.1" numbered="true" toc="default">
<section title="Inter-AS Routing" anchor="sect-6.1"><section title="AS In <name>Inter-AS Routing</name>
clusion and Exclusion" anchor="sect-6.1.1"><t> <section anchor="sect-6.1.1" numbered="true" toc="default">
<xref target="RFC5441"/> allows the specifying of inclusion or exclusion of a <name>AS Inclusion and Exclusion</name>
n AS <t>
or an ASBR. Using this method, an operator might decide if an AS <xref target="RFC5441" format="default"/> allows the specification of AS or
must be include or exclude from the inter-AS path computation. ASBR inclusion or exclusion. Using this method, an operator might decide whet
her an AS
must be included or excluded from the inter-AS path computation.
Exclusion and/or inclusion could also be specified at any step in Exclusion and/or inclusion could also be specified at any step in
the LSP path computation process by a PCE (within the BRPC the LSP path computation process by a PCE (within the BRPC
algorithm) but the best practice would be to specify them at the algorithm), but the best practice would be to specify them at the
edge. In opposition to the strict and loose path, AS inclusion or edge. In opposition to the strict and loose path, AS inclusion or
exclusion doesn't impose topology disclosure as ASes are public exclusion doesn't impose topology disclosure as ASes and their
entity as well as their interconnection.</t> interconnection are public
entities.</t>
</section> </section>
</section>
</section> <section anchor="sect-6.2" numbered="true" toc="default">
<name>Inter-AS Bandwidth Guarantees</name>
<section title="Inter-AS Bandwidth Guarantees" anchor="sect-6.2"><t> <t>
Many operators with multi-AS domains will have deployed MPLS-TE Many operators with multi-AS domains will have deployed the MPLS-TE
DiffServ either across their entire network or at the domain edges Diffserv either across their entire network or at the domain edges
on CE-PE links. In situations where strict QOS bounds are required, on CE-PE links. In situations where strict QoS bounds are required,
admission control inside the network may also be required.</t> admission control inside the network may also be required.</t>
<t>
<t>
When the propagation delay can be bounded, the performance targets, When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay may be guaranteed by providing such as maximum one-way transit delay, may be guaranteed by providing
bandwidth guarantees along the DiffServ-enabled path, these bandwidth guarantees along the Diffserv-enabled path. These
requirements are described in <xref target="RFC4216"/>.</t> requirements are described in <xref target="RFC4216" format="default"/>.</t>
<t>
<t> One typical example of the requirements in <xref target="RFC4216" format="def
One typical example of the requirements in <xref target="RFC4216"/> is to pro ault"/> is to provide
vide
bandwidth guarantees over an end-to-end path for VoIP traffic bandwidth guarantees over an end-to-end path for VoIP traffic
classified as EF (Expedited Forwarding) class in a DiffServ-enabled classified as an EF (Expedited Forwarding) class in a Diffserv-enabled
network. In the case where the EF path is extended across multiple network. In cases where the EF path is extended across multiple
ASes, inter-AS bandwidth guarantee would be required.</t> ASes, an inter-AS bandwidth guarantee would be required.</t>
<t>
<t> Another case for an inter-AS bandwidth guarantee is the requirement to guaran
Another case for inter-AS bandwidth guarantee is the requirement for tee a certain amount of transit bandwidth across one or
guaranteeing a certain amount of transit bandwidth across one or
multiple ASes.</t> multiple ASes.</t>
</section>
</section> <section anchor="sect-6.3" numbered="true" toc="default">
<name>Inter-AS Recovery</name>
<section title="Inter-AS Recovery" anchor="sect-6.3"><t> <t>
During a path computation process, a PCC request may contain the During a path computation process, a PCC request may contain the
requirement to compute a backup LSP for protecting the primary LSP, requirement to compute a backup LSP for protecting the primary LSP, such as
1+1 protection. A single LSP or multiple backup LSPs may also be 1+1 protection.
used for a group of primary LSPs, this is typically known as m:n A single LSP or multiple backup LSPs may also be
used for a group of primary LSPs; this is typically known as m:n
protection.</t> protection.</t>
<t>
<t> Other inter-AS recovery mechanisms include <xref target="RFC4090" format="def
Other inter-AS recovery mechanisms include <xref target="RFC4090"/> which add ault"/>, which adds Fast
s fast Reroute (FRR) protection to an LSP. So, the PCE could be used to
re-route (FRR) protection to an LSP. So, the PCE could be used to trigger computation of backup tunnels in order to protect inter-AS
trigger computation of backup tunnels in order to protect Inter-AS
connectivity.</t> connectivity.</t>
<t>
<t>
Inter-AS recovery clearly requires backup LSPs for service Inter-AS recovery clearly requires backup LSPs for service
protection but it would also be advisable to have multiple PCEs protection, but it would also be advisable to have multiple PCEs
deployed for path computation redundancy, especially for service deployed for path computation redundancy, especially for service
restoration in the event of catastrophic network failure.</t> restoration in the event of catastrophic network failure.</t>
</section>
<section anchor="sect-6.4" numbered="true" toc="default">
<name>Inter-AS PCE Peering Policies</name>
<t>
Like BGP peering policies, inter-AS PCE peering policies are required for
an operator. In an inter-AS BRPC process, the PCE must
cooperate in order to compute the end-to-end LSP. Therefore, the AS path
must not only follow technical constraints, e.g., bandwidth
availability, but also the policies defined by the operator.</t>
</section> <t>
Typically, PCE interconnections at an AS level must follow the agreed
<section title="Inter-AS PCE Peering Policies" anchor="sect-6.4"><t>
Like BGP peering policies, inter-AS PCE peering policies is a
requirement for operator. In inter-AS BRPC process, PCE must
cooperate in order to compute the end-to-end LSP. So, the AS path
must not only follow technical constraints, e.g. bandwidth
availability, but also policies defined by the operator.</t>
<t>
Typically PCE interconnections at an AS level must follow agreed
contract obligations, also known as peering agreements. The PCE contract obligations, also known as peering agreements. The PCE
peering policies are the result of the contract negotiation and peering policies are the result of the contract negotiation and
govern the relation between the different PCE.</t> govern the relation between the different PCEs.</t>
</section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
</section> <name>Multi-domain PCE Deployment Options</name>
<section anchor="sect-7.1" numbered="true" toc="default">
<section title="Multi-domain PCE Deployment Options" anchor="sect-7"><sec <name>Traffic Engineering Database and Synchronization</name>
tion title="Traffic Engineering Database and Synchronization" anchor="sect-7.1"> <t>
<t>
An optimal path computation requires knowledge of the available An optimal path computation requires knowledge of the available
network resources, including nodes and links, constraints, network resources, including nodes and links, constraints,
link connectivity, available bandwidth, and link costs. The PCE link connectivity, available bandwidth, and link costs. The PCE
operates on a view of the network topology as presented by a operates on a view of the network topology as presented by a
TED. As discussed in <xref target="RFC4655"/> the TED used by a PCE may be l earnt TED. As discussed in <xref target="RFC4655" format="default"/>, the TED used by a PCE may be learned
by the relevant IGP extensions.</t> by the relevant IGP extensions.</t>
<t>
<t> Thus, the PCE may operate its TED by participating
Thus, the PCE may operate its TED is by participating
in the IGP running in the network. In an MPLS-TE network, this in the IGP running in the network. In an MPLS-TE network, this
would require OSPF-TE <xref target="RFC3630"/> or ISIS-TE <xref target="RFC53 would require OSPF-TE <xref target="RFC3630" format="default"/> or ISIS-TE <x
05"/>. In a GMPLS ref target="RFC5305" format="default"/>. In a GMPLS
network it would utilize the GMPLS extensions to OSPF and IS-IS network, it would utilize the GMPLS extensions to OSPF and IS-IS
defined in <xref target="RFC4203"/> and <xref target="RFC5307"/>. Inter-as co defined in <xref target="RFC4203" format="default"/> and <xref target="RFC530
nnectivity 7" format="default"/>. Inter-AS connectivity
information may be populated via <xref target="RFC5316"/> and <xref target="R information may be populated via <xref target="RFC5316" format="default"/> an
FC5392"/>.</t> d <xref target="RFC5392" format="default"/>.</t>
<t>
<t> An alternative method to providing network topology and resource
An alternative method to provide network topology and resource information is offered by <xref target="RFC7752" format="default"/>, which is
information is offered by <xref target="RFC7752"/>, which is described in the described in the
following section.</t> following section.</t>
<section anchor="sect-7.1.1" numbered="true" toc="default">
<section title="Applicability of BGP-LS to PCE" anchor="sect-7.1.1"><t> <name>Applicability of BGP-LS to PCE</name>
The concept of exchange of TE information between Autonomous Systems <t>
(ASes) is discussed in <xref target="RFC7752"/>. The information exchanged i The concept of the exchange of TE information between Autonomous Systems
n this (ASes) is discussed in <xref target="RFC7752" format="default"/>. The inform
ation exchanged in this
way could be the full TE information from the AS, an aggregation of way could be the full TE information from the AS, an aggregation of
that information, or a representation of the potential connectivity that information, or a representation of the potential connectivity
across the AS. Furthermore, that information could be updated across the AS. Furthermore, that information could be updated
frequently (for example, for every new LSP that is set up across the frequently (for example, for every new LSP that is set up across the
AS) or only at threshold-crossing events.</t> AS) or only at threshold-crossing events.</t>
<t>
<t>
In an H-PCE deployment, the parent PCE will require the inter-domain In an H-PCE deployment, the parent PCE will require the inter-domain
topology and link status between child domains. This information may topology and link status between child domains. This information may
be learnt by a BGP-LS speaker and provided to the parent PCE, be learned by a BGP-LS speaker and provided to the parent PCE.
furthermore link-state performance including delay, available Furthermore, link-state performance, including delay, available
bandwidth and utilized bandwidth may also be provided to the parent bandwidth, and utilized bandwidth, may also be provided to the parent
PCE for optimal path link selection.</t> PCE for optimal path link selection.</t>
</section>
</section> </section>
<section anchor="sect-7.2" numbered="true" toc="default">
</section> <name>Pre-planning and Management-Based Solutions</name>
<t>
<section title="Pre-Planning and Management-Based Solutions" anchor="sect Offline path computation is performed ahead of time before the LSP
-7.2"><t> setup is requested. That means that it is requested by or performed
Offline path computation is performed ahead of time, before the LSP as part of an Operation Support System (OSS) management application.
setup is requested. That means that it is requested by, or performed This model can be seen in <xref target="RFC4655" section="5.5" sectionFormat=
as part of, an Operation Support System (OSS) management application. "of"/>.</t>
This model can be seen in Section 5.5 of <xref target="RFC4655"/>.</t> <t>
The offline model is particularly appropriate for long-lived LSPs
<t>
The offline model is particularly appropriate to long-lived LSPs
(such as those present in a transport network) or for planned (such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning.</t> normally a feature of LSP provisioning.</t>
<figure><artwork><![CDATA[ <t>
The management system may also use a PCE and BRPC to pre-plan an AS The management system may also use a PCE and BRPC to pre-plan an AS
sequence, and the source domain PCE and per-domain path sequence, and the source domain PCE and per-domain path
computation to be used when the actual end-to-end path is computation to be used when the actual end-to-end path is
required. This model may also be used where the operator required. This model may also be used where the operator
wishes to retain full manual control of the placement of LSPs, wishes to retain full manual control of the placement of LSPs,
using the PCE only as a computation tool to assist the operator, using the PCE only as a computation tool to assist the operator and
not as part of an automated network. not as part of an automated network.
]]></artwork> </t>
</figure> <t>
<t> In environments where operators peer with each other to provide end-to-end
In environments where operators peer with each other to provide end- paths, the operator responsible for each domain must agree on the
to-end paths, the operator responsible for each domain must agree extent to which paths must be pre-planned or manually controlled.</t>
to what extent paths must be pre-planned or manually controlled.</t> </section>
</section>
</section> <section anchor="sect-8" numbered="true" toc="default">
<name>Domain Confidentiality</name>
</section> <t>
This section discusses the techniques that cooperating PCEs
<section title="Domain Confidentiality" anchor="sect-8"><t>
This section discusses the techniques that co-operating PCEs
can use to compute inter-domain paths without each domain can use to compute inter-domain paths without each domain
disclosing sensitive internal topology information (such as disclosing sensitive internal topology information (such as
explicit nodes or links within the domain) to the other domains.</t> explicit nodes or links within the domain) to the other domains.</t>
<t> <t>
Confidentiality typically applies to inter-provider (inter-AS) PCE Confidentiality typically applies to inter-provider (inter-AS) PCE
communication. Where the TE LSP crosses multiple domains (ASes or communication.
areas), the path may be computed by multiple PCEs that cooperate Where the TE LSP crosses multiple domains (ASes or areas), the path may be
together. With each local PCE responsible for computing a segment computed by multiple PCEs that cooperate together, with each local PCE
responsible for computing a segment of the path.
With each local PCE responsible for computing a segment
of the path.</t> of the path.</t>
<t> <t>
In situations where ASes are administered by separate Service In situations where ASes are administered by separate Service
Providers, it would break confidentiality rules for a PCE to supply Providers, it would break confidentiality rules for a PCE to supply
a path segment details to a PCE responsible another domain, thus path segment details to a PCE responsible for another domain, thus
disclosing AS-internal or area topology information.</t> disclosing AS-internal or area topology information.</t>
<section anchor="sect-8.1" numbered="true" toc="default">
<section title="Loose Hops" anchor="sect-8.1"><t> <name>Loose Hops</name>
<t>
A method for preserving the confidentiality of the path segment is A method for preserving the confidentiality of the path segment is
for the PCE to return a path containing a loose hop in place of the for the PCE to return a path containing a loose hop in place of the
segment that must be kept confidential. The concept of loose and segment that must be kept confidential. The concept of loose and
strict hops for the route of a TE LSP is described in <xref target="RFC3209"/ strict hops for the route of a TE LSP is described in <xref target="RFC3209"
>.</t> format="default"/>.</t>
<t>
<t> <xref target="RFC5440" format="default"/> supports the use of paths with
<xref target="RFC5440"/> supports the use of paths with loose hops, and it is loose hops; whether it returns a full explicit
a path with strict hops or uses loose hops is a
local policy decision at a PCE whether it returns a full explicit local policy decision at a PCE. A path computation
path with strict hops or uses loose hops. A path computation request may require an explicit path with strict hops or may allow
request may require an explicit path with strict hops, or may allow loose hops, as detailed in <xref target="RFC5440" format="default"/>.</t>
loose hops as detailed in <xref target="RFC5440"/>.</t> </section>
<section anchor="sect-8.2" numbered="true" toc="default">
</section> <name>Confidential Path Segments and Path-Keys</name>
<t>
<section title="Confidential Path Segments and Path Keys" anchor="sect-8. <xref target="RFC5520" format="default"/> defines the concept and mechanism
2"><t> of a Path-Key. A Path-Key
<xref target="RFC5520"/> defines the concept and mechanism of Path-Key. A Pat
h-Key
is a token that replaces the path segment information in an explicit is a token that replaces the path segment information in an explicit
route. The Path-Key allows the explicit route information to be route. The Path-Key allows the explicit route information to be
encoded and in the PCEP (<xref target="RFC5440"/>) messages exchanged between the encoded and is contained in the Path Computation Element Communication Protoc ol (PCEP) (<xref target="RFC5440" format="default"/>) messages exchanged between the
PCE and PCC.</t> PCE and PCC.</t>
<t>
<t>
This Path-Key technique allows explicit route information to be used This Path-Key technique allows explicit route information to be used
for end-to-end path computation, without disclosing internal topology for end-to-end path computation without disclosing internal topology
information between domains.</t> information between domains.</t>
</section>
</section> </section>
<section anchor="sect-9" numbered="true" toc="default">
</section> <name>Point to Multipoint</name>
<t>
<section title="Point-to-Multipoint" anchor="sect-9"><t>
For inter-domain point-to-multipoint application scenarios using For inter-domain point-to-multipoint application scenarios using
MPLS-TE LSPs, the complexity of domain sequences, domain policies, MPLS-TE LSPs, the complexity of domain sequences, domain policies,
choice and number of domain interconnects is magnified compared to and the choice and number of domain interconnects is magnified compared to
point-to-point path computations. As the size of the network point-to-point path computations. As the size of the network
grows, the number of leaves and branches increase, further grows, the number of leaves and branches increases, further
increasing the complexity of the overall path computation problem. increasing the complexity of the overall path computation problem.
A solution for managing point-to-multipoint path computations may A solution for managing point-to-multipoint path computations may
be achieved using the PCE inter-domain point-to-multipoint path be achieved using the PCE inter-domain point-to-multipoint path
computation <xref target="RFC7334"/> procedure.</t> computation <xref target="RFC7334" format="default"/> procedure.</t>
</section>
</section> <section anchor="sect-10" numbered="true" toc="default">
<name>Optical Domains</name>
<section title="Optical Domains" anchor="sect-10"><t> <t>
The International Telecommunications Union (ITU) defines the ASON The International Telecommunication Union (ITU) defines the ASON
architecture in <xref target="G-8080"/>. <xref target="G-7715"/> defines the architecture in <xref target="G-8080" format="default"/>. <xref target="G-771
routing architecture 5" format="default"/> defines the routing architecture
for ASON and introduces a hierarchical architecture. In this for ASON and introduces a hierarchical architecture. In this
architecture, the Routing Areas (RAs) have a hierarchical architecture, the Routing Areas (RAs) have a hierarchical
relationship between different routing levels, which means a parent relationship between different routing levels, which means a parent
(or higher level) RA can contain multiple child RAs. The (or higher level) RA can contain multiple child RAs. The
interconnectivity of the lower RAs is visible to the higher-level RA.</t> interconnectivity of the lower RAs is visible to the higher-level RA.</t>
<t>
<t> In the ASON framework, a path computation request is termed a route
In the ASON framework, a path computation request is termed a Route query. This query is executed before signaling is used to establish
Query. This query is executed before signaling is used to establish an LSP, which is termed a Switched Connection (SC) or a Soft Permanent
an LSP termed a Switched Connection (SC) or a Soft Permanent Connection (SPC).
Connection (SPC). <xref target="G-7715-2"/> defines the requirements and <xref target="G-7715-2" format="default"/> defines the requirements and
architecture for the functions performed by Routing Controllers (RC) architecture for the functions performed by Routing Controllers (RC)
during the operation of remote route queries - an RC is synonymous during the operation of remote route queries. An RC is synonymous
with a PCE.</t> with a PCE.</t>
<t>
<t>
In the ASON routing environment, an RC responsible for an RA may In the ASON routing environment, an RC responsible for an RA may
communicate with its neighbor RC to request the computation of an communicate with its neighbor RC to request the computation of an
end-to-end path across several RAs. The path computation components end-to-end path across several RAs. The path computation components
and sequences are defined as follows:</t> and sequences are defined as follows:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Remote route query. An operation where a rout <li>Remote route query. An operation where a Routing Controller
ing controller communicates with another Routing Controller, which does not have
communicates with another routing controller, which does not have
the same set of layer resources, in order to compute a routing the same set of layer resources, in order to compute a routing
path in a collaborative manner.</t> path in a collaborative manner.</li>
<li>Route query requester. The connection controller or RC that sends a
<t>Route query requester. The connection controller or RC that sends a route query message to a Routing Controller that requests one or
route query message to a routing controller requesting for one or more routing paths satisfying a set of routing constraints.</li>
more routing paths that satisfy a set of routing constraints.</t>
<t>Route query responder. An RC that performs path computation upon
reception of a route query message from a routing controller or
connection controller, sending a response back at the end of
computation.</t>
</list>
</t>
<t> <li>Route query responder. An RC that performs the path computation
upon reception of a route query message from a Routing Controller or
connection controller, and sends a response back at the end of the
computation.</li>
</ul>
<t>
When computing an end-to-end connection, the route may be computed by When computing an end-to-end connection, the route may be computed by
a single RC or multiple RCs in a collaborative manner and the two a single RC or multiple RCs in a collaborative manner, and the two
scenarios can be considered a centralized remote route query model scenarios can be considered a centralized remote route query model
and distributed remote route query model. RCs in an ASON environment and a distributed remote route query model. RCs in an ASON environment
can also use the hierarchical PCE <xref target="RFC6805"/> model to match ful can also use the hierarchical PCE <xref target="RFC6805" format="default"/>
ly the model to fully match the
ASON hierarchical routing model.</t> ASON hierarchical routing model.</t>
<section anchor="sect-10.1" numbered="true" toc="default">
<section title="Abstraction and Control of TE Networks (ACTN)" anchor="se <name>Abstraction and Control of TE Networks (ACTN)</name>
ct-10.1"><t> <t>
Where a single operator operates multiple TE domains (including Where a single operator operates multiple TE domains (including
optical environments) then Abstraction and Control of TE Networks optical environments), an Abstraction and Control of TE Networks
(ACTN) framework <xref target="RFC8453"/> may be used to create an abstracted (ACTN) framework <xref target="RFC8453" format="default"/> may be used to cre
(virtualized network) view of underlay interconnected domains. This ate an abstracted
underlay connectivity then be exposed to higher-layer control (virtualized network) view of underlay-interconnected domains. This
underlay connectivity is then exposed to higher-layer control
entities and applications.</t> entities and applications.</t>
<t>
<t>
ACTN describes the method and procedure for coordinating the ACTN describes the method and procedure for coordinating the
underlay per-domain Physical Network Controllers (PNCs), which may underlay per-domain Provisioning Network Controllers (PNCs), which may
be PCEs, via a hierarchical model to facilitate setup of be PCEs, via a hierarchical model to facilitate setup of
end-to-end connections across inter-connected TE domains.</t> end-to-end connections across interconnected TE domains.</t>
</section>
</section> </section>
<section anchor="sect-11" numbered="true" toc="default">
</section> <name>Policy</name>
<t>
<section title="Policy" anchor="sect-11"><t>
Policy is important in the deployment of new services and the Policy is important in the deployment of new services and the
operation of the network. <xref target="RFC5394"/> provides a framework for P operation of the network. <xref target="RFC5394" format="default"/> provides
CE- a framework for PCE-based policy-enabled path computation. This framework is bas
based policy-enabled path computation. This framework is based on ed on
the Policy Core Information Model (PCIM) as defined in <xref target="RFC3060" the Policy Core Information Model (PCIM) as defined in <xref target="RFC3060"
/> and format="default"/> and
further extended by <xref target="RFC3460"/>.</t> further extended by <xref target="RFC3460" format="default"/>.</t>
<t>
<t>
When using a PCE to compute inter-domain paths, policy may be When using a PCE to compute inter-domain paths, policy may be
invoked by specifying:</t> invoked by specifying the following:</t>
<ul spacing="normal">
<t><list style="symbols"><t>Each PCC must select which computations will <li>Each PCC must select which computations it will request from a PCE.<
be requested to a PCE;</t> /li>
<li>Each PCC must select which PCEs it will use.</li>
<t>Each PCC must select which PCEs it will use;</t> <li>Each PCE must determine which PCCs are allowed to use its services
and for what computations.</li>
<t>Each PCE must determine which PCCs are allowed to use its services <li>The PCE must determine how to collect the information in its TED,
and for what computations;</t>
<t>The PCE must determine how to collect the information in its TED,
whom to trust for that information, and how to refresh/update the whom to trust for that information, and how to refresh/update the
information;</t> information.</li>
<li>Each PCE must determine which objective functions and algorithms to
<t>Each PCE must determine which objective functions and which apply.</li>
algorithms to apply.</t> </ul>
</section>
</list> <section anchor="sect-12" numbered="true" toc="default">
</t> <name>Manageability Considerations</name>
<t>
</section> General PCE management considerations are discussed in <xref target="RFC4655"
format="default"/>.
<section title="Manageability Considerations" anchor="sect-12"><t>
General PCE management considerations are discussed in <xref target="RFC4655"
/>.
In the case of multi-domains within a single service provider In the case of multi-domains within a single service provider
network, the management responsibility for each PCE would most network, the management responsibility for each PCE would most
likely be handled by the same service provider. In the case of likely be handled by the same service provider. In the case of
multiple ASes within different service provider networks, it will multiple ASes within different service provider networks, it will
likely be necessary for each PCE to be configured and managed likely be necessary for each PCE to be configured and managed
separately by each participating service provider, with policy separately by each participating service provider, with policy
being implemented based on a previously agreed set of principles.</t> being implemented based on a previously agreed set of principles.</t>
<section anchor="sect-12.1" numbered="true" toc="default">
<section title="Control of Function and Policy" anchor="sect-12.1"><t> <name>Control of Function and Policy</name>
As per PCEP <xref target="RFC5440"/> implementation allow the user to configu <t>
re As per <xref target="RFC5440" format="default"/>, PCEP implementation allows
a number of PCEP session parameters. These are detailed in section the user to configure
8.1 of <xref target="RFC5440"/>.</t> a number of PCEP session parameters. These are detailed in <xref target="RFC5
440" section="8.1" sectionFormat="of"/>.</t>
<t> <t>
In H-PCE deployments the administrative entity responsible for the In H-PCE deployments, the administrative entity responsible for the
management of the parent PCEs for multi-areas would typically be a management of the parent PCEs for multi-areas would typically be a
single service provider. In the multiple ASes (managed by different single service provider. In multiple ASes (managed by different
service providers), it may be necessary for a third party to manage service providers), it may be necessary for a third party to manage
the parent PCE.</t> the parent PCE.</t>
</section>
</section> <section anchor="sect-12.2" numbered="true" toc="default">
<name>Information and Data Models</name>
<section title="Information and Data Models" anchor="sect-12.2"><t> <t>
A PCEP MIB module is defined in <xref target="RFC7420"/> that describes manag A PCEP MIB module is defined in <xref target="RFC7420" format="default"/>,
ed which describes managed
objects for modeling of PCEP communication including:</t> objects for modeling PCEP communication, including:</t>
<ul spacing="normal">
<t><list style="symbols"><t>PCEP client configuration and status,</t> <li>PCEP client configuration and status.</li>
<li>PCEP peer configuration and information.</li>
<t>PCEP peer configuration and information,</t> <li>PCEP session configuration and information.</li>
<li>Notifications to indicate PCEP session changes.</li>
<t>PCEP session configuration and information,</t> </ul>
<t>
<t>Notifications to indicate PCEP session changes.</t> A YANG module for PCEP has also been proposed <xref target="I-D.ietf-pce-pcep
-yang" format="default"/>.</t>
</list> <t>
</t> An H-PCE MIB module or YANG data model will be required to
<t>
A YANG module for PCEP has also been proposed <xref target="PCEP-YANG"/>.</t>
<t>
An H-PCE MIB module, or YANG data model, will be required to
report parent PCE and child PCE information, including:</t> report parent PCE and child PCE information, including:</t>
<ul spacing="normal">
<t><list style="symbols"><t>parent PCE configuration and status,</t> <li>Parent PCE configuration and status.</li>
<li>Child PCE configuration and information.</li>
<t>child PCE configuration and information,</t> <li>Notifications to indicate session changes between parent PCEs and
child PCEs.</li>
<t>notifications to indicate session changes between parent PCEs and <li>Notification of parent PCE TED updates and changes.</li>
child PCEs, and</t> </ul>
</section>
<t>notification of parent PCE TED updates and changes.</t> <section anchor="sect-12.3" numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
</list> <t>
</t>
</section>
<section title="Liveness Detection and Monitoring" anchor="sect-12.3"><t>
PCEP includes a keepalive mechanism to check the liveliness of a PCEP PCEP includes a keepalive mechanism to check the liveliness of a PCEP
peer and a notification procedure allowing a PCE to advertise its peer and a notification procedure allowing a PCE to advertise its
overloaded state to a PCC. In a multi-domain environment <xref target="RFC588 6"/> overloaded state to a PCC. In a multi-domain environment, <xref target="RFC58 86" format="default"/>
provides the procedures necessary to monitor the liveliness and provides the procedures necessary to monitor the liveliness and
performances of a given PCE chain.</t> performance of a given PCE chain.</t>
</section>
</section> <section anchor="sect-12.4" numbered="true" toc="default">
<name>Verifying Correct Operation</name>
<section title="Verifying Correct Operation" anchor="sect-12.4"><t> <t>
It is important to verify the correct operation of PCEP, <xref target="RFC544 It is important to verify the correct operation of PCEP. <xref target="RFC544
0"/> 0" format="default"/>
specifies the monitoring of key parameters. These parameters are specifies the monitoring of key parameters. These parameters are
detailed in <xref target="RFC5520"/>.</t> detailed in <xref target="RFC5520" format="default"/>.</t>
</section>
</section> <section anchor="sect-12.5" numbered="true" toc="default">
<name>Impact on Network Operation</name>
<section title="Impact on Network Operation" anchor="sect-12.5"><t> <t>
<xref target="RFC5440"/> states that in order to avoid any unacceptable impac <xref target="RFC5440" format="default"/> states that in order to avoid any u
t on nacceptable impact on
network operations, a PCEP implementation should allow a limit to be network operations, a PCEP implementation should allow a limit to be
placed on the number of sessions that can be set up on a PCEP placed on the number of sessions that can be set up on a PCEP
speaker, it may also be practical to place a limit on the rate speaker and that it may also be practical to place a limit on the rate
of messages sent by a PCC and received my the PCE.</t> of messages sent by a PCC and received by the PCE.</t>
</section>
</section> </section>
<section anchor="sect-13" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>
<section title="Security Considerations" anchor="sect-13"><t> PCEP security considerations are discussed in <xref target="RFC5440" format="
PCEP Security considerations are discussed in <xref target="RFC5440"/> and <x default"/> and <xref target="RFC6952" format="default"/>.
ref target="RFC6952"/> Potential vulnerabilities include spoofing, snooping, falsification,
Potential vulnerabilities include spoofing, snooping, falsification
and using PCEP as a mechanism for denial of service attacks.</t> and using PCEP as a mechanism for denial of service attacks.</t>
<t>
<t>
As PCEP operates over TCP, it may make use of TCP security As PCEP operates over TCP, it may make use of TCP security
encryption mechanisms, such as Transport Layer Security (TLS) and TCP encryption mechanisms, such as Transport Layer Security (TLS) and TCP
Authentication Option (TCP-AO). Usage of these security mechanisms Authentication Option (TCP-AO). Usage of these security mechanisms
for PCEP is described in <xref target="RFC8253"/>, and recommendations and be for PCEP is described in <xref target="RFC8253" format="default"/>, and recom
st mendations and best
current practices in <xref target="RFC7525"/>.</t> current practices are described in <xref target="RFC7525" format="default"/>.
</t>
<section title="Multi-domain Security" anchor="sect-13.1"><t> <section anchor="sect-13.1" numbered="true" toc="default">
<name>Multi-domain Security</name>
<t>
Any multi-domain operation necessarily involves the exchange of Any multi-domain operation necessarily involves the exchange of
information across domain boundaries. This does represent information across domain boundaries. This represents a
significant security and confidentiality risk.</t> significant security and confidentiality risk.</t>
<t>
<t> It is expected that PCEP is used between PCCs and PCEs that belong to the
It is expected that PCEP is used between PCCs and PCEs belonging to same administrative authority while also using one of the aforementioned
the same administrative authority, and using one of the encryption mechanisms.
aforementioned encryption mechanisms. Furthermore, PCEP allows Furthermore, PCEP allows
individual PCEs to maintain confidentiality of their domain path individual PCEs to maintain the confidentiality of their domain path
information using path-keys.</t> information using path-keys.</t>
</section>
</section>
<section anchor="sect-14" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.</t>
</section>
</section> </middle>
<back>
</section>
<section title="IANA Considerations" anchor="sect-14"><t>
This document makes no requests for IANA action.</t>
</section>
<section title="Acknowledgements" anchor="sect-15"><t> <displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
The author would like to thank Adrian Farrel for his review, and
Meral Shirazipour and Francisco Javier Jimenex Chico for their
comments.</t>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3209.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3473.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4216.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4655.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4726.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5152.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5440.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5441.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5520.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5541.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6805.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3060.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3460.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3630.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4090.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4203.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4920.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5088.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5089.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5305.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5307.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5316.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5392.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5394.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5521.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5886.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6007.xml"/>
</middle> <!-- [G-8080] URL https://www.itu.int/rec/T-REC-G.8080-201202-I/en -->
<back> <reference anchor="G-8080">
<references title="Normative References"> <front>
&RFC3209; <title>Architecture for the automatically switched optical network</
&RFC3473; title>
&RFC4216; <seriesInfo name="ITU-T Recommendation" value="G.8080/Y.1304"/>
&RFC4655; <author>
&RFC4726; <organization>ITU-T</organization>
&RFC5152; </author>
&RFC5440; <date month="February" year="2012"/>
&RFC5441; </front>
&RFC5520; </reference>
&RFC5541;
&RFC6805;
</references>
<references title="Informative References">
&RFC3060;
&RFC3460;
&RFC3630;
&RFC4090;
&RFC4203;
&RFC4920;
&RFC5088;
&RFC5089;
&RFC5305;
&RFC5307;
&RFC5316;
&RFC5392;
&RFC5394;
&RFC5521;
&RFC5886;
&RFC6007;
<reference anchor="G-8080"><front>
<title>Architecture for the automatically switched optical network (ASON)
</title>
<author>
<organization>ITU-T Recommendation G.8080/Y.1304</organization>
</author>
<date/>
</front>
</reference> <!-- [G-7715] URL https://datatracker.ietf.org/documents/LIAISON/G-7715.htm -->
<reference anchor="G-7715"><front> <!-- this reference has been updated per
<title>Architecture and Requirements for the Automatically Switched Optic https://www.itu.int/rec/T-REC-G.7715/en.
al Network (ASON)</title> -->
<author> <reference anchor="G-7715">
<organization>ITU-T Recommendation G.7715 (2002)</organization> <front>
</author> <title>Architecture and requirements for routing in the
<date/> automatically switched optical networks</title>
</front> <seriesInfo name="ITU-T Recommendation" value="G.7715/Y.1706" />
<author>
<organization>ITU-T</organization>
</author>
<date month="June" year="2002"/>
</front>
</reference>
</reference> <!-- [G-7715-2] https://www.itu.int/rec/T-REC-G.7715.2-200702-I/en -->
<reference anchor="G-7715-2"><front>
<title>ASON routing architecture and requirements for remote route query<
/title>
<author>
<organization>ITU-T Recommendation G.7715.2 (2007)</organization>
</author>
<date/>
</front>
</reference> <reference anchor="G-7715-2">
&RFC6952; <front>
&RFC7334; <title>ASON routing architecture and requirements for remote route
&RFC7420; query</title>
&RFC7525; <seriesInfo name="ITU-T Recommendation" value="G.7715.2/Y.1706.2"/>
&RFC7752; <author>
&RFC7897; <organization>ITU-T</organization>
&RFC8253; </author>
&RFC8453; <date month="February" year="2007"/>
<reference anchor="PCEP-YANG"><front> </front>
<title>A YANG Data Model for Path Computation Element Communications Prot </reference>
ocol (PCEP)</title>
<author fullname="D. Dhody" initials="D." surname="Dhody">
</author>
<author fullname="J. Hardwick" initials="J." surname="Hardwick"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</author> ence.RFC.6952.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7334.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7420.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7752.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7897.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8253.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8453.xml"/>
<author fullname="V. Beeram" initials="V." surname="Beeram"> <!-- draft-ietf-pce-pcep-yang-13: I-D exists -->
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-pce-pcep-yang.xml"/>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"> </references>
</author> </references>
<date month="October" year="2018"/> <section anchor="acks" numbered="false" toc="default">
</front> <name>Acknowledgements</name>
<t>
The author would like to thank <contact fullname="Adrian Farrel"/> for his
review and <contact fullname="Meral Shirazipour"/> and <contact
fullname="Francisco Javier Jiménez Chico" /> for their comments.</t>
</section>
<seriesInfo name="work" value="in progress"/> <section anchor="contributors" numbered="false" toc="default">
</reference> <name>Contributors</name>
</references>
<section title="Contributors" anchor="sect-17"><figure><artwork><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Quintin Zhao <contact fullname="Dhruv Dhody" >
Huawei Technology <organization>Huawei Technologies</organization>
125 Nagog Technology Park <address>
Acton, MA 01719 <postal>
US <street>Divyashree Techno Park, Whitefield</street>
Email: qzhao@huawei.com <city>Bangalore</city>
<region>Karnataka</region><code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
Julien Meuric <contact fullname="Quintin Zhao">
France Telecom <organization>Huawei Technologies</organization>
2, avenue Pierre-Marzin <address>
22307 Lannion Cedex <postal>
Email: julien.meuric@orange-ftgroup.com <street>125 Nagog Technology Park</street>
<city>Acton</city>
<region>MA</region><code>01719</code>
<country>United States of America</country>
</postal>
<email>qzhao@huawei.com</email>
</address>
</contact>
Olivier Dugeon <contact fullname="Julien Meuric">
France Telecom <organization>France Telecom</organization>
2, avenue Pierre-Marzin <address>
22307 Lannion Cedex <postal>
Email: olivier.dugeon@orange-ftgroup.com <street>2, avenue Pierre-Marzin</street>
<city>Lannion Cedex</city><code>22307</code>
<country>France</country>
</postal>
<email>julien.meuric@orange.com</email>
</address>
</contact>
Jon Hardwick <contact fullname="Olivier Dugeon">
Metaswitch Networks <organization>France Telecom</organization>
100 Church Street <address>
Enfield, Middlesex <postal>
United Kingdom <street>2, avenue Pierre-Marzin</street>
Email: jonathan.hardwick@metaswitch.com <city>Lannion Cedex</city><code>22307</code>
<country>France</country>
</postal>
<email>olivier.dugeon@orange.com</email>
</address>
</contact>
Oscar Gonzalez de Dios <contact fullname="Jon Hardwick" >
Telefonica I+D <organization>Metaswitch Networks</organization>
Emilio Vargas 6, Madrid <address>
Spain <postal>
Email: ogondio@tid.es <street>100 Church Street</street>
]]></artwork> <city>Enfield</city>
</figure> <code>EN2 6BQ</code>
</section> <country>United Kingdom</country>
</postal>
<email>jonathan.hardwick@metaswitch.com</email>
</address>
</contact>
<section title="Author's Addresses" anchor="sect-18"/> <contact fullname="Óscar González de Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Emilio Vargas 6</street>
<city>Madrid</city>
<country>Spain</country>
</postal>
<email>oscar.gonzalezdedios@telefonica.com</email>
</address>
</contact>
</back> </section>
</back>
</rfc> </rfc>
 End of changes. 175 change blocks. 
974 lines changed or deleted 919 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/