draft-ietf-pce-inter-area-as-applicability-08.txt   rfc8694.txt 
PCE Working Group D. King
Internet Draft Old Dog Consulting
Intended status: Informational H. Zheng
Expires: January 9, 2020 Huawei Technologies
July 8, 2019
Applicability of the Path Computation Element to Inter-Area and Internet Engineering Task Force (IETF) D. King
Inter-AS MPLS and GMPLS Traffic Engineering Request for Comments: 8694 Old Dog Consulting
Category: Informational 郑好棉 (H. Zheng)
ISSN: 2070-1721 华为技术有限公司 (Huawei Technologies)
December 2019
draft-ietf-pce-inter-area-as-applicability-08 Applicability of the Path Computation Element to Inter-area and Inter-AS
MPLS and GMPLS Traffic Engineering
Abstract Abstract
The Path Computation Element (PCE) may be used for computing services The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-AS Multiprotocol Label Switching that traverse multi-area and multi-Autonomous System (multi-AS)
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic-Engineered (TE) networks.
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. multi-AS paths in MPLS and GMPLS networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on January 9, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8694.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Introduction.................................................3 Table of Contents
1.1. Domains.................................................4
1.2. Path Computation........................................4
1.2.1 PCE-based Path Computation Procedure.................5
1.3. Traffic Engineering Aggregation and Abstraction.........6
1.4. Traffic Engineered Label Switched Paths.................6
1.5. Inter-area and Inter-AS Capable PCE Discovery...........6
1.6. Objective Functions.....................................6
2. Terminology..................................................7
3. Issues and Considerations....................................7
3.1 Multi-homing.............................................7
3.2 Destination Location.....................................8
3.3 Domain Confidentiality ..................................8
4. Domain Topologies............................................8
4.1 Selecting Domain Paths...................................8
4.2 Domain Sizes.............................................9
4.3 Domain Diversity.........................................9
4.4 Synchronized Path Computations...........................9
4.5 Domain Inclusion or Exclusion............................9
5. Applicability of the PCE to Inter-area Traffic Engineering...10
5.1. Inter-area Routing......................................11
5.1.1. Area Inclusion and Exclusion..........................11
5.1.2. Strict Explicit Path and Loose Path...................11
5.1.3. Inter-Area Diverse Path Computation...................11
6. Applicability of the PCE to Inter-AS Traffic Engineering.....12
6.1. Inter-AS Routing........................................12
6.1.1. AS Inclusion and Exclusion............................12
6.2. Inter-AS Bandwidth Guarantees...........................12
6.3. Inter-AS Recovery.......................................13
6.4. Inter-AS PCE Peering Policies...........................13
7. Multi-Domain PCE Deployment..................................13
7.1 Traffic Engineering Database.............................13
7.1.1. Applicability of BGP-LS to PCE........................14
7.2 Pre-Planning and Management-Based Solutions..............14
8. Domain Confidentiality.......................................15
8.1 Loose Hops...............................................15
8.2 Confidential Path Segments and Path Keys.................15
9. Point-to-Multipoint..........................................16
10. Optical Domains.............................................16
10.1 Abstraction and Control of TE Networks (ACTN)...........17
11. Policy......................................................17
12. Manageability Considerations................................18
12.1 Control of Function and Policy...........................18
12.2 Information and Data Models..............................18
12.3 Liveness Detection and Monitoring........................19
12.4 Verifying Correct Operation..............................19
12.5 Impact on Network Operation..............................19
13. Security Considerations.....................................19
13.1 Multi-domain Security....................................19
14. IANA Considerations.........................................20
15. Acknowledgements............................................20
16. References..................................................20
16.1. Normative References....................................20
16.2. Informative References..................................21
17. Contributors................................................24
18. Author's Addresses..........................................25
1. Introduction 1. Introduction
1.1. Domains
1.2. Path Computation
1.2.1. PCE-Based Path Computation Procedure
1.3. Traffic Engineering Aggregation and Abstraction
1.4. Traffic-Engineered Label Switched Paths
1.5. Inter-area and Inter-AS-capable PCE Discovery
1.6. Objective Functions
2. Terminology
3. Issues and Considerations
3.1. Multihoming
3.2. Destination Location
3.3. Domain Confidentiality
4. Domain Topologies
4.1. Selecting Domain Paths
4.2. Domain Sizes
4.3. Domain Diversity
4.4. Synchronized Path Computations
4.5. Domain Inclusion or Exclusion
5. Applicability of the PCE to Inter-area Traffic Engineering
5.1. Inter-area Routing
5.1.1. Area Inclusion and Exclusion
5.1.2. Strict Explicit Path and Loose Path
5.1.3. Inter-Area Diverse Path Computation
6. Applicability of the PCE to Inter-AS Traffic Engineering
6.1. Inter-AS Routing
6.1.1. AS Inclusion and Exclusion
6.2. Inter-AS Bandwidth Guarantees
6.3. Inter-AS Recovery
6.4. Inter-AS PCE Peering Policies
7. Multi-domain PCE Deployment Options
7.1. Traffic Engineering Database and Synchronization
7.1.1. Applicability of BGP-LS to PCE
7.2. Pre-planning and Management-Based Solutions
8. Domain Confidentiality
8.1. Loose Hops
8.2. Confidential Path Segments and Path-Keys
9. Point to Multipoint
10. Optical Domains
10.1. Abstraction and Control of TE Networks (ACTN)
11. Policy
12. Manageability Considerations
12.1. Control of Function and Policy
12.2. Information and Data Models
12.3. Liveness Detection and Monitoring
12.4. Verifying Correct Operation
12.5. Impact on Network Operation
13. Security Considerations
13.1. Multi-domain Security
14. IANA Considerations
15. References
15.1. Normative References
15.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Computing paths across large multi-domain environments may 1. Introduction
require special computational components and cooperation between
entities in different domains capable of complex path computation.
Issues that may exist when routing in multi-domain networks include: Computing paths across large multi-domain environments may require
special computational components and cooperation between entities in
different domains capable of complex path computation.
o Often there is a lack of full topology and TE information across Issues that may exist when routing in multi-domain networks include
domains; the following:
o No single node has the full visibility to determine an optimal or
even feasible end-to-end path across domains;
o How to evaluate and select the exit point and next domain boundary
from a domain?
o How might the ingress node determine which domains should be used
for the end-to-end path?
Often information exchange across multiple domains is limited due to * There is often a lack of full topology and TE information across
the lack of trust relationship, security issues, or scalability domains.
issues even if there is a trust relationship between domains.
* No single node has the full visibility to determine an optimal or
even feasible end-to-end path across domains.
* Knowing how to evaluate and select the exit point and next domain
boundary from a domain.
* Understanding how the ingress node determines which domains should
be used for the end-to-end path.
An information exchange across multiple domains is often limited due
to the lack of trust relationship, security issues, or scalability
issues, even if there is a trust relationship between domains.
The Path Computation Element (PCE) [RFC4655] provides an architecture The Path Computation Element (PCE) [RFC4655] provides an architecture
and a set of functional components to address the problem space, and and a set of functional components to address the problem space and
issues highlighted above. the issues highlighted above.
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 [RFC5152]. environments using a per-domain path computation technique [RFC5152].
The so called backward recursive path computation (BRPC) mechanism The so-called backward recursive PCE-based computation (BRPC)
[RFC5441] defines a PCE-based path computation procedure to compute mechanism [RFC5441] defines a path computation procedure 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. fixed by the network operator or obtained by other means.
In more advanced deployments (including multi-area and multi- In more advanced deployments (including multi-area and multi-
Autonomous System (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- may not be known in advance, and the choice of domains in the end-to-
end 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
[RFC6805] architecture and mechanisms may be used to discover the PCE [RFC6805] architecture and mechanisms may be used to discover the
intra-area path and select the optimal end-to-end domain sequence. intra-area path and select the optimal end-to-end domain sequence.
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
and inter-AS MPLS and GMPLS Traffic Engineered paths. inter-AS MPLS and GMPLS Traffic-Engineered paths.
This document scope does not include discussion on stateful PCE, The scope of this document does not include discussions of deployment
active PCE, remotely initiated PCE, or PCE as a central controller scenarios for stateful PCE, active PCE, remotely initiated PCE, or
(PCECC) deployment scenarios. PCE as a central controller (PCECC).
1.1 Domains 1.1. Domains
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
(as per [RFC4726] and [RFC4655]). per [RFC4726] and [RFC4655]).
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
common sphere of address management or path computational sphere of address management or path computational responsibility.
responsibility. Wholly or partially overlapping domains are not Wholly or partially overlapping domains are not within the scope of
within the scope of this document. this document.
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
[G-8080]. In this case, computation of an end-to-end path requires [G-8080]. 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
ASON routing area [G-7715]. A PCE may perform the path computation an ASON routing area [G-7715]. A PCE may perform the path
function of an ASON routing controller as described in [G-7715-2]. computation function of an ASON Routing Controller as described in
[G-7715-2].
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. group of domains, such as the Internet.
1.2 Path Computation 1.2. Path Computation
For the purpose of this document, it is assumed that the
path computation is the sole responsibility of the PCE as per the For the purpose of this document, it is assumed that path computation
architecture defined in [RFC4655]. When a path is required the Path is the sole responsibility of the PCE as per the architecture defined
Computation Client (PCC) will send a request to the PCE. The PCE in [RFC4655]. When a path is required, the Path Computation Client
will apply the required constraints and compute a path and return a (PCC) will send a request to the PCE. The PCE will apply the
response to the PCC. In the context of this document it may be required constraints, compute a path, and return a response to the
necessary for the PCE to co-operate with other PCEs in adjacent PCC. In the context of this document, it may be necessary for the
domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE PCE to cooperate with other PCEs in adjacent domains (as per BRPC
(as per [RFC6805]). [RFC5441]) or with a parent PCE (as per [RFC6805]).
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. discovered and applied is outside the scope of this document.
1.2.1 PCE-based Path Computation Procedure 1.2.1. PCE-Based Path Computation Procedure
As highlighted, the PCE is an entity capable of computing an As highlighted, the PCE is an entity capable of computing an inter-
inter-domain TE path upon receiving a request from a PCC. There could domain TE path upon receiving a request from a PCC. There could be a
be a single PCE per domain, or single PCE responsible for all single PCE per domain or a single PCE responsible for all domains. A
domains. A PCE may or may not reside on the same node as the PCE may or may not reside on the same node as the requesting PCC. A
requesting PCC. A path may be computed by either a single PCE node path may be computed by either a single PCE node or a set of
or a set of distributed PCE nodes that collaborate during path distributed PCE nodes that collaborate during path computation.
computation.
[RFC4655] defines that a PCC should send a path computation request According to [RFC4655], a PCC should send a path computation request
to a particular PCE, using [RFC5440] (PCC-to-PCE communication). to a particular PCE using [RFC5440] (PCC-to-PCE communication). This
This negates the need to broadcast a request to all the PCEs. Each negates the need to broadcast a request to all the PCEs. Each PCC
PCC can maintain information about the computation capabilities can maintain information about the computation capabilities of the
of the PCEs, it is aware of. The PCC-PCE capability awareness can be 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. PCE discovery procedures.
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
if it is aware of the topology and TE information required to is aware of the topology and TE information required to compute the
compute the entire path. If the PCE is unable to compute the entire path. If the PCE is unable to compute the entire path, the
entire path, the PCE architecture provides co-operative PCE PCE architecture provides cooperative PCE mechanisms for the
mechanisms for the resolution of path computation requests when an resolution of path computation requests when an individual PCE does
individual PCE does not have sufficient TE visibility. not have sufficient TE visibility.
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.
information. A path key that is a token that replaces a path segment A Path-Key is a token that replaces a path segment in an explicit
in an explicit route. The path key mechanism is described in route. The Path-Key mechanism is described in [RFC5520].
[RFC5520]
1.3 Traffic Engineering Aggregation and Abstraction 1.3. Traffic Engineering Aggregation and Abstraction
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
network confidentiality and scalability TE properties of each area confidentiality and scalability, the TE properties of each area and
and AS are not generally advertized outside each specific area or AS. AS are not generally advertised outside each specific area or AS.
TE aggregation or abstraction provide mechanism to hide information TE aggregation or abstraction provide a mechanism to hide information
but may cause failed path setups or the selection of suboptimal but may cause failed path setups or the selection of suboptimal end-
end-to-end paths [RFC4726]. The aggregation process may also have to-end paths [RFC4726]. The aggregation process may also have
significant scaling issues for networks with many possible routes significant scaling issues for networks with many possible routes and
and multiple TE metrics. Flooding TE information breaks multiple TE metrics. Flooding TE information breaks confidentiality
confidentiality and does not scale in the routing protocol. and does not scale in the routing protocol.
The PCE architecture and associated mechanisms provide a solution The PCE architecture and associated mechanisms provide a solution to
to avoid the use of TE aggregation and abstraction. avoid the use of TE aggregation and abstraction.
1.4 Traffic Engineered Label Switched Paths 1.4. Traffic-Engineered Label Switched Paths
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)
(inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and across multiple areas (inter-area TE LSP) and ASes (inter-AS TE LSP).
within the remainder of this document, we consider all LSPs to be In this context and within the remainder of this document, we
constraint-based and traffic engineered. consider all LSPs to be constraint based and traffic engineered.
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 [RFC4726]: inter-AS LSP [RFC4726]:
o Contiguous LSP * Contiguous LSP
o Stitched LSP
o Nested LSP * Stitched LSP
* Nested LSP
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. procedures discussed in this document.
1.5 Inter-area and Inter-AS Capable PCE Discovery 1.5. Inter-area and Inter-AS-capable PCE Discovery
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 [RFC5088] and [RFC5089] facilitates discovery mechanism defined in [RFC5088] and [RFC5089] facilitates
the discovery of PCEs, and disclosure of information related to the discovery of PCEs and disclosure of information related to inter-
inter-area and inter-AS capable PCEs. area and inter-AS-capable PCEs.
1.6 Objective Functions 1.6. Objective Functions
An Objective Function (OF) [RFC5541], or set of OFs, specifies the An Objective Function (OF) [RFC5541] or a set 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
in the context of the computation request. the context of the computation request.
An OF specifies the desired outcome of a computation. An OF does not An OF specifies the desired outcome of a computation. It 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
[RFC5541]. [RFC5541].
Various OFs may be included in the PCE computation request to Various OFs may be included in the PCE computation request to satisfy
satisfy the policies encoded or configured at the PCC, and a PCE the policies encoded or configured at the PCC, and a PCE may be
may be subject to policy in determining whether it meets the OFs subject to policy in determining whether it meets the OFs included in
included in the computation request or applies its own OFs. the computation request or whether it applies its own OFs.
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. OFs and policies.
2. Terminology 2. Terminology
This document also uses the terminology defined in [RFC4655] and This document also uses the terminology defined in [RFC4655] and
[RFC5440]. Additional terminology is defined below: [RFC5440]. Additional terminology is defined below:
ABR: IGP Area Border Router, a router that is attached to more than ABR: IGP Area Border Router -- a router that is attached to more
one IGP area. than one IGP area.
ASBR: Autonomous System Border Router, a router used to connect ASBR: Autonomous System Border Router -- a router used to connect
together ASes of a different or the same Service Provider via one or together ASes of a different or the same Service Provider via
more inter-AS links. one or more inter-AS links.
Inter-area TE LSP: A TE LSP whose path transits through two or more Inter-area TE LSP: A TE LSP whose path transits through two or more
IGP areas. IGP areas.
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or
more ASes or sub-ASes (BGP confederations more ASes or sub-ASes (BGP confederations)
SRLG: Shared Risk Link Group. SRLG: Shared Risk Link Group.
TED: Traffic Engineering Database, which contains the topology and TED: Traffic Engineering Database, which contains the topology and
resource information of the domain. The TED may be fed by Interior resource information of the domain. The TED may be fed by
Gateway Protocol (IGP) extensions or potentially by other means. Interior Gateway Protocol (IGP) extensions or potentially by
other means.
3. Issues and Considerations 3. Issues and Considerations
3.1 Multi-homing 3.1. Multihoming
Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid
a single point failure disrupting both primary and backup services.
3.2 Destination Location Networks constructed from multi-areas or multi-AS environments may
have multiple interconnect points (multihoming). End-to-end path
computations may need to use different interconnect points to avoid a
single-point failure disrupting both the primary and backup services.
The PCC asking for an inter-domain path computation is typically 3.2. Destination Location
aware of the identity of the destination node. If the PCC is aware
of the destination domain, it may supply the destination domain
information as part of the path computation request. However, if the
PCC does not know the destination domain this information must be
determined by another method.
3.3 Domain Confidentiality A PCC asking for an inter-domain path computation is typically aware
of the identity of the destination node. If the PCC is aware of the
destination domain, it may supply the destination domain information
as part of the path computation request. However, if the PCC does
not know the destination domain, this information must be determined
by another method.
Where the end-to-end path crosses multiple domains, it may be 3.3. Domain Confidentiality
possible that each domain (AS or area) are administered by separate
Service Providers, it would break confidentiality rules for a PCE When the end-to-end path crosses multiple domains, it may be possible
to supply a path segment to a PCE in another domain, thus disclosing that each domain (AS or area) is administered by separate Service
Providers. Thus, if a PCE supplies a path segment to a PCE in
another domain, it may break confidentiality rules and could disclose
AS-internal topology information. AS-internal topology information.
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
be able to see the individual hops through another domain. will be able to see the individual hops through another domain.
This topic is discussed further in Section 8 of this document. This topic is discussed further in Section 8 of this document.
4. Domain Topologies 4. Domain Topologies
Constraint-based inter-domain path computation is a fundamental Constraint-based inter-domain path computation is a fundamental
requirement for operating traffic engineered MPLS [RFC3209] and requirement for operating traffic-engineered MPLS [RFC3209] and GMPLS
GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain) [RFC3473] networks in inter-area and inter-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. PCE.
4.1 Selecting Domain Paths 4.1. Selecting Domain Paths
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
[RFC5152] technique may be used. Where there are multiple connections [RFC5152] technique may be used. Where there are multiple
between domains and there is no preference for the choice of points connections between domains and there is no preference for the choice
of interconnection, BRPC [RFC5441] can be used to derive an optimal of points of interconnection, BRPC [RFC5441] can be used to derive an
path. optimal path.
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-to-end path will have to navigate a mesh of small domains end path will have to navigate a mesh of small domains (especially
(especially typical in optical networks), the optimum path may be typical in optical networks), the optimum path may be derived through
derived through the application of a Hierarchical PCE [RFC6805]. the application of a hierarchical PCE [RFC6805].
4.2 Domain Sizes 4.2. Domain Sizes
Very frequently network domains are composed of dozens or hundreds of Very frequently, network domains are composed of dozens or hundreds
network elements. These network elements are usually interconnected of network elements. These network elements are usually
in a partial-mesh fashion, to provide survivability against dual interconnected in a partial-mesh fashion to provide survivability
failures, and to benefit from the traffic engineering capabilities against dual failures and to benefit from the traffic-engineering
from MPLS and GMPLS protocols. Network operator feedback in the capabilities of MPLS and GMPLS protocols. Network operator feedback
development of the document highlighted that node degree (the number in the development of the document highlighted that the node degree
of neighbors per node) typically ranges from 3 to 10 (4-5 is quite (the number of neighbors per node) typically ranges from 3 to 10 (4-5
common). is quite common).
4.3 Domain Diversity 4.3. Domain Diversity
Domain and path diversity may also be required when computing Domain and path diversity may also be required when computing end-to-
end-to-end paths. Domain diversity should facilitate the selection end paths. Domain diversity should facilitate the selection of paths
of paths that share ingress and egress domains, but do not share that share ingress and egress domains but do not share transit
transit domains. Therefore, there must be a method allowing the domains. Therefore, there must be a method allowing the inclusion or
inclusion or exclusion of specific domains when computing end-to-end exclusion of specific domains when computing end-to-end paths.
paths.
4.4 Synchronized Path Computations 4.4. Synchronized Path Computations
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. the capability of the PCE to perform synchronized path computation.
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
defined in [RFC5440] and [RFC6007] provides an overview for the in [RFC5440], and [RFC6007] provides an overview of the use of the
use of the PCE SVEC list for synchronized path computations when PCE SVEC list for synchronized path computations when computing
computing dependent requests. dependent requests.
In H-PCE deployments, a child PCE will be able to request both In hierarchical PCE (H-PCE) deployments, a child PCE will be able to
dependent and synchronized domain diverse end to end paths from its request both dependent and synchronized domain-diverse end-to-end
parent PCE. paths from its parent PCE.
4.5 Domain Inclusion or Exclusion 4.5. Domain Inclusion or Exclusion
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
Hierarchical PCE (H-PCE). of hierarchical PCE (H-PCE).
During multi-domain path computation, a PCC may request During multi-domain path computation, a PCC may request specific
specific domains to be included or excluded in the domain sequence domains to be included or excluded in the domain sequence using the
using the Include Route Object (IRO) [RFC5440] and Exclude Route Include Route Object (IRO) [RFC5440] and Exclude Route Object (XRO)
Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an [RFC5521]. The use of Autonomous Number (AS) as an abstract node
abstract node representing a domain is defined in [RFC3209]. representing a domain is defined in [RFC3209]. [RFC7897] specifies
[RFC7897] specifies new sub-objects to include or exclude domains new subobjects to include or exclude domains such as an IGP area or a
such as an IGP area or a 4-Byte AS number. 4-byte AS number.
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
Shared Risk Link Group (SRLG) information may be used to ensure Group (SRLG) information may be used to ensure path diversity.
path diversity.
5. Applicability of the PCE to Inter-area Traffic Engineering 5. Applicability of the PCE to Inter-area Traffic Engineering
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
flooded within the network and make the network more manageable. An within the network and make the network more manageable. An IGP
IGP hierarchy is designed to improve IGP scalability by dividing the hierarchy is designed to improve IGP scalability by dividing the IGP
IGP domain into areas and limiting the flooding scope of topology 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
be required to compute a path across area boundaries. required to compute a path across area boundaries.
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
data or control plane technologies cannot interoperate, it is useful or control-plane technologies cannot interoperate, it is useful to
to divide the network into vendor domains. Each vendor domain is divide the network into vendor domains. Each vendor domain is an IGP
an IGP area, and the flooding scope of the topology (as well as any area, and the flooding scope of the topology (as well as any other
other relevant information) is limited to the area boundaries. relevant information) is limited to the area boundaries.
Per-domain path computation [RFC5152] exists to provide a method of Per-domain path computation [RFC5152] exists to provide a method 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: using a constrained path. However, at least two issues exist:
o This method does not guarantee an optimal constrained path. * This method does not guarantee an optimal constrained path.
o The method may require several crankback signaling messages, as per * The method may require several crankback signaling messages, as
[RFC4920], increasing signaling traffic and delaying the LSP setup. per [RFC4920], increasing signaling traffic and delaying the LSP
setup.
The PCE-based architecture [RFC4655] is designed to solve inter-area PCE-based architecture [RFC4655] is designed to solve inter-area path
path computation problems. The issue of limited topology visibility computation problems. The issue of limited topology visibility is
is resolved by introducing path computation entities that are able to 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. located in different areas.
5.1. Inter-area Routing 5.1. Inter-area Routing
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
IGP areas. In a multi-area network, topology visibility remains areas. In a multi-area network, topology visibility remains local to
local to a given area for scaling and privacy purposes, a node a given area for scaling and privacy purposes. A node in one area
in one area will not be able to compute an end-to-end path across will not be able to compute an end-to-end path across multiple areas
multiple areas without the use of a PCE. without the use of a PCE.
5.1.1. Area Inclusion and Exclusion 5.1.1. Area Inclusion and Exclusion
The BRPC method [RFC5441] of path computation provides a more optimal The BRPC method [RFC5441] 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. the inter-area path computation.
5.1.2. Strict Explicit Path and Loose Path 5.1.2. Strict Explicit Path and Loose Path
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
path computation request, if a strict explicit path is required or explicit path is required during the path computation request. An
not. An inter-area path may be strictly explicit or loose (e.g., a inter-area path may be strictly explicit or loose (e.g., a list of
list of ABRs as loose hops). ABRs as loose hops).
A PCC request to a PCE does allow the indication of whether a strict A PCC request to a PCE does allow indication of whether a strict
explicit path across specific areas ([RFC7897]) is required or explicit path across specific areas ([RFC7897]) is required or
desired, or if the path request is loose. desired or whether the path request is loose.
5.1.3. Inter-Area Diverse Path Computation 5.1.3. Inter-Area Diverse Path Computation
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
a primary service with a corresponding backup service. There are primary service with a corresponding backup service. There are
various levels of diversity in the context of an inter-area network: various levels of diversity in the context of an inter-area network:
o Per-area diversity (intra-area path segments are link, node or * Per-area diversity (the intra-area path segments are a link, node,
SRLG disjoint. or SRLG disjoint).
o Inter-area diversity (end-to-end inter-area paths are link, * Inter-area diversity (the end-to-end inter-area paths are a link,
node or SRLG disjoint). node, or SRLG disjoint).
Note that two paths may be disjoint in the backbone area but non- Note that two paths may be disjointed in the backbone area but non-
disjoint in peripheral areas. Also, two paths may be node disjoint disjointed in peripheral areas. Also, two paths may be node
within areas but may share ABRs, in which case path segments within disjointed within areas but may share ABRs, in which case path
an area is node disjoint, but end-to-end paths are not node-disjoint. segments within an area are node disjointed but end-to-end paths are
Per-Domain [RFC5152], BRPC [RFC5441] and H-PCE [RFC6805] mechanisms not node disjointed. Per-domain [RFC5152], BRPC [RFC5441], and H-PCE
all support the capability to compute diverse paths across multi-area [RFC6805] mechanisms all support the capability to compute diverse
topologies. paths across multi-area topologies.
6. Applicability of the PCE to Inter-AS Traffic Engineering 6. Applicability of the PCE to Inter-AS Traffic Engineering
As discussed in section 4 (Applicability of the PCE to Inter-area As discussed in Section 5 (Applicability of the PCE to Inter-area
Traffic Engineering) it is necessary to divide the network into 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
to compute a path across an AS boundary, it must also use an inter-AS needs to compute a path across an AS boundary, it must also use an
computation technique. [RFC5152] defines mechanisms for the inter-AS computation technique. [RFC5152] defines mechanisms 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. signaling paths to compute per-domain constrained path segments.
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-
PCE-enabled solution for computing inter-AS paths. enabled solution for computing inter-AS paths.
6.1 Inter-AS Routing 6.1. Inter-AS Routing
6.1.1. AS Inclusion and Exclusion 6.1.1. AS Inclusion and Exclusion
[RFC5441] allows the specifying of inclusion or exclusion of an AS [RFC5441] allows the specification of AS or ASBR inclusion or
or an ASBR. Using this method, an operator might decide if an AS exclusion. Using this method, an operator might decide whether an AS
must be include or exclude from the inter-AS path computation. 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
the LSP path computation process by a PCE (within the BRPC LSP path computation process by a PCE (within the BRPC algorithm),
algorithm) but the best practice would be to specify them at the but the best practice would be to specify them at the edge. In
edge. In opposition to the strict and loose path, AS inclusion or opposition to the strict and loose path, AS inclusion or exclusion
exclusion doesn't impose topology disclosure as ASes are public doesn't impose topology disclosure as ASes and their interconnection
entity as well as their interconnection. are public entities.
6.2 Inter-AS Bandwidth Guarantees 6.2. Inter-AS Bandwidth Guarantees
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
on CE-PE links. In situations where strict QOS bounds are required, CE-PE links. In situations where strict QoS bounds are required,
admission control inside the network may also be required. admission control inside the network may also be required.
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 [RFC4216]. requirements are described in [RFC4216].
One typical example of the requirements in [RFC4216] is to provide One typical example of the requirements in [RFC4216] is to provide
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-
network. In the case where the EF path is extended across multiple enabled network. In cases where the EF path is extended across
ASes, inter-AS bandwidth guarantee would be required. multiple ASes, an inter-AS bandwidth guarantee would be required.
Another case for inter-AS bandwidth guarantee is the requirement for Another case for an inter-AS bandwidth guarantee is the requirement
guaranteeing a certain amount of transit bandwidth across one or to guarantee a certain amount of transit bandwidth across one or
multiple ASes. multiple ASes.
6.3 Inter-AS Recovery 6.3. Inter-AS Recovery
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,
1+1 protection. A single LSP or multiple backup LSPs may also be such as 1+1 protection. A single LSP or multiple backup LSPs may
used for a group of primary LSPs, this is typically known as m:n also be used for a group of primary LSPs; this is typically known as
protection. m:n protection.
Other inter-AS recovery mechanisms include [RFC4090] which adds fast Other inter-AS recovery mechanisms include [RFC4090], which adds Fast
re-route (FRR) protection to an LSP. So, the PCE could be used to Reroute (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. connectivity.
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. restoration in the event of catastrophic network failure.
6.4 Inter-AS PCE Peering Policies 6.4. Inter-AS PCE Peering Policies
Like BGP peering policies, inter-AS PCE peering policies is a Like BGP peering policies, inter-AS PCE peering policies are required
requirement for operator. In inter-AS BRPC process, PCE must for an operator. In an inter-AS BRPC process, the PCE must cooperate
cooperate in order to compute the end-to-end LSP. So, the AS path in order to compute the end-to-end LSP. Therefore, the AS path must
must not only follow technical constraints, e.g. bandwidth not only follow technical constraints, e.g., bandwidth availability,
availability, but also policies defined by the operator. but also the policies defined by the operator.
Typically PCE interconnections at an AS level must follow agreed Typically, PCE interconnections at an AS level must follow the 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. govern the relation between the different PCEs.
7. Multi-domain PCE Deployment Options 7. Multi-domain PCE Deployment Options
7.1 Traffic Engineering Database and Synchronization 7.1. Traffic Engineering Database and Synchronization
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
link connectivity, available bandwidth, and link costs. The PCE connectivity, available bandwidth, and link costs. The PCE operates
operates on a view of the network topology as presented by a on a view of the network topology as presented by a TED. As
TED. As discussed in [RFC4655] the TED used by a PCE may be learnt discussed in [RFC4655], the TED used by a PCE may be learned by the
by the relevant IGP extensions. relevant IGP extensions.
Thus, the PCE may operate its TED is by participating Thus, the PCE may operate its TED by participating in the IGP running
in the IGP running in the network. In an MPLS-TE network, this in the network. In an MPLS-TE network, this would require OSPF-TE
would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS network, it would utilize
network it would utilize the GMPLS extensions to OSPF and IS-IS the GMPLS extensions to OSPF and IS-IS defined in [RFC4203] and
defined in [RFC4203] and [RFC5307]. Inter-as connectivity [RFC5307]. Inter-AS connectivity information may be populated via
information may be populated via [RFC5316] and [RFC5392]. [RFC5316] and [RFC5392].
An alternative method to provide network topology and resource An alternative method to providing network topology and resource
information is offered by [RFC7752], which is described in the information is offered by [RFC7752], which is described in the
following section. following section.
7.1.1 Applicability of BGP-LS to PCE 7.1.1. Applicability of BGP-LS to PCE
The concept of exchange of TE information between Autonomous Systems The concept of the exchange of TE information between Autonomous
(ASes) is discussed in [RFC7752]. The information exchanged in this Systems (ASes) is discussed in [RFC7752]. The information exchanged
way could be the full TE information from the AS, an aggregation of in this way could be the full TE information from the AS, an
that information, or a representation of the potential connectivity aggregation of that information, or a representation of the potential
across the AS. Furthermore, that information could be updated connectivity across the AS. Furthermore, that information could be
frequently (for example, for every new LSP that is set up across the updated frequently (for example, for every new LSP that is set up
AS) or only at threshold-crossing events. across the AS) or only at threshold-crossing events.
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. PCE for optimal path link selection.
7.2 Pre-Planning and Management-Based Solutions 7.2. Pre-planning and Management-Based Solutions
Offline path computation is performed ahead of time, before the LSP Offline path computation is performed ahead of time before the LSP
setup is requested. That means that it is requested by, or performed setup is requested. That means that it is requested by or performed
as part of, an Operation Support System (OSS) management application. as part of an Operation Support System (OSS) management application.
This model can be seen in Section 5.5 of [RFC4655]. This model can be seen in Section 5.5 of [RFC4655].
The offline model is particularly appropriate to long-lived LSPs The offline model is particularly appropriate for 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. normally a feature of LSP provisioning.
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
computation to be used when the actual end-to-end path is to be used when the actual end-to-end path is required. This model
required. This model may also be used where the operator may also be used where the operator wishes to retain full manual
wishes to retain full manual control of the placement of LSPs, control of the placement of LSPs, using the PCE only as a computation
using the PCE only as a computation tool to assist the operator, tool to assist the operator and not as part of an automated network.
not as part of an automated network.
In environments where operators peer with each other to provide end- In environments where operators peer with each other to provide end-
to-end paths, the operator responsible for each domain must agree to-end paths, the operator responsible for each domain must agree on
to what extent paths must be pre-planned or manually controlled. the extent to which paths must be pre-planned or manually controlled.
8. Domain Confidentiality 8. Domain Confidentiality
This section discusses the techniques that co-operating PCEs This section discusses the techniques that cooperating PCEs can use
can use to compute inter-domain paths without each domain to compute inter-domain paths without each domain disclosing
disclosing sensitive internal topology information (such as sensitive internal topology information (such as explicit nodes or
explicit nodes or links within the domain) to the other domains. links within the domain) to the other domains.
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. Where the TE LSP crosses multiple domains (ASes or
areas), the path may be computed by multiple PCEs that cooperate areas), the path may be computed by multiple PCEs that cooperate
together. With each local PCE responsible for computing a segment together, with each local PCE responsible for computing a segment of
of the path. the path. With each local PCE responsible for computing a segment of
the path.
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. disclosing AS-internal or area topology information.
8.1 Loose Hops 8.1. Loose Hops
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 [RFC3209]. strict hops for the route of a TE LSP is described in [RFC3209].
[RFC5440] supports the use of paths with loose hops, and it is a [RFC5440] supports the use of paths with loose hops; whether it
local policy decision at a PCE whether it returns a full explicit returns a full explicit path with strict hops or uses loose hops is a
path with strict hops or uses loose hops. A path computation local policy decision at a PCE. A path computation request may
request may require an explicit path with strict hops, or may allow require an explicit path with strict hops or may allow loose hops, as
loose hops as detailed in [RFC5440]. detailed in [RFC5440].
8.2 Confidential Path Segments and Path Keys 8.2. Confidential Path Segments and Path-Keys
[RFC5520] defines the concept and mechanism of Path-Key. A Path-Key [RFC5520] defines the concept and mechanism of a Path-Key. A Path-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 ([RFC5440]) messages exchanged between the encoded and is contained in the Path Computation Element
PCE and PCC. Communication Protocol (PCEP) ([RFC5440]) messages exchanged between
the PCE and PCC.
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. information between domains.
9. Point-to-Multipoint 9. Point to Multipoint
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
point-to-point path computations. As the size of the network compared to point-to-point path computations. As the size of the
grows, the number of leaves and branches increase, further network 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
A solution for managing point-to-multipoint path computations may solution for managing point-to-multipoint path computations may be
be achieved using the PCE inter-domain point-to-multipoint path achieved using the PCE inter-domain point-to-multipoint path
computation [RFC7334] procedure. computation [RFC7334] procedure.
10. Optical Domains 10. Optical Domains
The International Telecommunications Union (ITU) defines the ASON The International Telecommunication Union (ITU) defines the ASON
architecture in [G-8080]. [G-7715] defines the routing architecture architecture in [G-8080]. [G-7715] 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. interconnectivity of the lower RAs is visible to the higher-level RA.
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 termed a Switched Connection (SC) or a Soft Permanent an LSP, which is termed a Switched Connection (SC) or a Soft
Connection (SPC). [G-7715-2] defines the requirements and Permanent Connection (SPC). [G-7715-2] 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. with a PCE.
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: and sequences are defined as follows:
o Remote route query. An operation where a routing controller * Remote route query. An operation where a Routing 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. path in a collaborative manner.
o Route query requester. The connection controller or RC that sends a * Route query requester. The connection controller or RC that sends
route query message to a routing controller requesting for one or a route query message to a Routing Controller that requests one or
more routing paths that satisfy a set of routing constraints. more routing paths satisfying a set of routing constraints.
o Route query responder. An RC that performs path computation upon * Route query responder. An RC that performs the path computation
reception of a route query message from a routing controller or upon reception of a route query message from a Routing Controller
connection controller, sending a response back at the end of or connection controller, and sends a response back at the end of
computation. the computation.
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
can also use the hierarchical PCE [RFC6805] model to match fully the environment can also use the hierarchical PCE [RFC6805] model to
ASON hierarchical routing model. fully match the ASON hierarchical routing model.
10.1 Abstraction and Control of TE Networks (ACTN) 10.1. Abstraction and Control of TE Networks (ACTN)
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 [RFC8453] may be used to create an abstracted (ACTN) framework [RFC8453] may be used to create an abstracted
(virtualized network) view of underlay interconnected domains. This (virtualized network) view of underlay-interconnected domains. This
underlay connectivity then be exposed to higher-layer control underlay connectivity is then exposed to higher-layer control
entities and applications. entities and applications.
ACTN describes the method and procedure for coordinating the ACTN describes the method and procedure for coordinating the underlay
underlay per-domain Physical Network Controllers (PNCs), which may per-domain Provisioning Network Controllers (PNCs), which may be
be PCEs, via a hierarchical model to facilitate setup of PCEs, via a hierarchical model to facilitate setup of end-to-end
end-to-end connections across inter-connected TE domains. connections across interconnected TE domains.
11. Policy 11. Policy
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. [RFC5394] provides a framework for PCE- operation of the network. [RFC5394] provides a framework for PCE-
based policy-enabled path computation. This framework is based on based policy-enabled path computation. This framework is based on
the Policy Core Information Model (PCIM) as defined in [RFC3060] and the Policy Core Information Model (PCIM) as defined in [RFC3060] and
further extended by [RFC3460]. further extended by [RFC3460].
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
invoked by specifying: by specifying the following:
o Each PCC must select which computations will be requested to a PCE; * Each PCC must select which computations it will request from a
PCE.
o Each PCC must select which PCEs it will use; * Each PCC must select which PCEs it will use.
o Each PCE must determine which PCCs are allowed to use its services * Each PCE must determine which PCCs are allowed to use its services
and for what computations; and for what computations.
o The PCE must determine how to collect the information in its TED, * 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; information.
o Each PCE must determine which objective functions and which * Each PCE must determine which objective functions and algorithms
algorithms to apply. to apply.
12. Manageability Considerations 12. Manageability Considerations
General PCE management considerations are discussed in [RFC4655]. General PCE management considerations are discussed in [RFC4655]. In
In the case of multi-domains within a single service provider the case of multi-domains within a single service provider network,
network, the management responsibility for each PCE would most the management responsibility for each PCE would most likely be
likely be handled by the same service provider. In the case of handled by the same service provider. In the case of multiple ASes
multiple ASes within different service provider networks, it will within different service provider networks, it will likely be
likely be necessary for each PCE to be configured and managed necessary for each PCE to be configured and managed separately by
separately by each participating service provider, with policy each participating service provider, with policy being implemented
being implemented based on a previously agreed set of principles. based on a previously agreed set of principles.
12.1 Control of Function and Policy 12.1. Control of Function and Policy
As per PCEP [RFC5440] implementation allow the user to configure As per [RFC5440], PCEP implementation allows the user to configure a
a number of PCEP session parameters. These are detailed in section number of PCEP session parameters. These are detailed in Section 8.1
8.1 of [RFC5440]. of [RFC5440].
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. the parent PCE.
12.2 Information and Data Models 12.2. Information and Data Models
A PCEP MIB module is defined in [RFC7420] that describes managed A PCEP MIB module is defined in [RFC7420], which describes managed
objects for modeling of PCEP communication including: objects for modeling PCEP communication, including:
o PCEP client configuration and status, * PCEP client configuration and status.
o PCEP peer configuration and information, * PCEP peer configuration and information.
o PCEP session configuration and information, * PCEP session configuration and information.
o Notifications to indicate PCEP session changes. * Notifications to indicate PCEP session changes.
A YANG module for PCEP has also been proposed [PCEP-YANG]. A YANG module for PCEP has also been proposed [PCEP-YANG].
An H-PCE MIB module, or YANG data model, will be required to An H-PCE MIB module or YANG data model will be required to report
report parent PCE and child PCE information, including: parent PCE and child PCE information, including:
o parent PCE configuration and status, * Parent PCE configuration and status.
o child PCE configuration and information, * Child PCE configuration and information.
o notifications to indicate session changes between parent PCEs and * Notifications to indicate session changes between parent PCEs and
child PCEs, and child PCEs.
o notification of parent PCE TED updates and changes. * Notification of parent PCE TED updates and changes.
12.3 Liveness Detection and Monitoring 12.3. Liveness Detection and Monitoring
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 [RFC5886] overloaded state to a PCC. In a multi-domain environment, [RFC5886]
provides the procedures necessary to monitor the liveliness and provides the procedures necessary to monitor the liveliness and
performances of a given PCE chain. performance of a given PCE chain.
12.4 Verifying Correct Operation 12.4. Verifying Correct Operation
It is important to verify the correct operation of PCEP, [RFC5440] It is important to verify the correct operation of PCEP. [RFC5440]
specifies the monitoring of key parameters. These parameters are specifies the monitoring of key parameters. These parameters are
detailed in [RFC5520]. detailed in [RFC5520].
12.5 Impact on Network Operation 12.5. Impact on Network Operation
[RFC5440] states that in order to avoid any unacceptable impact on [RFC5440] states that in order to avoid any unacceptable 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
speaker, it may also be practical to place a limit on the rate and that it may also be practical to place a limit on the rate of
of messages sent by a PCC and received my the PCE. messages sent by a PCC and received by the PCE.
13. Security Considerations 13. Security Considerations
PCEP Security considerations are discussed in [RFC5440] and [RFC6952] PCEP security considerations are discussed in [RFC5440] and
Potential vulnerabilities include spoofing, snooping, falsification [RFC6952]. Potential vulnerabilities include spoofing, snooping,
and using PCEP as a mechanism for denial of service attacks. falsification, and using PCEP as a mechanism for denial of service
attacks.
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
encryption mechanisms, such as Transport Layer Security (TLS) and TCP 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 [RFC8253], and recommendations and best for PCEP is described in [RFC8253], and recommendations and best
current practices in [RFC7525]. current practices are described in [RFC7525].
13.1 Multi-domain Security 13.1. Multi-domain Security
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
significant security and confidentiality risk. security and confidentiality risk.
It is expected that PCEP is used between PCCs and PCEs belonging to It is expected that PCEP is used between PCCs and PCEs that belong to
the same administrative authority, and using one of the the same administrative authority while also using one of the
aforementioned encryption mechanisms. Furthermore, PCEP allows aforementioned encryption mechanisms. 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. information using path-keys.
14. IANA Considerations 14. IANA Considerations
This document makes no requests for IANA action. This document has no IANA actions.
15. Acknowledgements 15. References
The author would like to thank Adrian Farrel for his review, and 15.1. Normative References
Meral Shirazipour and Francisco Javier Jimenex Chico for their
comments.
16. References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
16.1. Normative References [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC4216] Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter-
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Autonomous System (AS) Traffic Engineering (TE)
Tunnels", RFC 3209, December 2001. Requirements", RFC 4216, DOI 10.17487/RFC4216, November
2005, <https://www.rfc-editor.org/info/rfc4216>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Switching (GMPLS) Signaling Resource ReserVation Computation Element (PCE)-Based Architecture", RFC 4655,
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC DOI 10.17487/RFC4655, August 2006,
3473, January 2003. <https://www.rfc-editor.org/info/rfc4655>.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter- [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
Autonomous System (AS) Traffic Engineering (TE) for Inter-Domain Multiprotocol Label Switching Traffic
Requirements", RFC 4216, November 2005. Engineering", RFC 4726, DOI 10.17487/RFC4726, November
2006, <https://www.rfc-editor.org/info/rfc4726>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Element (PCE)-Based Architecture", RFC 4655, August 2006. Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<https://www.rfc-editor.org/info/rfc5152>.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
for Inter-Domain Multiprotocol Label Switching Traffic Element (PCE) Communication Protocol (PCEP)", RFC 5440,
Engineering", RFC 4726, November 2006. DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
Path Computation Method for Establishing Inter-Domain "A Backward-Recursive PCE-Based Computation (BRPC)
Traffic Engineering (TE) Label Switched Paths (LSPs)", Procedure to Compute Shortest Constrained Inter-Domain
RFC 5152, February 2008. Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Preserving Topology Confidentiality in Inter-Domain Path
"Path Computation Element (PCE) Communication Protocol Computation Using a Path-Key-Based Mechanism", RFC 5520,
(PCEP)", RFC 5440, March 2009. DOI 10.17487/RFC5520, April 2009,
<https://www.rfc-editor.org/info/rfc5520>.
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Computation (BRPC) procedure to compute shortest inter- Objective Functions in the Path Computation Element
domain Traffic Engineering Label Switched Paths", Communication Protocol (PCEP)", RFC 5541,
RFC5441, April 2009. DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
"Preserving Topology Confidentiality in Inter-Domain Path Path Computation Element Architecture to the Determination
Computation Using a Path-Key-Based Mechanism", RFC 5520, of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
April 2009. DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>.
[RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding 15.2. Informative References
of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, December 2008.
[RFC6805] King, D. and A. Farrel, "The Application of the Path [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
Computation Element Architecture to the Determination "Policy Core Information Model -- Version 1
of a Sequence of Domains in MPLS & GMPLS", RFC6805, July Specification", RFC 3060, DOI 10.17487/RFC3060, February
2010. 2001, <https://www.rfc-editor.org/info/rfc3060>.
16.2. Informative References [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003,
<https://www.rfc-editor.org/info/rfc3460>.
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
Westerinen, "Policy Core Information Model -- Version 1 (TE) Extensions to OSPF Version 2", RFC 3630,
Specification", RFC 3060, February 2001. DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Extensions", RFC 3460, January 2003. Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Engineering (TE) Extensions to OSPF Version 2", RFC Support of Generalized Multi-Protocol Label Switching
3630, September 2003. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N.,
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May and G. Ash, "Crankback Signaling Extensions for MPLS and
2005. GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007,
<https://www.rfc-editor.org/info/rfc4920>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Extensions in Support of Generalized Multi- Zhang, "OSPF Protocol Extensions for Path Computation
Protocol Label Switching (GMPLS)", RFC Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
4203, October 2005. January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
N., and G. Ash, "Crankback Signaling Extensions for MPLS Zhang, "IS-IS Protocol Extensions for Path Computation
and GMPLS RSVP-TE", RFC 4920, July 2007. Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
"OSPF Protocol Extensions for Path Computation Element Engineering", RFC 5305, DOI 10.17487/RFC5305, October
(PCE) Discovery", RFC 5088, January 2008. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
Zhang, "IS-IS Protocol Extensions for Path Computation in Support of Generalized Multi-Protocol Label Switching
Element (PCE) Discovery", RFC 5089, January 2008. (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Engineering", RFC 5305, October 2008. Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Extensions in Support of Generalized Multi-Protocol Support of Inter-Autonomous System (AS) MPLS and GMPLS
Label Switching (GMPLS)", RFC 5307, Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
October 2008. January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
Support of Inter-Autonomous System (AS) MPLS and GMPLS "Policy-Enabled Path Computation Framework", RFC 5394,
Traffic Engineering", December 2008. DOI 10.17487/RFC5394, December 2008,
<https://www.rfc-editor.org/info/rfc5394>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Support of Inter-Autonomous System (AS) MPLS and GMPLS Path Computation Element Communication Protocol (PCEP) for
Traffic Engineering", RFC 5392, January 2009. Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <https://www.rfc-editor.org/info/rfc5521>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
"Policy-Enabled Path Computation Framework", RFC 5394, Monitoring Tools for Path Computation Element (PCE)-Based
December 2008. Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<https://www.rfc-editor.org/info/rfc5886>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization
Path Computation Element Communication Protocol (PCEP) VECtor (SVEC) List for Synchronized Dependent Path
for Route Exclusions", RFC 5521, April 2009. Computations", RFC 6007, DOI 10.17487/RFC6007, September
2010, <https://www.rfc-editor.org/info/rfc6007>.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of [G-8080] ITU-T, "Architecture for the automatically switched
Monitoring Tools for Path ComputationElement (PCE)-Based optical network", ITU-T Recommendation G.8080/Y.1304,
Architecture", RFC 5886, June 2010. February 2012.
[RFC6007] Nishioka, I., King, D., "Use of the Synchronization [G-7715] ITU-T, "Architecture and requirements for routing in the
VECtor (SVEC) List for Synchronized Dependent Path automatically switched optical networks", ITU-T
Computations", RFC6007, September 2010. Recommendation G.7715/Y.1706, June 2002.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for [G-7715-2] ITU-T, "ASON routing architecture and requirements for
the automatically switched optical network (ASON). remote route query", ITU-T
Recommendation G.7715.2/Y.1706.2, February 2007.
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
and Requirements for the Automatically Switched BGP, LDP, PCEP, and MSDP Issues According to the Keying
Optical Network (ASON). and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas,
architecture and requirements for remote route query. "PCE-Based Computation Procedure to Compute Shortest
Constrained Point-to-Multipoint (P2MP) Inter-Domain
Traffic Engineering Label Switched Paths", RFC 7334,
DOI 10.17487/RFC7334, August 2014,
<https://www.rfc-editor.org/info/rfc7334>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
BGP, LDP, PCEP, and MSDP Issues According to the Keying Hardwick, "Path Computation Element Communication Protocol
and Authentication for Routing Protocols (KARP) Design (PCEP) Management Information Base (MIB) Module",
Guide", RFC 6952, May 2013. RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>.
[RFC7334] Zhao, Q., Dhody, D., Ali Z., King, D., [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
Casellas, R., "PCE-based Computation "Recommendations for Secure Use of Transport Layer
Procedure To Compute Shortest Constrained Security (TLS) and Datagram Transport Layer Security
P2MP Inter-domain Traffic Engineering Label Switched (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
Paths", August 2014. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7420] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
Communication Protocol (PCEP) Management Information S. Ray, "North-Bound Distribution of Link-State and
Base", December 2014. Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects
"Recommendations for Secure Use of Transport Layer for the Path Computation Element Communication Protocol
Security (TLS) and Datagram Transport Layer Security (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016,
(DTLS)", BCP 195, RFC 7525, May 2015. <https://www.rfc-editor.org/info/rfc7897>.
[RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
S. Ray, "North-Bound Distribution of Link-State and TE "PCEPS: Usage of TLS to Provide a Secure Transport for the
Information using BGP", March 2016. Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
for the Path Computation Element Communication Protocol Abstraction and Control of TE Networks (ACTN)", RFC 8453,
(PCEP)", June 2016. DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [PCEP-YANG]
"PCEPS: Usage of TLS to Provide a Secure Transport for Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
the Path Computation Element Communication Protocol YANG Data Model for Path Computation Element
(PCEP)", RFC 8253, October 2017. Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October
2019,
<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Acknowledgements
Abstraction and Control of TE Networks (ACTN)", RFC8453,
August 2018.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A The author would like to thank Adrian Farrel for his review and Meral
YANG Data Model for Path Computation Element Shirazipour and Francisco Javier Jiménez Chico for their comments.
Communications Protocol (PCEP)", work in progress,
October 2018.
17. Contributors Contributors
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore 560066
Karnataka
India India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Quintin Zhao Quintin Zhao
Huawei Technology Huawei Technologies
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US United States of America
Email: qzhao@huawei.com Email: qzhao@huawei.com
Julien Meuric Julien Meuric
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France
Email: julien.meuric@orange-ftgroup.com Email: julien.meuric@orange.com
Olivier Dugeon Olivier Dugeon
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France
Email: olivier.dugeon@orange-ftgroup.com Email: olivier.dugeon@orange.com
Jon Hardwick Jon Hardwick
Metaswitch Networks Metaswitch Networks
100 Church Street 100 Church Street
Enfield, Middlesex Enfield
EN2 6BQ
United Kingdom United Kingdom
Email: jonathan.hardwick@metaswitch.com Email: jonathan.hardwick@metaswitch.com
Oscar Gonzalez de Dios Óscar González de Dios
Telefonica I+D Telefonica I+D
Emilio Vargas 6, Madrid Emilio Vargas 6
Madrid
Spain Spain
Email: ogondio@tid.es Email: oscar.gonzalezdedios@telefonica.com
18. Author's Addresses Authors' Addresses
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District H1, Huawei Xiliu Beipo Village, Songshan Lake
Shenzhen, Guangdong 518129 Dongguan
P.R.China Guangdong, 523808
China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Additional contact information:
郑好棉
中国
523808
广东 东莞
松山湖华为溪流背坡村H1
华为技术有限公司
 End of changes. 264 change blocks. 
708 lines changed or deleted 764 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/