draft-ietf-pce-inter-area-as-applicability-05.txt   draft-ietf-pce-inter-area-as-applicability-06.txt 
PCE Working Group D. King PCE Working Group D. King
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Intended status: Informational J. Meuric Intended status: Informational J. Meuric
Expires: January 29, 2016 O. Dugeon Expires: January 21, 2017 O. Dugeon
France Telecom France Telecom
Q. Zhao Q. Zhao
D. Dhody
Huawei Technologies Huawei Technologies
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
July 28, 2015 July 20, 2016
Applicability of the Path Computation Element to Inter-Area and Applicability of the Path Computation Element to Inter-Area and
Inter-AS MPLS and GMPLS Traffic Engineering Inter-AS MPLS and GMPLS Traffic Engineering
draft-ietf-pce-inter-area-as-applicability-05 draft-ietf-pce-inter-area-as-applicability-06
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-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. (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.
skipping to change at page 1, line 49 skipping to change at page 1, line 50
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 29, 2016. This Internet-Draft will expire on January 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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.
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction.................................................3
1.1. Domains.................................................4 1.1. Domains.................................................4
1.2. Path Computation........................................4 1.2. Path Computation........................................4
1.2.1 PCE-based Path Computation Procedure.................5 1.2.1 PCE-based Path Computation Procedure.................5
1.3. Traffic Engineering Aggregation and Abstraction.........5 1.3. Traffic Engineering Aggregation and Abstraction.........5
1.4. Traffic Engineered Label Switched Paths.................6 1.4. Traffic Engineered Label Switched Paths.................
1.5. Inter-area and Inter-AS Connectivity Discovery..........6 1.5. Inter-area and Inter-AS Capable PCE Discovery...........6
1.6. Objective Functions.....................................6 1.6. Objective Functions.....................................6
2. Terminology..................................................7 2. Terminology..................................................7
3. Issues and Considerations....................................7 3. Issues and Considerations....................................7
3.1 Multi-homing.............................................7 3.1 Multi-homing.............................................7
3.2 Domain Confidentiality ..................................8 3.2 Domain Confidentiality ..................................8
3.3 Destination Location.....................................8 3.3 Destination Location.....................................8
4. Domain Topologies............................................8 4. Domain Topologies............................................8
4.1 Selecting Domain Paths...................................9 4.1 Selecting Domain Paths...................................8
4.2 Multi-Homed Domains......................................9 4.2 Multi-Homed Domains......................................9
4.3 Domain Meshes............................................9 4.3 Domain Topologies........................................9
4.4 Domain Diversity.........................................9 4.4 Domain Diversity.........................................9
4.5 Synchronized Path Computations...........................9 4.5 Synchronized Path Computations...........................9
4.6 Domain Inclusion or Exclusion............................10 4.6 Domain Inclusion or Exclusion............................10
5. Applicability of the PCE to Inter-area Traffic Engineering...10 5. Applicability of the PCE to Inter-area Traffic Engineering...11
5.1. Inter-area Routing......................................11 5.1. Inter-area Routing......................................11
5.1.1. Area Inclusion and Exclusion..........................11 5.1.1. Area Inclusion and Exclusion..........................11
5.1.2. Strict Explicit Path and Loose Path...................11 5.1.2. Strict Explicit Path and Loose Path...................12
5.1.3. Inter-Area Diverse Path Computation...................12 5.1.3. Inter-Area Diverse Path Computation...................12
5.2. Control and Recording of Area Crossing..................12 5.2. Control and Recording of Area Crossing..................12
6. Applicability of the PCE to Inter-AS Traffic Engineering.....12 6. Applicability of the PCE to Inter-AS Traffic Engineering.....12
6.1. Inter-AS Routing........................................13 6.1. Inter-AS Routing........................................13
6.1.1. AS Inclusion and Exclusion............................13 6.1.1. Strict Explicit Path and Loose Path...................13
6.1.2. Strict Explicit Path and Loose Path...................13 6.1.2. AS Inclusion and Exclusion............................13
6.1.3. AS Inclusion and Exclusion............................13
6.2. Inter-AS Bandwidth Guarantees...........................13 6.2. Inter-AS Bandwidth Guarantees...........................13
6.3. Inter-AS Recovery.......................................14 6.3. Inter-AS Recovery.......................................14
6.4. Inter-AS PCE Peering Policies...........................14 6.4. Inter-AS PCE Peering Policies...........................14
7. Multi-Domain PCE Deployment..................................14 7. Multi-Domain PCE Deployment..................................14
7.1 Traffic Engineering Database.............................14 7.1 Traffic Engineering Database.............................15
7.2 Provisioning Techniques..................................14 7.1.1 Provisioning Techniques................................16
7.3 Pre-Planning and Management-Based Solutions..............16 7.3 Pre-Planning and Management-Based Solutions..............16
7.4 Per-Domain Computation...................................16 7.4 Per-Domain Computation...................................16
7.5 Cooperative PCEs.........................................16 7.5 Cooperative PCEs.........................................16
7.6 Hierarchical PCEs ......................................16 7.6 Hierarchical PCEs ......................................17
8. Domain Confidentiality.......................................17 8. Domain Confidentiality.......................................17
8.1 Loose Hops...............................................17 8.1 Loose Hops...............................................17
8.2 Confidential Path Segments and Path Keys.................17 8.2 Confidential Path Segments and Path Keys.................17
9. Point-to-Multipoint..........................................17 9. Point-to-Multipoint..........................................18
10. Optical Domains.............................................18 10. Optical Domains.............................................18
10.1. PCE applied to the ASON Architecture....................18 10.1. PCE applied to the ASON Architecture....................18
11. Policy......................................................19 11. Policy......................................................19
12. TED Topology and Synchronization............................19 12. TED Topology and Synchronization............................19
12.1. Applicability of BGP-LS to PCE..........................20 12.1. Applicability of BGP-LS to PCE..........................20
13. Manageability Considerations................................20 13. Manageability Considerations................................20
13.1 Control of Function and Policy...........................20 13.1 Control of Function and Policy...........................20
13.2 Information and Data Models..............................21 13.2 Information and Data Models..............................21
13.3 Liveness Detection and Monitoring........................21 13.3 Liveness Detection and Monitoring........................21
13.4 Verifying Correct Operation..............................21 13.4 Verifying Correct Operation..............................22
13.5 Impact on Network Operation..............................21 13.5 Impact on Network Operation..............................22
14. Security Considerations.....................................21 14. Security Considerations.....................................22
15. IANA Considerations.........................................22 15. IANA Considerations.........................................22
16. Acknowledgements............................................22 16. Acknowledgements............................................22
17. References..................................................22 17. References..................................................22
17.1. Normative References....................................22 17.1. Normative References....................................22
17.2. Informative References..................................22 17.2. Informative References..................................22
18. Author's Addresses..........................................25 18. Author's Addresses..........................................26
1. Introduction 1. Introduction
Computing paths across large multi-domain environments may Computing paths across large multi-domain environments may
require special computational components and cooperation between require special computational components and cooperation between
entities in different domains capable of complex path computation. entities in different domains capable of complex path computation.
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 this problem space. and a set of functional components to address this problem space.
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 path computation (BRPC) mechanism
[RFC5441] defines a PCE-based path computation procedure to compute [RFC5441] defines a PCE-based 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-AS In more advanced deployments (including multi-area and multi-
environments) the sequence of domains may not be known in advance Autonomous System (multi-AS) environments) the sequence of domains
and the choice of domains in the end-to-end domain sequence might may not be known in advance and the choice of domains in the end-to-
be critical to the determination of an optimal end-to-end path. In end domain sequence might be critical to the determination of an
this case the use of the Hierarchical PCE [RFC6805] architecture and optimal end-to-end path. In this case the use of the Hierarchical PCE
mechanisms may be used to discovery the intra-area path and select [RFC6805] architecture and mechanisms may be used to discover the
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, protocols and protocol extensions for using the PCE architecture, protocols and protocol extensions for
computing inter-area and inter-AS MPLS and GMPLS Traffic TE paths. computing inter-area and inter-AS MPLS and GMPLS Traffic TE paths.
This document does not discuss stateful PCE, active PCE, or remotely
initiated PCE, deployment scenarios.
1.1 Domains 1.1 Domains
A domain can be defined as a separate administrative, geographic, or A domain can be defined as a separate administrative, geographic, or
switching environment within the network. A domain may be further switching environment within the network. A domain may be further
defined as a zone of routing or computational ability. Under these defined as a zone of routing or computational ability. Under these
definitions a domain might be categorized as an Antonymous System definitions a domain might be categorized as an Antonymous System
(AS) or an Interior Gateway Protocol (IGP) area ( as per [RFC4726] (AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726]
and [RFC4655]). 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 common collection of network elements within an area or AS that has a common
sphere of address management or path computational responsibility. sphere of address management or path computational responsibility.
Wholly or partially overlapping domains are not within the scope of Wholly or partially overlapping domains are not 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 an
ASON routing area [G-7715]. A PCE may perform the path computation ASON routing area [G-7715]. A PCE may perform the path computation
function of an ASON routing controller as described in [G-7715-2]. function of an ASON routing controller as described in [G-7715-2].
It is assumed that the PCE architecture should only be applied to It is assumed that the PCE architecture is not applied to a large
small inter-domain topologies and not to solve route computation group of domains, such as Internet.
issues across large groups of domains, i.e. the entire Internet.
1.2 Path Computation 1.2 Path Computation
For the purpose of this document it is assumed that the For the purpose of this document it is assumed that the
path computation is the sole responsibility of the PCE as per the path computation is the sole responsibility of the PCE as per the
architecture defined in [RFC4655]. When a path is required the Path architecture defined in [RFC4655]. When a path is required the Path
Computation Client (PCC) will send a request to the PCE. The PCE will Computation Client (PCC) will send a request to the PCE. The PCE will
apply the required constraints and compute a path and return a apply the required constraints and compute a path and return a
response to the PCC. In the context of this document it maybe response to the PCC. In the context of this document it maybe
necessary for the PCE to co-operate with other PCEs in adjacent necessary for the PCE to co-operate with other PCEs in adjacent
skipping to change at page 5, line 26 skipping to change at page 5, line 30
be a single PCE per domain, or single PCE responsible for all be a single PCE per domain, or single PCE responsible for all
domains. A PCE may or may not reside on the same node as the domains. A PCE may or may not reside on the same node as the
requesting PCC. A path may be computed by either a single PCE node requesting PCC. A path may be computed by either a single PCE node
or a set of distributed PCE nodes that collaborate during path or a set of distributed PCE nodes that collaborate during path
computation. computation.
[RFC4655] defines that a PCC should send a path computation request [RFC4655] defines that 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 negates the need to broadcast a request to all the PCEs. Each This negates the need to broadcast a request to all the PCEs. Each
PCC can maintain information about the computation capabilities PCC can maintain information about the computation capabilities
of the PCEs it is aware of. The PCC-PCE capability awareness can of the PCEs it is aware of. The PCC-PCE capability awareness can be
configured using static configuration or by listening to the configured using static configurations or by automatic and dynamic
periodic advertisements generated by PCEs. PCE discovery procedures.
Once a path computation request is received, the PCC will send a Once a path computation request is received, the PCC will send a
request to the PCE. A PCE may compute the end-to-end path request to the PCE. A PCE may compute the end-to-end path
if it is aware of the topology and TE information required to if it is aware of the topology and TE information required to
compute the entire path. If the PCE is unable to compute the compute the entire path. If the PCE is unable to compute the
entire path, the PCE architecture provides co-operative PCE entire path, the PCE architecture provides co-operative PCE
mechanisms for the resolution of path computation requests when an mechanisms for the resolution of path computation requests when an
individual PCE does not have sufficient TE visibility. individual PCE does not have sufficient TE visibility.
A PCE may cooperate with other PCEs to determine intermediate loose End-to-end path segments may be kept confidential through the
hops. End-to-end path segments may be kept confidential through the
application of path keys, to protect partial or full path application of path keys, to protect partial or full path
information. A path key that is a token that replaces a path segment information. A path key that is a token that replaces a path segment
in an explicit route. The path key mechanism is described in in an explicit route. The path key mechanism is described in
[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 confidentiality and scalability TE properties of each area network confidentiality and scalability TE properties of each area
skipping to change at page 6, line 30 skipping to change at page 6, line 33
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]:
- Contiguous LSP - Contiguous LSP
- Stitched LSP - Stitched LSP
- Nested 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 Connectivity 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] allow discovery mechanism defined in [RFC5088] and [RFC5089] allow
the discovery of PCEs and disclosure of information related to the discovery of PCEs and disclosure of information related to
inter-area and inter-AS capable PCEs across area and AS boundaries. inter-area and inter-AS capable PCEs.
1.6 Objective Functions 1.6 Objective Functions
An Objective Function (OF) [RFC5541], or set of OFs, specify the An Objective Function (OF) [RFC5541], or set of OFs, specify the
intentions of the path computation and so define the "optimality" intentions of the path computation and so define the "optimality"
in the context of that computation request. in the context of that computation request.
An OF specifies the desired outcome of a computation. An OF does not An OF specifies the desired outcome of a computation. An OF does not
describe or specify the algorithm to use, and an implementation may describe or specify the algorithm to use, and an implementation may
apply any algorithm or set of algorithms to achieve the result apply any algorithm or set of algorithms to achieve the result
skipping to change at page 7, line 31 skipping to change at page 7, line 34
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 than
one IGP area. 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 one or
more inter-AS links. more inter-AS links.
CSPF: Constrained Shortest Path First.
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 Interior
skipping to change at page 8, line 22 skipping to change at page 8, line 24
3.2 Domain Confidentiality 3.2 Domain Confidentiality
Where the end-to-end path crosses multiple domains, it may be Where the end-to-end path crosses multiple domains, it may be
possible that each domain (AS or area) are administered by separate possible that each domain (AS or area) are administered by separate
Service Providers, it would break confidentiality rules for a PCE Service Providers, it would break confidentiality rules for a PCE
to supply a path segment to a PCE in another domain, thus disclosing to supply a path segment to a PCE in another domain, thus disclosing
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 PCC will be cannot exchange path segments or else the receiving PCE or PCC will
able to see the individual hops through another domain. be able to see the individual hops through another domain.
3.3 Destination Location 3.3 Destination Location
The PCC asking for an inter-domain path computation is typically The PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. Additionally, if the aware of the identity of the destination node. Additionally, if the
PCC is aware of the destination domain, it can supply this PCC is aware of the destination domain, it can supply this
information as part of the path computation request. However, information as part of the path computation request. However,
if the PCC does not know the egress domain this information must if the PCC does not know the egress domain this information must
be determined by another method. be determined by another method.
skipping to change at page 9, line 16 skipping to change at page 9, line 19
end-to-end path can be derived through the use of a hierarchical end-to-end path can be derived through the use of a hierarchical
relationship between domains [RFC6805]. relationship between domains [RFC6805].
4.2 Multi-Homed Domains 4.2 Multi-Homed Domains
Networks constructed from multi-areas or multi-AS environments Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid computations may need to use different interconnect points to avoid
single point failures disrupting primary and backup services. single point failures disrupting primary and backup services.
4.3 Domain Meshes 4.3 Domain Topologies
Very frequently network domains are composed by dozens or hundreds of Very frequently network domains are composed by dozens or hundreds of
network elements. These network elements are usually interconnected network elements. These network elements are usually interconnected
between them in a partial-mesh fashion, to provide survivability between them in a partial-mesh fashion, to provide survivability
against dual failures, and to benefit from the traffic engineering against dual failures, and to benefit from the traffic engineering
capabilities from MPLS and GMPLS protocols. A typical node degree capabilities from MPLS and GMPLS protocols. A typical node degree
ranges from 3 to 10 (4-5 is quite common), being the node degree the ranges from 3 to 10 (4-5 is quite common), being the node degree the
number of neighbors per node. number of neighbors per node.
Networks are sometimes divided into domains. Some reasons for it Networks are sometimes divided into domains. Some reasons for it
range from manageability to separation into vendor-specific domains. range from manageability to separation into vendor-specific domains.
The size of the domain will be usually limited by control plane, but The size of the domain will be usually limited by control plane, but
it can also be stated by arbitrary design constraints. it can also be stated by arbitrary design constraints.
4.4 Domain Diversity 4.4 Domain Diversity
Whenever an specific connectivity service is required to have 1+1 Whenever an specific connectivity service is required to have 1+1
protection feature, two completely disjoint paths must be protection feature, two completely disjoint paths must be established
established on an end to end fashion. In a multi-domain environment in an end to end fashion. In a multi-domain environment, this can be
without, this can be accomplished either by selecting domain accomplished either by selecting domain diversity, or by ensuring
diversity, or by ensuring diverse connection within a domain. In diverse connection within a domain. The domain diversity ensures
order to compute the route diversity, it could be helpful to have diversity in the transit domain, the diverse path should be computed
SRLG information in the domains. within the ingress and egress domain. In order to compute the path
diversity, it could be helpful to also have SRLG information in the
domains, to ensure SRLG diversity.
4.5 Synchronized Path Computations 4.5 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 in [RFC5440] and [RFC6007] provides an overview for the defined in [RFC5440] and [RFC6007] provides an overview for the
use of the PCE SVEC list for synchronized path computations when use of the PCE SVEC list for synchronized path computations when
computing dependent requests. computing dependent requests.
In a H-PCE deployment a child PCE will be able to request both
dependent and synchronized domain diverse end to end paths from its
parent PCE.
A non-comprehensive list of synchronized path computations include A non-comprehensive list of synchronized path computations include
the following examples: the following examples:
o Route diversity: computation of two disjoint paths from a source to o Route diversity: computation of two disjoint paths from a source to
a destination (as drafted in the previous section). a destination (as drafted in the previous section).
o Synchronous restoration: joint computation of a set of alternative o Synchronous restoration: joint computation of a set of alternative
paths for a set of affected LSPs as a consequence of a failure paths for a set of affected LSPs as a consequence of a failure
event. Note that in this case, the requests will potentially event. Note that in this case, the requests will potentially
involve different source-destination pairs. In this scenario, the involve different source-destination pairs. In this scenario, the
skipping to change at page 10, line 25 skipping to change at page 10, line 34
o Batch provisioning: It is common that the operator sends a set of o Batch provisioning: It is common that the operator sends a set of
LSPs requests together, e.g in a daily of weekly basis, mainly in LSPs requests together, e.g in a daily of weekly basis, mainly in
case of long lived LSPs. In order to optimize the resource usage, case of long lived LSPs. In order to optimize the resource usage,
a synchronized path computation is needed. a synchronized path computation is needed.
o Network optimization: After some time of operation, the o Network optimization: After some time of operation, the
distribution of the established LSP paths results in a non optimal distribution of the established LSP paths results in a non optimal
use of resources. Also, inter-domain policies/agreements may have use of resources. Also, inter-domain policies/agreements may have
been changed. In such cases, a full (or partial) network planning been changed. In such cases, a full (or partial) network planning
action regarding the inter-domain connections will be triggered. action regarding the inter-domain connections will be triggered.
This will involve the request of potentially a big amount of This process is also known as a Global Concurrent Optimization
connections. (GCO) [RFC5557].
4.6 Domain Inclusion or Exclusion 4.6 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 use of during path computation to guide the PCEs or derived via use of
Hierarchical PCE (H-PCE). Hierarchical PCE (H-PCE).
During multi-domain path computation, a PCC may request During multi-domain path computation, a PCC may request
specific domains to be included or excluded in the domain sequence specific domains to be included or excluded in the domain sequence
using the Include Route Object (IRO) [RFC5440] and Exclude Route using the Include Route Object (IRO) [RFC5440] and Exclude Route
Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an
abstract node representing a domain is defined in [RFC3209], abstract node representing a domain is defined in [RFC3209],
[DOMAIN-SEQ] specifies new sub-objects to include or exclude domains [RFC7897] specifies new sub-objects to include or exclude domains
such as an IGP area or an Autonomous Systems. such as an IGP area or a 4-Byte AS number.
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 information flooded introduce scaling methods to reduce the amount information flooded
within the network and make the network more manageable. An IGP within the network and make the network more manageable. An IGP
hierarchy is designed to improve IGP scalability by dividing the hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of information to within area boundaries. This restricts visibility of
the area to routers in a single area. If a router needs to compute a the area to routers in a single area. If a router needs to compute a
skipping to change at page 11, line 38 skipping to change at page 11, line 50
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 areas. In a multi-area network, topology visibility remains IGP areas. In a multi-area network, topology visibility remains
local to a given area, and a node in one area will not be able to local to a given area, and a node in one area will not be able to
compute an end-to-end path across multiple areas without the use compute an end-to-end path across multiple areas without the use
of a PCE. of a PCE.
5.1.1. Area Inclusion and Exclusion 5.1.1. Area Inclusion and Exclusion
[RFC5152] provides the mechanisms to compute an inter-area
path. It uses loose hop routing with an ERO expansion on each ABR.
This allows the end-to-end path to be set up following a constrained
path, but faces two major limitations:
- The method does not guarantee the use of an optimal constrained
path.
- This may lead to several crankback signaling messages and hence
delay the path setup.
[RFC5441] provides a more optimal method to specify inclusion or [RFC5441] provides a more optimal method to specify inclusion or
exclusion of an ABR. Using this method, an operator might decide if exclusion of an ABR. Using this method, an operator might decide if
an area must be include or exclude from the inter-area path an area must be include or exclude from the inter-area path
computation. 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, loose path is defined as a set of at least one loose hop and zero,
one or more strict hops. It may be useful to indicate, during the one or more strict hops. It may be useful to indicate, during the
path computation request, if a strict explicit path is required or path computation request, if a strict explicit path is required or
not. An inter-area path may be strictly explicit or loose (e.g., a not. An inter-area path may be strictly explicit or loose (e.g., a
list of ABRs as loose hops). list of ABRs as loose hops).
A PCC request to a PCE does allow the indication of if a strict A PCC request to a PCE does allow the indication of if a strict
explicit path across specific areas is required or desired, or if explicit path across specific areas ([RFC7897]) is required or
the path request is loose. desired, or if 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 (for protection or load-balancing) to compute It may be necessary (for protection or load-balancing) to compute
a path that is diverse, from a previously computed path. There are a path that is diverse, from a previously computed path. 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:
- Per-area diversity (intra-area path segments are link, node or - Per-area diversity (intra-area path segments are link, node or
SRLG disjoint. SRLG disjoint.
- Inter-area diversity (end-to-end inter-area paths are link, - Inter-area diversity (end-to-end inter-area paths are 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 disjoint in the backbone area but non-
disjoint in peripheral areas. Also two paths may be node disjoint disjoint in peripheral areas. Also two paths may be node disjoint
within areas but may share ABRs, in which case path segments within within areas but may share ABRs, in which case path segments within
an area are node disjoint but end-to-end paths are not node-disjoint. an area are node disjoint but end-to-end paths are not node-disjoint.
Both Per-Domain [RFC5152] and BRPC [RFC5441] mechanisms support the Per-Domain [RFC5152], BRPC [RFC5441] and H-PCE [RFC6805] mechanisms
capability to compute diverse across multi-area topologies. support the capability to compute diverse across multi-area
topologies.
5.2. Control and Recording of Area Crossing 5.2. Control and Recording of Area Crossing
In some environments it be useful for the PCE to provide a PCC the In some environments it be useful for the PCE to provide a PCC the
set of areas crossed by the end-to-end path. Additionally the PCE set of areas crossed by the end-to-end path. Then an operator may
can provide the path information and mark each segment so the PCC either want to avoid crossing specific areas, and choose to select a
has visibility of which piece of the path lies within which area. sub-optimal intra-area path. Additionally the PCE can provide the
Although by implementing Path-Key, the hop-by-hop (area topology) path information and mark each segment so the PCC has visibility of
information is kept confidential. which piece of the path lies within which area. Although by
implementing Path-Key, the hop-by-hop (area topology) information is
kept confidential.
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 4 (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 needs
to compute a path across an AS boundary it must also use an inter-AS to compute a path across an AS boundary it must also use an inter-AS
computation technique. [RFC5152] defines mechanisms for the 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-enabled solution for computing inter-AS paths. PCE-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. Strict Explicit Path and Loose Path
[RFC5441] a method to specify inclusion or exclusion of an ASBR.
Using this method, an operator might decide if an AS must be include
or exclude from the inter-AS path computation.
6.1.2. Strict Explicit Path and Loose Path
During path computation, the PCE architecture and BRPC algorithm During path computation, the PCE architecture and BRPC algorithm
allow operators to specify if the resultant LSP must follow a strict allow operators to specify if the resultant LSP must follow a strict
or a loose path. By explicitly specify the path, the operator or a loose path. By explicitly specify the path, the operator
request a strict explicit path which must pass through one or many request a strict explicit path which must pass through one or many
LSR. If this behaviour is well define and appropriate for inter-area, LSR. If this behaviour is well define and appropriate for inter-area,
it implies some topology discovery for inter-AS. So, this feature it implies some topology discovery for inter-AS. So, this feature
when the operator owns several ASes (and so, knows the topology of when the operator owns several ASes (and so, knows the topology of
its ASes) or restricts to the well-known ASBR to avoid topology its ASes) or restricts to the well-known ASBR to avoid topology
discovery between operators. The loose path, even if it does not discovery between operators. The loose path, even if it does not
allow granular specification of the path, protects topology allow granular specification of the path, protects topology
disclosure as it not obligatory for the operator to disclose disclosure as it not obligatory for the operator to disclose
information about its networks. information about its networks.
6.1.3. AS Inclusion and Exclusion 6.1.2. AS Inclusion and Exclusion
Like explicit and loose path, [RFC5441] allows to specify inclusion Like explicit and loose path, [RFC5441] allows to specify inclusion
or exclusion of respectively an AS or an ASBR. Using this method, or exclusion of respectively an AS or an ASBR. Using this method,
an operator might decide if an AS must be include or exclude from an operator might decide if an AS must be include or exclude from
the inter-AS path computation. Exclusion and/or inclusion could also the inter-AS path computation. Exclusion and/or inclusion could also
be specified at any step in the LSP path computation process by a PCE be specified at any step in the LSP path computation process by a PCE
(within the BRPC algorithm) but the best practice would be to specify (within the BRPC algorithm) but the best practice would be to specify
them at the edge. In opposition to the strict and loose path, AS them at the edge. In opposition to the strict and loose path, AS
inclusion or exclusion doesn't impose topology disclosure as ASes are inclusion or exclusion doesn't impose topology disclosure as ASes are
public entity as well as their interconnection. public entity as well as their interconnection.
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 MPLS-TE
DiffServ either across their entire network or at the domain edges DiffServ either across their entire network or at the domain edges
on CE-PE links. In situations where strict QOS bounds are required, on CE-PE links. In situations where strict QOS bounds are required,
admission control inside the network may also be required. 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. bandwidth guarantees along the DiffServ-enabled path, these
requirements are described in [RFC4216].
One typical example of this requirement is to provide bandwidth One typical example of the requirements in [RFC4216] is to provide
guarantees over an end-to-end path for VoIP traffic classified as EF bandwidth guarantees over an end-to-end path for VoIP traffic
(Expedited Forwarding) class in a DiffServ-enabled classified as EF (Expedited Forwarding) class in a DiffServ-enabled
network. In the case where the EF path is extended across multiple network. In the case where the EF path is extended across multiple
ASes, inter-AS bandwidth guarantee would be required. ASes, inter-AS bandwidth guarantee would be required.
Another case for inter-AS bandwidth guarantee is the requirement for Another case for inter-AS bandwidth guarantee is the requirement for
guaranteeing a certain amount of transit bandwidth across one or guaranteeing a certain amount of transit bandwidth across one or
multiple ASes. multiple ASes.
6.3 Inter-AS Recovery 6.3 Inter-AS Recovery
During path computation, a PCC request may contain backup LSP During a path computation process, a PCC request may contain a
requirements in order to setup in the same time the primary and requirement to compute a backup LSP for protecting the primary LSP,
backup LSPs. It is also possible to request a backup LSP for a group 1+1 protection. A single, or multiple backup LSPs may also be used
of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So, for a group of primary LSPs, m:n protection.
the PCE could be used to trigger computation of backup tunnels in
order to protect Inter-AS connectivity. Inter-AS recovery Other inter-AS recovery mechanisms include [RFC4090] which adds fast
requirements needs not only PCE protection and redundancy but also re-route (FRR) protection to an LSP. So, the PCE could be used to
LSP tunnels protection through FRR mechanisms. Inter-AS PCE trigger computation of backup tunnels in order to protect Inter-AS
computation must support the FRR mechanisms and the patch computation connectivity.
for backup tunnels for protection and fast recovery.
Inter-AS recovery needs not only LSP protection but it would also be
advisable to have multiple PCEs deployed for redundancy.
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 is a
requirement for operator. In inter-AS BRPC process, PCE must requirement for operator. In inter-AS BRPC process, PCE must
cooperate in order to compute the end-to-end LSP. So, the AS path cooperate in order to compute the end-to-end LSP. So, the AS path
must not only follow technical constraints e.g. bandwidth must not only follow technical constraints e.g. bandwidth
availability, but also policies define by the operator. availability, but also policies define by the operator.
Typically PCE interconnections at an AS level must follow contract Typically PCE interconnections at an AS level must follow contract
skipping to change at page 15, line 33 skipping to change at page 15, line 38
path request from a PCC contains source and destination nodes that path request from a PCC contains source and destination nodes that
are located in different domains the PCE is required to co-operate are located in different domains the PCE is required to co-operate
between multiple PCEs, each responsible for its own domain. between multiple PCEs, each responsible for its own domain.
Techniques for inter-domain path computation are described in Techniques for inter-domain path computation are described in
[RFC5152] and [RFC5441], both techniques assume that the sequence of [RFC5152] and [RFC5441], both techniques assume that the sequence of
domains to be crossed from source to destination is well known. In domains to be crossed from source to destination is well known. In
the event that the sequence of domains is not well known, [RFC6805] the event that the sequence of domains is not well known, [RFC6805]
might be used. The sequence could also be retrieve locally from might be used. The sequence could also be retrieve locally from
information previously stored in the PCE database (preferably in information previously stored in the PCE database (preferably in
the TED) by OSS management or other protocols. the TED) by Operational Support Systems (OSS) management or other
protocols.
7.1 Traffic Engineering Database 7.1 Traffic Engineering Database
TEDs are automatically populated by the IGP-TE like IS-IS-TE or TEDs are automatically populated by the IGP-TE like IS-IS-TE or
OSPF-TE. However, no information related to AS path are provided OSPF-TE. However, no information related to AS path are provided
by such IGP-TE. It could be helpful for BRPC algorithm as AS path by such IGP-TE. It could be helpful for BRPC algorithm as AS path
helper, to populate a TED with suitable information regarding helper, to populate a TED with suitable information regarding
inter-AS connectivity. Such information could be obtain from inter-AS connectivity. Such information could be obtain from
various sources, such as BGP protocol, peering policies, OSS of the various sources, such as BGP protocol, peering policies, OSS of the
operator or from neighbor PCE. In any case, no topology disclosure operator or from neighbor PCE. In any case, no topology disclosure
must be impose in order to provide such information. must be impose in order to provide such information.
In particular, for both inter-area and inter-AS, the TED must be In particular, for both inter-area and inter-AS, the TED must be
populated with all boundary node information suitable to populated. Inter-as connectivity information may be populated via
establish PCEP protocol with the next PCE in the path. [RFC5316] and [RFC5392].
7.2 Provisioning Techniques 7.1.1 Provisioning Techniques
As PCE algorithms rely on information contained in the TED, it As PCE algorithms rely on information contained in the TED, it
is possible to populate TED information by means of provisioning. In is possible to populate TED information by means of provisioning. In
this case, the operator must regularly update and store all suitable this case, the operator must regularly update and store all suitable
information in the TED in order for the PCE to correctly compute LSP. information in the TED in order for the PCE to correctly compute LSP.
Such information range from policies (e.g. avoid this LSR, or use Such information range from policies (e.g. avoid this LSR, or use
this ASBR for a specific IP prefix) up to topology information (e.g. this ASBR for a specific IP prefix) up to topology information (e.g.
AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s
are reserved for EF traffic). Operators may choose the type and are reserved for EF traffic). Operators may choose the type and
amount of information they can use to manage their traffic engineered amount of information they can use to manage their traffic engineered
skipping to change at page 16, line 42 skipping to change at page 16, line 47
automated network. automated network.
The management based solutions could also be used in conjunction The management based solutions could also be used in conjunction
with the BRPC algorithm. Operator just computes the AS-Path as with the BRPC algorithm. Operator just computes the AS-Path as
parameter for the inter-AS path computation request and let each parameter for the inter-AS path computation request and let each
PCE along the AS path compute the LSP part on its own domain. PCE along the AS path compute the LSP part on its own domain.
7.4 Per-Domain Computation 7.4 Per-Domain Computation
[RFC5152] defines the mechanism to compute per-domain path and must [RFC5152] defines the mechanism to compute per-domain path and must
be used in that condition. Otherwise, BRPC [RFC5441] will be used. be used in that condition. Otherwise, BRPC [RFC5441] or HPCE RFC6805]
will be used..
7.5 Cooperative PCEs 7.5 Cooperative PCEs
When PCE cooperate to compute an inter-area or inter-AS LSP, both When PCE cooperatation is required to compute an inter-area or inter-
[RFC5152] and [RFC5441] could be used. AS LSP, the techniques described in [RFC5441] and [RFC6805] could be
used.
7.6 Hierarchical PCEs 7.6 Hierarchical PCEs
The [RFC6805] draft defines how a hierarchy of PCEs may be used. An The H-PCE [RFC6805] proposal defines how a hierarchy of PCEs may be
operator must define a parent PCE and each child PCE. A parent PCE used. An operator must enable a parent PCE, and a child PCE per
can be announced in the other areas or ASes in order for the parent domain (AS or area). A parent PCE can be announced in the other areas
PCE to contact remote child PCEs. Reciprocally, child PCEs are or ASes in order for the parent PCE to contact remote child PCEs.
announced in remote areas or ASes in order to be contacted by a Reciprocally, child PCEs are announced in remote areas or ASes in
remote parent PCE. Parent and each child PCE could also be order to be contacted by a remote parent PCE. Parent and each child
provisioned in the TED if they are not announced. PCE could also be provisioned in the TED if they are not announced.
8. Domain Confidentiality 8. Domain Confidentiality
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 the path. However, in some cases (e.g., when ASes are of the path. However, in some cases (e.g., when ASes are
administered by separate Service Providers), it would break administered by separate Service Providers), it would break
confidentiality rules for a PCE to supply a path segment to a confidentiality rules for a PCE to supply a path segment to a
skipping to change at page 18, line 9 skipping to change at page 18, line 15
9. Point-to-Multipoint 9. Point-to-Multipoint
For the Point-to-Multipoint application scenarios for MPLS-TE LSP, For the Point-to-Multipoint application scenarios for MPLS-TE LSP,
the complexity of domain sequences, domain policies, choice and the complexity of domain sequences, domain policies, choice and
number of domain interconnects is magnified comparing to P2P path number of domain interconnects is magnified comparing to P2P path
computations. Also as the size of the network grows, the number of computations. Also as the size of the network grows, the number of
leaves and branches increase and it in turn puts the scalability of leaves and branches increase and it in turn puts the scalability of
the path computation and optimization into a bigger issue. A the path computation and optimization into a bigger issue. A
solution for the point-to-multipoint path computations may be solution for the point-to-multipoint path computations may be
achieved using the PCEP protocol extension for P2MP [RFC6006] and achieved using the PCEP protocol extension for P2MP [RFC6006] and
using the PCEP P2MP procedures defined in [RFC7334]. using the inter-domain P2MP procedures defined in [RFC7334].
10. Optical Domains 10. Optical Domains
The International Telecommunications Union (ITU) defines the ASON The International Telecommunications 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.
skipping to change at page 19, line 20 skipping to change at page 19, line 25
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 by specifying: invoked by specifying:
- Each PCC must select which computations will be delegated to a PCE; - Each PCC must select which computations will be requested to a PCE;
- Each PCC must select which PCEs it will use; - Each PCC must select which PCEs it will use;
- 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;
- The PCE must determine how to collect the information in its TED, - The PCE must determine how to collect the information in its TED,
who to trust for that information, and how to refresh/update the who to trust for that information, and how to refresh/update the
information; information;
skipping to change at page 20, line 6 skipping to change at page 20, line 10
Traffic Engineering Database. As discussed in [RFC4655] the TED Traffic Engineering Database. As discussed in [RFC4655] the TED
used by a PCE may be learnt by the relevant IGP extensions. used by a PCE may be learnt by the relevant IGP extensions.
Thus, the PCE may operate its TED is by participating Thus, the PCE may operate its TED is by participating
in the IGP running in the network. In an MPLS-TE network, this in the IGP running in the network. In an MPLS-TE network, this
would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS
network it would utilize the GMPLS extensions to OSPF and IS-IS network it would utilize the GMPLS extensions to OSPF and IS-IS
defined in [RFC4203] and [RFC5307]. defined in [RFC4203] and [RFC5307].
An alternative method to provide network topology and resource An alternative method to provide network topology and resource
information is offered by [BGP-LS], which is described in the information is offered by [RFC7752], which is described in the
following section. following section.
12.1 Applicability of BGP-LS to PCE 12.1 Applicability of BGP-LS to PCE
The concept of exchange of TE information between Autonomous Systems The concept of exchange of TE information between Autonomous Systems
(ASes) is discussed in [BGP-LS]. The information exchanged in this (ASes) is discussed in [RFC7752]. The information exchanged in this
way could be the full TE information from the AS, an aggregation of way could be the full TE information from the AS, an aggregation of
that information, or a representation of the potential connectivity that information, or a representation of the potential connectivity
across the AS. Furthermore, that information could be updated across the AS. Furthermore, that information could be updated
frequently (for example, for every new LSP that is set up across the frequently (for example, for every new LSP that is set up across the
AS) or only at threshold-crossing events. AS) or only at threshold-crossing events.
There are a number of discussion points associated with the use of In a H-PCE deployment, the parent PCE will require the inter-domain
[BGP-LS] concerning the volume of information, the rate of churn of topology and link status between child domains. This information may
information, the confidentiality of information, the accuracy of be learnt by a BGP-LS speaker and provided to the parent PCE,
aggregated or potential-connectivity information, and the processing furthermore link-state performance including: delay, available
required to generate aggregated information. The PCE architecture and bandwidth and utilized bandwidth, may also be provided to the parent
the architecture enabled by [BGP-LS] make different assumptions about PCE for optimal link selection.
the operational objectives of the networks, and this document does
not attempt to make one of the approaches "right" and the other
"wrong". Instead, this work assumes that a decision has been made to
utilize the PCE architecture.
Indeed, [BGP-LS] may have some uses within the PCE model. For
example, [BGP-LS] could be used as a "northbound" TE advertisement
such that a PCE does not need to listen to an IGP in its domain, but
has its TED populated by messages received (for example) from a
Route Reflector. Furthermore, the inter-domain connectivity and
connectivity capabilities that is required optional information for
a parent PCE could be obtained as a filtered subset of the
information available in [BGP-LS].
13. Manageability Considerations 13. Manageability Considerations
General PCE management considerations are discussed in [RFC4655]. General PCE management considerations are discussed in [RFC4655].
In the case of multi-domains within a single service provider In the case of multi-domains within a single service provider
network, the management responsibility for each PCE would most network, the management responsibility for each PCE would most
likely be handled by the same service provider. In the case of likely be handled by the same service provider. In the case of
multiple ASes within different service provider networks, it will multiple ASes within different service provider networks, it will
likely be necessary for each PCE to be configured and managed likely be necessary for each PCE to be configured and managed
separately by each participating service provider, with policy separately by each participating service provider, with policy
being implemented based on an a previously agreed set of principles. being implemented based on an a previously agreed set of principles.
13.1 Control of Function and Policy 13.1 Control of Function and Policy
As per PCEP [RFC5440] implementation allow the user to configure As per PCEP [RFC5440] implementation allow the user to configure
a number of PCEP session parameters. These are detailed in section a number of PCEP session parameters. These are detailed in section
8.1 of [RFC5440] and will not be repeated here. 8.1 of [RFC5440].
In H-PCE deployments the administrative entity responsible for the
management of the parent PCEs for multi-areas would typically be a
single service provider. In the multiple ASes (managed by different
service providers), it may be necessary for a third party to manage
the parent PCE.
13.2 Information and Data Models 13.2 Information and Data Models
A PCEP MIB module is defined in [RFC7420] that describes managed A PCEP MIB module is defined in [RFC7420] that describes managed
objects for modeling of PCEP communication including: objects for modeling of PCEP communication including:
o PCEP client configuration and status, o PCEP client configuration and status,
o PCEP peer configuration and information, o PCEP peer configuration and information,
o PCEP session configuration and information, o PCEP session configuration and information,
o Notifications to indicate PCEP session changes. o Notifications to indicate PCEP session changes.
13.3 Liveness Detection and Monitoring A YANG module for PCEP has also been proposed [PCEP-YANG].
PCEP includes a keepalive mechanism to check the liveliness of a PCEP A H-PCE MIB module, or YANG data model, will be required to
peer and a notification procedure allowing a PCE to advertise its report parent PCE and child PCE information, including:
overloaded state to a PCC. In a multi-domain environment [RFC5886]
provides the procedures necessary to monitor the liveliness and
performances of a given PCE chain.
13.4 Verifying Correct Operation o parent PCE configuration and status,
In order to verify the correct operation of PCEP, [RFC5440] specifies o child PCE configuration and information,
the monitoring of key parameters. These parameters are detailed in
o notifications to indicate session changes between parent PCEs and
child PCEs, and
o notification of parent PCE TED updates and changes.
section 8.4 of [RFC5440] and will not be repeated here. section 8.4 of [RFC5440] and will not be repeated here.
13.5 Impact on Network Operation 13.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, it may also be practical to place a limit on the rate speaker, it may also be practical to place a limit on the rate
of messages sent by a PCC and received my the PCE. of messages sent by a PCC and received my the PCE.
14. Security Considerations 14. Security Considerations
PCEP security is defined [RFC5440]. Any multi-domain operation PCEP security is defined [RFC5440]. Any multi-domain operation
necessarily involves the exchange of information across domain necessarily involves the exchange of information across domain
boundaries. This does represent a significant security and boundaries. This does represent a significant security and
confidentiality risk. PCEP allows individual PCEs to maintain confidentiality risk. PCEP allows individual PCEs to maintain
confidentiality of their domain path information using path-keys confidentiality of their domain path information using path-keys
13.3 Liveness Detection and Monitoring
PCEP includes a keepalive mechanism to check the liveliness of a PCEP
peer and a notification procedure allowing a PCE to advertise its
overloaded state to a PCC. In a multi-domain environment [RFC5886]
provides the procedures necessary to monitor the liveliness and
performances of a given PCE chain.
13.4 Verifying Correct Operation
In order to verify the correct operation of PCEP, [RFC5440] specifies
the monitoring of key parameters. These parameters are detailed in
[RFC5520]. [RFC5520].
For further considerations of the security issues related to inter- As PCEP operates over TCP, it may also make use of TCP security
domain path computation, see [RFC5376]. mechanisms, such as Transport Layer Security (TLS) and TCP
Authentication Option (TCP-AO). Usage of these security mechanisms
for PCEP is described in [PCEPS].
For further considerations of the security issues related PCECP and
to inter-domain path computation, see [RFC6952] and [RFC5376].
15. IANA Considerations 15. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
16. Acknowledgements 16. Acknowledgements
The author would like to thank Adrian Farrel for his review, and The author would like to thank Adrian Farrel for his review, and
Meral Shirazipour and Francisco Javier Jimenex Chico for their Meral Shirazipour and Francisco Javier Jimenex Chico for their
comments. comments.
This work received funding from the European Union's Seventh
Framework Programme for research, technological development and
demonstration through the PACE project under grant agreement no.
619712.
17. References 17. References
17.1. Normative References 17.1. Normative References
17.2. Informative References 17.2. Informative References
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A.
Westerinen, "Policy Core Information Model -- Version 1 Westerinen, "Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001. Specification", RFC 3060, February 2001.
skipping to change at page 22, line 55 skipping to change at page 23, line 18
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005. 2005.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi- Extensions in Support of Generalized Multi-
Protocol Label Switching (GMPLS)", RFC Protocol Label Switching (GMPLS)", RFC
4203, October 2005. 4203, October 2005.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
skipping to change at page 23, line 30 skipping to change at page 23, line 50
RFC 5152, February 2008. RFC 5152, February 2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-Protocol Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, Label Switching (GMPLS)", RFC 5307,
October 2008. October 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", December 2008.
[RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path
Computation Element Communication Protocol (PCECP)", RFC Computation Element Communication Protocol (PCECP)", RFC
5376, November 2008. 5376, November 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
December 2008. December 2008.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol "Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009. (PCEP)", RFC 5440, March 2009.
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
skipping to change at page 24, line 9 skipping to change at page 24, line 40
April 2009. April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) Path Computation Element Communication Protocol (PCEP)
for Route Exclusions", RFC 5521, April 2009. for Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding [RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding
of Objective Functions in the Path Computation Element of Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, December 2008. Communication Protocol (PCEP)", RFC5541, December 2008.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path ComputationElement (PCE)-Based Monitoring Tools for Path ComputationElement (PCE)-Based
Architecture", RFC 5886, June 2010. Architecture", RFC 5886, June 2010.
[RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z., [RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,
Zhao, Q., King, D., "Extensions to the Path Computation Zhao, Q., King, D., "Extensions to the Path Computation
Element Communication Protocol (PCEP) for Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC6006, September 2010. Paths", RFC6006, September 2010.
skipping to change at page 24, line 38 skipping to change at page 25, line 24
Optical Network (ASON). Optical Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing
architecture and requirements for remote route query. architecture and requirements for remote route query.
[RFC6805] King, D. and A. Farrel, "The Application of the Path [RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS & GMPLS", RFC6805, July of a Sequence of Domains in MPLS & GMPLS", RFC6805, July
2010. 2010.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
[RFC7334] Zhao, Q., Dhody, D., Ali Z., King, D., [RFC7334] Zhao, Q., Dhody, D., Ali Z., King, D.,
Casellas, R., "PCE-based Computation Casellas, R., "PCE-based Computation
Procedure To Compute Shortest Constrained Procedure To Compute Shortest Constrained
P2MP Inter-domain Traffic Engineering Label Switched P2MP Inter-domain Traffic Engineering Label Switched
Paths", August 2014. Paths", August 2014.
[RFC7420] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE [RFC7420] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE
Communication Protocol (PCEP) Management Information Communication Protocol (PCEP) Management Information
Base", Decembe4 2014. Base", December 2014.
[BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and TE S. Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", work in progress. Information using BGP", March 2016.
[DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects
Representation Of Domain Sequence", work in progress. for the Path Computation Element Communication Protocol
(PCEP)", June 2016.
[PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
Transport for PCEP", work in progress, November 2015.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", work in progress,
January 2016.
18. Author's Addresses 18. Author's Addresses
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK UK
EMail: daniel@olddog.co.uk EMail: daniel@olddog.co.uk
Julien Meuric Julien Meuric
skipping to change at page 25, line 35 skipping to change at page 26, line 37
EMail: olivier.dugeon@orange-ftgroup.com EMail: olivier.dugeon@orange-ftgroup.com
Quintin Zhao Quintin Zhao
Huawei Technology Huawei Technology
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
US US
EMail: qzhao@huawei.com EMail: qzhao@huawei.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
Emilio Vargas 6, Madrid Emilio Vargas 6, Madrid
Spain Spain
EMail: ogondio@tid.es EMail: ogondio@tid.es
 End of changes. 71 change blocks. 
156 lines changed or deleted 200 lines changed or added

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