draft-ietf-pce-hierarchy-fwk-05.txt   rfc6805.txt 
Network Working Group D. King (Ed.)
Internet-Draft Old Dog Consulting
Intended Status: Informational A. Farrel (Ed.)
Expires: 29 January 2013 Old Dog Consulting
29 August 2012
The Application of the Path Computation Element Architecture to the Internet Engineering Task Force (IETF) D. King, Ed.
Determination of a Sequence of Domains in MPLS and GMPLS Request for Comments: 6805 A. Farrel, Ed.
Category: Informational Old Dog Consulting
ISSN: 2070-1721 November 2012
draft-ietf-pce-hierarchy-fwk-05.txt The Application of the Path Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS and GMPLS
Abstract Abstract
Computing optimum routes for Label Switched Paths (LSPs) across Computing optimum routes for Label Switched Paths (LSPs) across
multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS
networks presents a problem because no single point of path networks presents a problem because no single point of path
computation is aware of all of the links and resources in each computation is aware of all of the links and resources in each
domain. A solution may be achieved using the Path Computation domain. A solution may be achieved using the Path Computation
Element (PCE) architecture. Element (PCE) architecture.
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 optimum path. If the domains are can be employed to derive an optimum path. If the domains are simply
simply-connected, or if the preferred points of interconnection are connected, or if the preferred points of interconnection are also
also known, the Per-Domain Path Computation technique can be used. known, the Per-Domain Path Computation technique can be used. Where
Where there are multiple connections between domains and there is there are multiple connections between domains and there is no
no preference for the choice of points of interconnection, the preference for the choice of points of interconnection, the Backward-
Backward Recursive Path Computation Procedure (BRPC) can be used to Recursive PCE-based Computation (BRPC) procedure can be used to
derive an optimal path. derive an optimal path.
This document examines techniques to establish the optimum path when This document examines techniques to establish the optimum path when
the sequence of domains is not known in advance. The document the sequence of domains is not known in advance. The document shows
shows how the PCE architecture can be extended to allow the optimum how the PCE architecture can be extended to allow the optimum
sequence of domains to be selected, and the optimum end-to-end path sequence of domains to be selected, and the optimum end-to-end path
to be derived through the use of a hierarchical relationship between to be derived through the use of a hierarchical relationship between
domains. domains.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is not an Internet Standards Track specification; it is
and may be updated, replaced, or obsoleted by other documents at any published for informational purposes.
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on 29 August 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6805.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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.
Contents Table of Contents
1. Introduction..................................................3 1. Introduction ....................................................4
1.1 Problem Statement.........................................4 1.1. Problem Statement ..........................................5
1.2 Definition of a Domain............. ......................5 1.2. Definition of a Domain .....................................5
1.3 Assumptions and Requirements..............................5 1.3. Assumptions and Requirements ...............................6
1.3.1 Metric Objectives...................................6 1.3.1. Metric Objectives ...................................6
1.3.2 Diversity...........................................6 1.3.2. Diversity ...........................................7
1.3.2.1 Physical Diversity..........................6 1.3.2.1. Physical Diversity .........................7
1.3.2.2 Domain Diversity............................7 1.3.2.2. Domain Diversity ...........................7
1.3.3 Existing Traffic Engineering Constraints............7 1.3.3. Existing Traffic Engineering Constraints ............7
1.3.4 Commercial Constraints..............................7 1.3.4. Commercial Constraints ..............................8
1.3.5 Domain Confidentiality..............................7 1.3.5. Domain Confidentiality ..............................8
1.3.6 Limiting Information Aggregation....................8 1.3.6. Limiting Information Aggregation ....................8
1.3.7 Domain Interconnection Discovery....................8 1.3.7. Domain Interconnection Discovery ....................8
1.4 Terminology...............................................8 1.4. Terminology ................................................8
2. Examination of Existing PCE Mechanisms........................9 2. Examination of Existing PCE Mechanisms ..........................9
2.1 Per Domain Path Computation...............................9 2.1. Per-Domain Path Computation ................................9
2.2 Backward Recursive Path Computation.......................10 2.2. Backward-Recursive PCE-Based Computation ..................10
2.2.1 Applicability of BRPC when the Domain Path is not 2.2.1. Applicability of BRPC When the Domain Path
Known.................................................10 is Not Known .......................................11
3. Hierarchical PCE..............................................11 3. Hierarchical PCE ...............................................12
4. Hierarchical PCE Procedures...................................12 4. Hierarchical PCE Procedures ....................................13
4.1 Objective Functions and Policy............................12 4.1. Objective Functions and Policy ............................13
4.2 Maintaining Domain Confidentiality........................13 4.2. Maintaining Domain Confidentiality ........................14
4.3 PCE Discovery.............................................13 4.3. PCE Discovery .............................................14
4.4 Parent Domain Traffic Engineering Database................14 4.4. Traffic Engineering Database for the Parent Domain ........15
4.5 Determination of Destination Domain ......................15 4.5. Determination of Destination Domain .......................16
4.6 Hierarchical PCE Examples.................................15 4.6. Hierarchical PCE Examples .................................16
4.6.1 Hierarchical PCE Initial Information Exchange.......17 4.6.1. Hierarchical PCE Initial Information Exchange ......18
4.6.2 Hierarchical PCE End-to-End Path Computation 4.6.2. Hierarchical PCE End-to-End Path
Procedure Example.........................................17 Computation Procedure ..............................19
4.7 Hierarchical PCE Error Handling...........................19 4.7. Hierarchical PCE Error Handling ...........................20
4.8 Hierarchical PCEP Protocol Extensions.....................19 4.8. Requirements for Hierarchical PCEP Protocol Extensions ....20
4.8.1 PCEP Request Qualifiers.............................19 4.8.1. PCEP Request Qualifiers ............................21
4.8.2 Indication of H-PCE Capability......................20 4.8.2. Indication of Hierarchical PCE Capability ..........21
4.8.3 Intention to Utilize Parent PCE Capabilities........20 4.8.3. Intention to Utilize Parent PCE Capabilities .......21
4.8.4 Communication of Domain Connectivity Information....20 4.8.4. Communication of Domain Connectivity Information ...22
4.8.5 Domain Identifiers..................................21 4.8.5. Domain Identifiers .................................22
5. Hierarchical PCE Applicability................................21 5. Hierarchical PCE Applicability .................................23
5.1 autonomous Systems and Areas..............................21 5.1. Autonomous Systems and Areas ..............................23
5.2 ASON architecture (G-7715-2)..............................22 5.2. ASON Architecture .........................................24
5.2.1 Implicit Consistency Between Hierarchical PCE and 5.2.1. Implicit Consistency between Hierarchical
G.7715.2..................................................23 PCE and G.7715.2 ...................................25
5.2.2 Benefits of Hierarchical PCEs in ASON...............24 5.2.2. Benefits of Hierarchical PCEs in ASON ..............26
6. A Note on BGP-TE..............................................24 6. A Note on BGP-TE ...............................................26
6.1 Use of BGP for TED Synchronization........................25 6.1. Use of BGP for TED Synchronization ........................27
7. Management Considerations ....................................25 7. Management Considerations ......................................27
7.1 Control of Function and Policy............................25 7.1. Control of Function and Policy ............................27
7.1.1 Child PCE...........................................25 7.1.1. Child PCE ..........................................27
7.1.2 Parent PCE..........................................26 7.1.2. Parent PCE .........................................27
7.1.3 Policy Control......................................26 7.1.3. Policy Control .....................................28
7.2 Information and Data Models...............................26 7.2. Information and Data Models ...............................28
7.3 Liveness Detection and Monitoring.........................26 7.3. Liveness Detection and Monitoring .........................28
7.4 Verifying Correct Operation...............................26 7.4. Verifying Correct Operation ...............................28
7.5. Impact on Network Operation..............................27 7.5. Impact on Network Operation ...............................29
8. Security Considerations ......................................27 8. Security Considerations ........................................29
9. IANA Considerations ..........................................28 9. Acknowledgements ...............................................30
10. Acknowledgements ............................................28 10. References ....................................................30
11. References ..................................................28 10.1. Normative References .....................................30
11.1. Normative References....................................28 10.2. Informative References ...................................31
11.2. Informative References .................................29 11. Contributors ..................................................32
12. Authors' Addresses ..........................................12
1. Introduction 1. Introduction
The capability to compute the routes of end-to-end inter-domain MPLS The capability to compute the routes of end-to-end inter-domain MPLS
Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs) is Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs)
expressed as requirements in [RFC4105] and [RFC4216]. This capability is expressed as requirements in [RFC4105] and [RFC4216]. This
may be realized by a Path Computation Element (PCE). The PCE capability may be realized by a Path Computation Element (PCE). The
architecture is defined in [RFC4655]. The methods for establishing PCE architecture is defined in [RFC4655]. The methods for
and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are
[RFC4726]. documented in [RFC4726].
In this context, a domain can be defined as a separate In this context, a domain can be defined as a separate
administrative, geographic, or switching environment within the administrative, geographic, or switching environment within the
network. A domain may be further defined as a zone of routing or network. A domain may be further defined as a zone of routing or
computational ability. Under these definitions a domain might be computational ability. Under these definitions, a domain might be
categorized as an autonomous System (AS) or an Interior Gateway categorized as an Autonomous System (AS) or an Interior Gateway
Protocol (IGP) area [RFC4726] and [RFC4655]. Domains are connected Protocol (IGP) area [RFC4726] [RFC4655]. Domains are connected
through ingress and egress boundary nodes (BNs). A more detailed through ingress and egress boundary nodes (BNs). A more detailed
definition is given in Section 1.2. definition is given in Section 1.2.
In a multi-domain environment, the determination of an end-to-end In a multi-domain environment, the determination of an end-to-end
traffic engineered path is a problem because no single point of path traffic engineered path is a problem because no single point of path
computation is aware of all of the links and resources in each computation is aware of all of the links and resources in each
domain. PCEs can be used to compute end-to-end paths using a per- domain. PCEs can be used to compute end-to-end paths using a per-
domain path computation technique [RFC5152]. Alternatively, the domain path computation technique [RFC5152]. Alternatively, the
backward recursive path computation (BRPC) mechanism [RFC5441] Backward-Recursive PCE-based Computation (BRPC) mechanism [RFC5441]
allows multiple PCEs to collaborate in order to select an optimal allows multiple PCEs to collaborate in order to select an optimal
end-to-end path that crosses multiple domains. Both mechanisms end-to-end path that crosses multiple domains. Both mechanisms
assume that the sequence of domains to be crossed between ingress assume that the sequence of domains to be crossed between ingress and
and egress is known in advance. egress is known in advance.
This document examines techniques to establish the optimum path when This document examines techniques to establish the optimum path when
the sequence of domains is not known in advance. It shows how the PCE the sequence of domains is not known in advance. It shows how the
architecture can be extended to allow the optimum sequence of domains PCE architecture can be extended to allow the optimum sequence of
to be selected, and the optimum end-to-end path to be derived. domains to be selected, and the optimum end-to-end path to be
derived.
The model described in this document introduces a hierarchical The model described in this document introduces a hierarchical
relationship between domains. It is applicable to environments with relationship between domains. It is applicable to environments with
small groups of domains where visibility from the ingress Label small groups of domains where visibility from the ingress Label
Switching Router (LSR) is limited. Applying the hierarchical PCE Switching Router (LSR) is limited. Applying the hierarchical PCE
model to large groups of domains such as the Internet, is not model to large groups of domains such as the Internet, is not
considered feasible or desirable, and is out of scope for this considered feasible or desirable, and is out of scope for this
document. document.
This document does not specify any protocol extensions or This document does not specify any protocol extensions or
enhancements. That work is left for future protocol specification enhancements. That work is left for future protocol specification
documents. However, some assumptions are made about which protocols documents. However, some assumptions are made about which protocols
will be used to provide specific functions, and guidelines to will be used to provide specific functions, and guidelines to future
future protocol developers are made in the form of requirements protocol developers are made in the form of requirements statements.
statements.
1.1 Problem Statement 1.1. Problem Statement
Using a PCE to compute a path between nodes within a single domain is Using a PCE to compute a path between nodes within a single domain is
relatively straightforward. Computing an end-to-end path when the relatively straightforward. Computing an end-to-end path when the
source and destination nodes are located in different domains source and destination nodes are located in different domains
requires co-operation between multiple PCEs, each responsible for requires co-operation between multiple PCEs, each responsible for its
its own domain. own domain.
Techniques for inter-domain path computation described so far Techniques for inter-domain path computation described so far
([RFC5152] and [RFC5441]) assume that the sequence of domains to be ([RFC5152] and [RFC5441]) assume that the sequence of domains to be
crossed from source to destination is well known. No explanation is crossed from source to destination is well known. No explanation is
given (for example, in [RFC4655]) of how this sequence is generated given (for example, in [RFC4655]) of how this sequence is generated
or what criteria may be used for the selection of paths between or what criteria may be used for the selection of paths between
domains. In small clusters of domains, such as simple cooperation domains. In small clusters of domains, such as simple cooperation
between adjacent ISPs, this selection process is not complex. In more between adjacent ISPs, this selection process is not complex. In
advanced deployments (such as optical networks constructed from more advanced deployments (such as optical networks constructed from
multiple sub-domains, or in multi-AS environments) the choice of multiple sub-domains, or in multi-AS environments), the choice of
domains in the end-to-end domain sequence can be critical to the domains in the end-to-end domain sequence can be critical to the
determination of an optimum end-to-end path. determination of an optimum end-to-end path.
1.2 Definition of a Domain 1.2. Definition of a Domain
A domain is defined in [RFC4726] as any collection of network A domain is defined in [RFC4726] as any collection of network
elements within a common sphere of address management or path elements within a common sphere of address management or path
computational responsibility. Examples of such domains include computational responsibility. Examples of such domains include IGP
IGP areas and Autonomous Systems. Wholly or partially overlapping areas and Autonomous Systems. Wholly or partially overlapping
domains are not within the scope of this document. domains are not within the scope of 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, a domain might be an ASON Routing Area [G-8080]. In this case, a domain might be an ASON Routing Area
[G-7715]. Furthermore, computation of an end-to-end path requires [G-7715]. Furthermore, computation of an end-to-end path requires
the selection of nodes and links within a routing area where some the selection of nodes and links within a routing area where some
nodes may, in fact, be subnetworks. A PCE may perform the path nodes may, in fact, be subnetworks. A PCE may perform the path
computation function of an ASON Routing Controller as described in computation function of an ASON Routing Controller as described in
[G-7715-2]. See Section 5.2 for a further discussion of the [G-7715-2]. See Section 5.2 for a further discussion of the
applicability to the ASON architecture. applicability to the ASON architecture.
This document assumes that the selection of a sequence of domains for This document assumes that the selection of a sequence of domains for
an end-to-end path is in some sense a hierarchical path computation an end-to-end path is in some sense a hierarchical path computation
problem. That is, where one mechanism is used to determine a path problem. That is, where one mechanism is used to determine a path
across a domain, a separate mechanism (or at least a separate set across a domain, a separate mechanism (or at least a separate set of
of paradigms) is used to determine the sequence of domains. The paradigms) is used to determine the sequence of domains. The
responsibility for the selection of domain interconnection can belong responsibility for the selection of domain interconnection can belong
to either or both of the mechanisms. to either or both of the mechanisms.
1.3 Assumptions and Requirements 1.3. Assumptions and Requirements
Networks are often constructed from multiple domains. These Networks are often constructed from multiple domains. These domains
domains are often interconnected via multiple interconnect points. are often interconnected via multiple interconnect points. It's
Its assumed that the sequence of domains for an end-to-end path is assumed that the sequence of domains for an end-to-end path is not
not always well known; that is, an application requesting end-to-end always well known; that is, an application requesting end-to-end
connectivity has no preference for, or no ability to specify, the connectivity has no preference for, or no ability to specify, the
sequence of domains to be crossed by the path. sequence of domains to be crossed by the path.
The traffic engineering properties of a domain cannot be seen from The traffic engineering properties of a domain cannot be seen from
outside the domain. Traffic engineering aggregation or abstraction, outside the domain. Traffic engineering aggregation or abstraction,
hides information and can lead to failed path setup or the selection hides information and can lead to failed path setup or the selection
of suboptimal end-to-end paths [RFC4726]. The aggregation process of suboptimal end-to-end paths [RFC4726]. The aggregation process
may also have significant scaling issues for networks with many may also have significant scaling issues for networks with many
possible routes and multiple TE metrics. Flooding TE information possible routes and multiple TE metrics. Flooding TE information
breaks confidentiality and does not scale in the routing protocol. breaks confidentiality and does not scale in the routing protocol.
See Section 6 for a discussion of the concept of inter-domain traffic See Section 6 for a discussion of the concept of inter-domain traffic
engineering information exchange known as BGP-TE. engineering information exchange known as BGP-TE.
The primary goal of this document is to define how to derive optimal The primary goal of this document is to define how to derive optimal
end-to-end, multi-domain paths when the sequence of domains is not end-to-end, multi-domain paths when the sequence of domains is not
known in advance. The solution needs to be scalable and to maintain known in advance. The solution needs to be scalable and to maintain
internal domain topology confidentiality while providing the optimal internal domain topology confidentiality while providing the optimal
end-to-end path. It cannot rely on the exchange of TE information end-to-end path. It cannot rely on the exchange of TE information
between domains, and for the confidentiality, scaling, and between domains, and for the confidentiality, scaling, and
aggregation reasons just cited, it cannot utilize a computation aggregation reasons just cited, it cannot utilize a computation
element that has universal knowledge of TE properties and topology element that has universal knowledge of TE properties and topology of
of all domains. all domains.
The sub-sections that follow set out the primary objectives and The sub-sections that follow set out the primary objectives and
requirements to be satisfied by a PCE solution to multi-domain path requirements to be satisfied by a PCE solution to multi-domain path
computation. computation.
1.3.1 Metric Objectives 1.3.1. Metric Objectives
The definition of optimality is dependent on policy, and is based on The definition of optimality is dependent on policy and is based on a
a single objective or a group objectives. An objective is expressed single objective or a group of objectives. An objective is expressed
as an objective function [RFC5541] and may be specified on a path as an objective function [RFC5541] and may be specified on a path
computation request. The following objective functions are identified computation request. The following objective functions are
in this document. They define how the path metrics and TE link identified in this document. They define how the path metrics and TE
qualities are manipulated during inter-domain path computation. The link qualities are manipulated during inter-domain path computation.
list is not proscriptive and may be expanded in other documents. The list is not proscriptive and may be expanded in other documents.
o Minimize the cost of the path [RFC5541] o Minimize the cost of the path [RFC5541].
o Select a path using links with the minimal load [RFC5541] o Select a path using links with the minimal load [RFC5541].
o Select a path that leaves the maximum residual bandwidth [RFC5541] o Select a path that leaves the maximum residual bandwidth
o Minimize aggregate bandwidth consumption [RFC5541] [RFC5541].
o Minimize the Load of the most loaded Link [RFC5541] o Minimize aggregate bandwidth consumption [RFC5541].
o Minimize the Cumulative Cost of a set of paths [RFC5541] o Minimize the load of the most loaded link [RFC5541].
o Minimize or cap the number of domains crossed o Minimize the cumulative cost of a set of paths [RFC5541].
o Disallow domain re-entry o Minimize or cap the number of domains crossed.
o Disallow domain re-entry.
See Section 4.1 for further discussion of objective functions. See Section 4.1 for further discussion of objective functions.
1.3.2 Diversity 1.3.2. Diversity
1.3.2.1 Physical Diversity 1.3.2.1. Physical Diversity
Within a Carrier's carrier environment MPLS services may share common Within a "Carrier's Carrier" environment, MPLS services may share
underlying equipment and resources, including optical fiber and common underlying equipment and resources, including optical fiber
nodes. An MPLS service request may require a path for traffic that is and nodes. An MPLS service request may require a path for traffic
physically disjointed from another service. Thus, if a physical link that is physically disjointed from another service. Thus, if a
or node fails on one of the disjoint paths, not all traffic is lost. physical link or node fails on one of the disjoint paths, not all
traffic is lost.
1.3.2.2 Domain Diversity 1.3.2.2. Domain Diversity
A pair of paths are domain-diverse if they do not transit any of the A pair of paths are domain-diverse if they do not transit any of the
same domains. A pair of paths that share a common ingress and egress same domains. A pair of paths that share a common ingress and egress
are domain-diverse if they only share the same domains at the ingress are domain-diverse if they only share the same domains at the ingress
and egress (the ingress and egress domains). Domain diversity may be and egress (the ingress and egress domains). Domain diversity may be
maximized for a pair of paths by selecting paths that have the maximized for a pair of paths by selecting paths that have the
smallest number of shared domains. (Note that this is not the same smallest number of shared domains. (Note that this is not the same
as finding paths with the greatest number of distinct domains!) as finding paths with the greatest number of distinct domains!)
Path computation should facilitate the selection of paths that share Path computation should facilitate the selection of paths that share
ingress and egress domains, but do not share any transit domains. ingress and egress domains but do not share any transit domains.
This provides a way to reduce the risk of shared failure along any This provides a way to reduce the risk of shared failure along any
path, and automatically helps to ensure path diversity for most of path and automatically helps to ensure path diversity for most of the
the route of a pair of LSPs. route of a pair of LSPs.
Thus, domain path selection should provide the capability to include Thus, domain path selection should provide the capability to include
or exclude specific domains and specific boundary nodes. or exclude specific domains and specific boundary nodes.
1.3.3 Existing Traffic Engineering Constraints 1.3.3. Existing Traffic Engineering Constraints
Any solution should take advantage of typical traffic engineering Any solution should take advantage of typical traffic engineering
constraints (hop count, bandwidth, lambda continuity, path cost, constraints (hop count, bandwidth, lambda continuity, path cost,
etc.) to meet the service demands expressed in the path computation etc.) to meet the service demands expressed in the path computation
request [RFC4655]. request [RFC4655].
1.3.4 Commercial Constraints 1.3.4. Commercial Constraints
The solution should provide the capability to include commercially The solution should provide the capability to include commercially
relevant constraints such as policy, SLAs, security, peering relevant constraints such as policy, Service Level Agreements (SLAs),
preferences, and monetary costs. security, peering preferences, and monetary costs.
Additionally it may be necessary for the service provider to Additionally, it may be necessary for the service provider to request
request that specific domains are included or excluded based on that specific domains are included or excluded based on commercial
commercial relationships, security implications, and reliability. relationships, security implications, and reliability.
1.3.5 Domain Confidentiality 1.3.5. Domain Confidentiality
A key requirement is the ability to maintain domain confidentiality A key requirement is the ability to maintain domain confidentiality
when computing inter-domain end-to-end paths. It should be possible when computing inter-domain end-to-end paths. It should be possible
for local policy to require that a PCE not disclose to any other PCE for local policy to require that a PCE not disclose to any other PCE
the intra-domain paths it computes or the internal topology of the the intra-domain paths it computes or the internal topology of the
domain it serves. This requirement should have no impact in the domain it serves. This requirement should have no impact in the
optimality or quality of the end-to-end path that is derived. optimality or quality of the end-to-end path that is derived.
1.3.6 Limiting Information Aggregation 1.3.6. Limiting Information Aggregation
In order to reduce processing overhead and to not sacrifice In order to reduce processing overhead and to not sacrifice
computational detail, there should be no requirement to aggregate or computational detail, there should be no requirement to aggregate or
abstract traffic engineering link information. abstract traffic engineering link information.
1.3.7 Domain Interconnection Discovery 1.3.7. Domain Interconnection Discovery
To support domain mesh topologies, the solution should allow the To support domain mesh topologies, the solution should allow the
discovery and selection of domain inter-connections. Pre- discovery and selection of domain interconnections. Pre-
configuration of preferred domain interconnections should also be configuration of preferred domain interconnections should also be
supported for network operators that have bilateral agreement, and supported for network operators that have bilateral agreement and
preference for the choice of points of interconnection. have a preference for the choice of points of interconnection.
1.4 Terminology 1.4. Terminology
This document uses PCE terminology defined in [RFC4655], [RFC4726], This document uses PCE terminology defined in [RFC4655], [RFC4726],
and [RFC5440]. Additional terms are defined below. and [RFC5440]. Additional terms are defined below.
Domain Path: The sequence of domains for a path. Domain Path: The sequence of domains for a path.
Ingress Domain: The domain that includes the ingress LSR of a path. Ingress Domain: The domain that includes the ingress LSR of a path.
Transit Domain: A domain that has an upstream and downstream Transit Domain: A domain that has an upstream and downstream neighbor
neighbor domain for a specific path. domain for a specific path.
Egress Domain: The domain that includes the egress LSR of a path. Egress Domain: The domain that includes the egress LSR of a path.
Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could
be Area Border Routers (ABRs) or Autonomous System Border Routers be Area Border Routers (ABRs) or Autonomous System Border Routers
(ASBRs) depending on the type of domain. They are defined here more (ASBRs) depending on the type of domain. They are defined here more
generically as Boundary Nodes (BNs). generically as Boundary Nodes (BNs).
Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a
on a path. path.
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a
on a path. path.
Parent Domain: A domain higher up in a domain hierarchy such Parent Domain: A domain higher up in a domain hierarchy such that it
that it contains other domains (child domains) and potentially other contains other domains (child domains) and potentially other links
links and nodes. and nodes.
Child Domain: A domain lower in a domain hierarchy such that it has Child Domain: A domain lower in a domain hierarchy such that it has a
a parent domain. parent domain.
Parent PCE: A PCE responsible for selecting a path across a parent Parent PCE: A PCE responsible for selecting a path across a parent
domain and any number of child domains by coordinating with child domain and any number of child domains by coordinating with child
PCEs and examining a topology map that shows domain inter- PCEs and examining a topology map that shows domain inter-
connectivity. connectivity.
Child PCE: A PCE responsible for computing the path across one or Child PCE: A PCE responsible for computing the path across one or
more specific (child) domains. A child PCE maintains a relationship more specific (child) domains. A child PCE maintains a relationship
with at least one parent PCE. with at least one parent PCE.
OF: Objective Function: A set of one or more optimization Objective Function (OF): A set of one or more optimization criteria
criteria used for the computation of a single path (e.g., path cost used for the computation of a single path (e.g., path cost
minimization), or the synchronized computation of a set of paths minimization), or the synchronized computation of a set of paths
(e.g., aggregate bandwidth consumption minimization). See [RFC4655] (e.g., aggregate bandwidth consumption minimization). See [RFC4655]
and [RFC5541]. and [RFC5541].
2. Examination of Existing PCE Mechanisms 2. Examination of Existing PCE Mechanisms
This section provides a brief overview of two existing PCE This section provides a brief overview of two existing PCE
cooperation mechanisms called the per-domain path computation method, cooperation mechanisms called the Per-Domain Path Computation method
and the backward recursive path computation method. It describes the and the BRPC method. It describes the applicability of these methods
applicability of these methods to the multi-domain problem. to the multi-domain problem.
2.1 Per-Domain Path Computation 2.1. Per-Domain Path Computation
The per-domain path computation method for establishing inter-domain The Per-Domain Path Computation method for establishing inter-domain
TE-LSPs [RFC5152] defines a technique whereby the path is computed TE-LSPs [RFC5152] defines a technique whereby the path is computed
during the signalling process on a per-domain basis. The entry BN of during the signaling process on a per-domain basis. The entry BN of
each domain is responsible for performing the path computation for each domain is responsible for performing the path computation for
the section of the LSP that crosses the domain, or for requesting the section of the LSP that crosses the domain, or for requesting
that a PCE for that domain computes that piece of the path. that a PCE for that domain computes that piece of the path.
During per-domain path computation, each computation results in the During per-domain path computation, each computation results in a
best path across the domain to provide connectivity to the next path that crosses the domain to provide connectivity to the next
domain in the domain sequence (usually indicated in signalling by an domain in the sequence. The chosen path across the domain will be
identifier of the next domain or the identity of the next entry BN). selected as best according to the optimization characteristics of the
computation. The next domain in the sequence is usually indicated in
signaling by an identifier of the next domain or the identity of the
next entry BN.
Per-domain path computation may lead to sub-optimal end-to-end paths Per-domain path computation may lead to suboptimal end-to-end paths
because the most optimal path in one domain may lead to the choice of because the most optimal path in one domain may lead to the choice of
an entry BN for the next domain that results in a very poor path an entry BN for the next domain that results in a very poor path
across that next domain. across that next domain.
In the case that the domain path (in particular, the sequence of In the case that the domain path (in particular, the sequence of
boundary nodes) is not known, the path computing entity must select boundary nodes) is not known, the path computing entity must select
an exit BN based on some determination of how to reach the an exit BN based on some determination of how to reach the
destination that is outside the domain for which the path computing destination that is outside the domain for which the path computing
entity has computational responsibility. [RFC5152] suggest that this entity has computational responsibility. [RFC5152] suggest that this
might be achieved using the IP shortest path as advertise by BGP. might be achieved using the IP shortest path as advertised by BGP.
Note, however, that the existence of an IP forwarding path does not Note, however, that the existence of an IP forwarding path does not
guarantee the presence of sufficient bandwidth, let alone an optimal guarantee the presence of sufficient bandwidth, let alone an optimal
TE path. Furthermore, in many GMPLS systems inter-domain IP routing TE path. Furthermore, in many GMPLS systems, inter-domain IP routing
will not be present. Thus, per-domain path computation may require a will not be present. Thus, per-domain path computation may require a
significant number of crankback routing attempts to establish even a significant number of crankback routing attempts to establish even a
sub-optimal path. suboptimal path.
Note also that the path computing entities in each domain may have Note also that the path computing entities in each domain may have
different computation capabilities, may run different path different computation capabilities, may run different path
computation algorithms, and may apply different sets of constraints computation algorithms, and may apply different sets of constraints
and optimization criteria, etc. and optimization criteria, etc.
This can result in the end-to-end path being inconsistent and sub- This can result in the end-to-end path being inconsistent and
optimal. suboptimal.
Per-domain path computation can suit simply-connected domains where Per-domain path computation can suit simply connected domains where
the preferred points of interconnection are known. the preferred points of interconnection are known.
2.2 Backward Recursive Path Computation 2.2. Backward-Recursive PCE-Based Computation
The Backward Recursive Path Computation (BRPC) [RFC5441] procedure The Backward-Recursive PCE-based Computation (BRPC) [RFC5441]
involves cooperation and communication between PCEs in order to procedure involves cooperation and communication between PCEs in
compute an optimal end-to-end path across multiple domains. The order to compute an optimal end-to-end path across multiple domains.
sequence of domains to be traversed can either be determined before The sequence of domains to be traversed can be determined either
or during the path computation. In the case where the sequence of before or during the path computation. In the case where the
domains is known, the ingress Path Computation Client (PCC) sends a sequence of domains is known, the ingress Path Computation Client
path computation request to a PCE responsible for the ingress (PCC) sends a path computation request to a PCE responsible for the
domain. This request is forwarded between PCEs, domain-by-domain, to ingress domain. This request is forwarded between PCEs, domain-by-
a PCE responsible for the egress domain. The PCE in the egress domain, to a PCE responsible for the egress domain. The PCE in the
domain creates a set of optimal paths from all of the domain entry egress domain creates a set of optimal paths from all of the domain
BNs to the egress LSR. This set is represented as a tree of potential entry BNs to the egress LSR. This set is represented as a tree of
paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes potential paths called a Virtual Shortest Path Tree (VSPT), and the
it back to the previous PCE on the domain path. As the VSPT is passed PCE passes it back to the previous PCE on the domain path. As the
back toward the ingress domain, each PCE computes the optimal paths VSPT is passed back toward the ingress domain, each PCE computes the
from its entry BNs to its exit BNs that connect to the rest of the optimal paths from its entry BNs to its exit BNs that connect to the
tree. It adds these paths to the VSPT and passes the VSPT on until rest of the tree. It adds these paths to the VSPT and passes the
the PCE for the ingress domain is reached and computes paths from the VSPT on until the PCE for the ingress domain is reached and computes
ingress LSR to connect to the rest of the tree. The ingress PCE then paths from the ingress LSR to connect to the rest of the tree. The
selects the optimal end-to-end path from the tree, and returns the ingress PCE then selects the optimal end-to-end path from the tree,
path to the initiating PCC. and returns the path to the initiating PCC.
BRPC may suit environments where multiple connections exist between BRPC may suit environments where multiple connections exist between
domains and there is no preference for the choice of points of domains and there is no preference for the choice of points of
interconnection. It is best suited to scenarios where the domain interconnection. It is best suited to scenarios where the domain
path is known in advance, but can also be used when the domain path path is known in advance, but it can also be used when the domain
is not known. path is not known.
2.2.1. Applicability of BRPC when the Domain Path is Not Known 2.2.1. Applicability of BRPC When the Domain Path is Not Known
As described above, BRPC can be used to determine an optimal inter- As described above, BRPC can be used to determine an optimal inter-
domain path when the domain sequence is known. Even when the sequence domain path when the domain sequence is known. Even when the
of domains is not known BRPC could be used as follows. sequence of domains is not known, BRPC could be used as follows.
o The PCC sends a request to a PCE for the ingress domain (the o The PCC sends a request to a PCE for the ingress domain (the
ingress PCE). ingress PCE).
o The ingress PCE sends the path computation request direct to a o The ingress PCE sends the path computation request direct to a PCE
PCE responsible for the domain containing the destination node (the responsible for the domain containing the destination node (the
egress PCE). egress PCE).
o The egress PCE computes an egress VSPT and passes it to a PCE o The egress PCE computes an egress VSPT and passes it to a PCE
responsible for each of the adjacent (potentially upstream) responsible for each of the adjacent (potentially upstream)
domains. domains.
o Each PCE in turn constructs a VSPT and passes it on to all of its o Each PCE in turn constructs a VSPT and passes it on to all of its
neighboring PCEs. neighboring PCEs.
o When the ingress PCE has received a VSPT from each of its o When the ingress PCE has received a VSPT from each of its
neighboring domains it is able to select the optimum path. neighboring domains, it is able to select the optimum path.
Clearly this mechanism (which could be called path computation Clearly, this mechanism (which could be called path computation
flooding) has significant scaling issues. It could be improved by flooding) has significant scaling issues. It could be improved by
the application of policy and filtering, but such mechanisms are not the application of policy and filtering, but such mechanisms are not
simple and would still leave scaling concerns. simple and would still leave scaling concerns.
3. Hierarchical PCE 3. Hierarchical PCE
In the hierarchical PCE architecture, a parent PCE maintains a domain In the hierarchical PCE architecture, a parent PCE maintains a domain
topology map that contains the child domains (seen as vertices in the topology map that contains the child domains (seen as vertices in the
topology) and their interconnections (links in the topology). The topology) and their interconnections (links in the topology). The
parent PCE has no information about the content of the child domains; parent PCE has no information about the content of the child domains;
that is, the parent PCE does not know about the resource availability that is, the parent PCE does not know about the resource availability
within the child domains, nor about the availability of connectivity within the child domains, nor does it know about the availability of
across each domain because such knowledge would violate the connectivity across each domain because such knowledge would violate
confidentiality requirement and would either require flooding of full the confidentiality requirement and either would require flooding of
information to the parent (scaling issue) or would necessitate some full information to the parent (scaling issue) or would necessitate
form of aggregation. The parent PCE is aware of the TE capabilities some form of aggregation. The parent PCE is aware of the TE
of the interconnections between child domains as these capabilities of the interconnections between child domains as these
interconnections are links in its own topology map. interconnections are links in its own topology map.
Note that in the case that the domains are IGP areas, there is no Note that, in the case that the domains are IGP areas, there is no
link between the domains (the ABRs have a presence in both link between the domains (the ABRs have a presence in both
neighboring areas). The parent domain may choose to represent this in neighboring areas). The parent domain may choose to represent this
its TED as a virtual link that is unconstrained and has zero cost, in its Traffic Engineering Database (TED) as a virtual link that is
but this is entirely an implementation issue. unconstrained and has zero cost, but this is entirely an
implementation issue.
Each child domain has at least one PCE capable of computing paths Each child domain has at least one PCE capable of computing paths
across the domain. These PCEs are known as child PCEs and have a across the domain. These PCEs are known as child PCEs and have a
relationship with the parent PCE. Each child PCE also knows the relationship with the parent PCE. Each child PCE also knows the
identity of the domains that neighbor its own domain. A child PCE identity of the domains that neighbor its own domain. A child PCE
only knows the topology of the domain that it serves and does not only knows the topology of the domain that it serves and does not
know the topology of other child domains. Child PCEs are also not know the topology of other child domains. Child PCEs are also not
aware of the general domain mesh connectivity (i.e., the domain aware of the general domain mesh connectivity (i.e., the domain
topology map) beyond the connectivity to the immediate neighbor topology map) beyond the connectivity to the immediate neighbor
domains of the domain it serves. domains of the domain it serves.
The parent PCE builds the domain topology map either from The parent PCE builds the domain topology map either from
configuration or from information received from each child PCE. This configuration or from information received from each child PCE. This
tells it how the domains are interconnected including the TE tells it how the domains are interconnected including the TE
properties of the domain interconnections. But the parent PCE does properties of the domain interconnections. But, the parent PCE does
not know the contents of the child domains. Discovery of the domain not know the contents of the child domains. Discovery of the domain
topology and domain interconnections is discussed further in Section topology and domain interconnections is discussed further in Section
4.3. 4.3.
When a multi-domain path is needed, the ingress PCE sends a request When a multi-domain path is needed, the ingress PCE sends a request
to the parent PCE (using the path computation element protocol, PCEP to the parent PCE (using the Path Computation Element Protocol, PCEP
[RFC5440]). The parent PCE selects a set of candidate domain paths [RFC5440]). The parent PCE selects a set of candidate domain paths
based on the domain topology and the state of the inter-domain links. based on the domain topology and the state of the inter-domain links.
It then sends computation requests to the child PCEs responsible for It then sends computation requests to the child PCEs responsible for
each of the domains on the candidate domain paths. These requests may each of the domains on the candidate domain paths. These requests
be sequential or parallel depending on implementation details. may be sequential or parallel depending on implementation details.
Each child PCE computes a set of candidate path segments across its Each child PCE computes a set of candidate path segments across its
domain and sends the results to the parent PCE. The parent PCE uses domain and sends the results to the parent PCE. The parent PCE uses
this information to select path segments and concatenate them to this information to select path segments and concatenate them to
derive the optimal end-to-end inter-domain path. The end-to-end path derive the optimal end-to-end inter-domain path. The end-to-end path
is then sent to the child PCE which received the initial path request is then sent to the child PCE that received the initial path request,
and this child PCE passes the path on to the PCC that issued the and this child PCE passes the path on to the PCC that issued the
original request. original request.
Specific deployment and implementation scenarios are out of scope of Specific deployment and implementation scenarios are out of scope of
this document. However the hierarchical PCE architecture described this document. However, the hierarchical PCE architecture described
does support the function of parent PCE and child PCE being does support the function of parent PCE and child PCE being
implemented as a common PCE. implemented as a common PCE.
4. Hierarchical PCE Procedures 4. Hierarchical PCE Procedures
4.1 Objective Functions and Policy 4.1. Objective Functions and Policy
Deriving the optimal end-to-end domain path sequence is dependent on The definition of "optimal" in the context of deriving an optimal
the policy applied during domain path computation. An Objective end-to-end path is dependent on the choices that are made during the
Function (OF) [RFC5541], or set of OFs, may be applied to define the path selection. An Objective Function (OF) [RFC5541], or set of OFs,
policy being applied to the domain path computation. specify the intentions of the path computation and so define the
"optimality" in the context of that computation.
The OF specifies the desired outcome of the computation. It does An OF specifies the desired outcome of a computation: it does not
not describe the algorithm to use. When computing end-to-end inter- describe or demand the algorithm to use, and an implementation may
domain paths, required OFs may include (see Section 1.3.1): apply any algorithm or set of algorithms to achieve the result
indicated by the OF. OFs can be included in PCEP computation
requests to satisfy the policies encoded or configured at the PCC,
and a PCE may be subject to policy in determining whether it meets
the OFs included in the computation request, or applies its own OFs.
o Minimum cost path In inter-domain path computation, the selection of a domain sequence,
o Minimum load path the computation of each (per-domain) path fragment, and the
o Maximum residual bandwidth path determination of the end-to-end path may each be subject to different
o Minimize aggregate bandwidth consumption OFs and different policy.
o Minimize or cap the number of transit domains
o Disallow domain re-entry When computing end-to-end paths, OFs may include (see Section 1.3.1):
o Minimum cost path
o Minimum load path
o Maximum residual bandwidth path
o Minimize aggregate bandwidth consumption
o Minimize or cap the number of transit domains
o Disallow domain re-entry
The objective function may be requested by the PCC, the ingress The objective function may be requested by the PCC, the ingress
domain PCE (according to local policy), or applied by the parent PCE domain PCE (according to local policy), or applied by the parent PCE
according to inter-domain policy. according to inter-domain policy.
More than one OF (or a composite OF) may be chosen to apply to a More than one OF (or a composite OF) may be chosen to apply to a
single computation provided they are not contradictory. Composite OFs single computation provided they are not contradictory. Composite
may include weightings and preferences for the fulfilment of pieces OFs may include weightings and preferences for the fulfillment of
of the desired outcome. pieces of the desired outcome.
4.2 Maintaining Domain Confidentiality 4.2. Maintaining Domain Confidentiality
Information about the content of child domains is not shared for Information about the content of child domains is not shared for
scaling and confidentiality reasons. This means that a parent PCE is scaling and confidentiality reasons. This means that a parent PCE is
aware of the domain topology and the nature of the connections aware of the domain topology and the nature of the connections
between domains, but is not aware of the content of the domains. between domains but is not aware of the content of the domains.
Similarly, a child PCE cannot know the internal topology of another Similarly, a child PCE cannot know the internal topology of another
child domain. Child PCEs also do not know the general domain mesh child domain. Child PCEs also do not know the general domain mesh
connectivity, this information is only known by the parent PCE. connectivity; this information is only known by the parent PCE.
As described in the earlier sections of this document, PCEs can As described in the earlier sections of this document, PCEs can
exchange path information in order to construct an end-to-end inter- exchange path information in order to construct an end-to-end inter-
domain path. Each per-domain path fragment reveals information about domain path. Each per-domain path fragment reveals information about
the topology and resource availability within a domain. Some the topology and resource availability within a domain. Some
management domains or ASes will not want to share this information management domains or ASes will not want to share this information
outside of the domain (even with a trusted parent PCE). In order to outside of the domain (even with a trusted parent PCE). In order to
conceal the information, a PCE may replace a path segment with a conceal the information, a PCE may replace a path segment with a
path-key [RFC5520]. This mechanism effectively hides the content of a path-key [RFC5520]. This mechanism effectively hides the content of
segment of a path. a segment of a path.
4.3 PCE Discovery 4.3. PCE Discovery
It is a simple matter for each child PCE to be configured with the It is a simple matter for each child PCE to be configured with the
address of its parent PCE. Typically, there will only be one or two address of its parent PCE. Typically, there will only be one or two
parents of any child. parents of any child.
The parent PCE also needs to be aware of the child PCEs for all child The parent PCE also needs to be aware of the child PCEs for all child
domains that it can see. This information is most likely to be domains that it can see. This information is most likely to be
configured (as part of the administrative definition of each configured (as part of the administrative definition of each domain).
domain).
Discovery of the relationships between parent PCEs and child PCEs Discovery of the relationships between parent PCEs and child PCEs
does not form part of the hierarchical PCE architecture. Mechanisms does not form part of the hierarchical PCE architecture. Mechanisms
that rely on advertising or querying PCE locations across domain or that rely on advertising or querying PCE locations across domain or
provider boundaries are undesirable for security, scaling, provider boundaries are undesirable for security, scaling,
commercial, and confidentiality reasons. commercial, and confidentiality reasons.
The parent PCE also needs to know the inter-domain connectivity. The parent PCE also needs to know the inter-domain connectivity.
This information could be configured with suitable policy and This information could be configured with suitable policy and
commercial rules, or could be learned from the child PCEs as commercial rules, or could be learned from the child PCEs as
described in Section 4.4. described in Section 4.4.
In order for the parent PCE to learn about domain interconnection In order for the parent PCE to learn about domain interconnection,
the child PCE will report the identity of its neighbor domains. The the child PCE will report the identity of its neighbor domains. The
IGP in each neighbor domain can advertise its inter-domain TE IGP in each neighbor domain can advertise its inter-domain TE link
link capabilities [RFC5316], [RFC5392]. This information can be capabilities [RFC5316] [RFC5392]. This information can be collected
collected by the child PCEs and forwarded to the parent PCE, or the by the child PCEs and forwarded to the parent PCE, or the parent PCE
parent PCE could participate in the IGP in the child domains. could participate in the IGP in the child domains.
4.4 Parent Domain Traffic Engineering Database 4.4. Traffic Engineering Database for the Parent Domain
The parent PCE maintains a domain topology map of the child domains The parent PCE maintains a domain topology map of the child domains
and their interconnectivity. Where inter-domain connectivity is and their interconnectivity. Where inter-domain connectivity is
provided by TE links the capabilities of those links may also be provided by TE links, the capabilities of those links may also be
known to the parent PCE. The parent PCE maintains a traffic known to the parent PCE. The parent PCE maintains a TED for the
engineering database (TED) for the parent domain in the same way that parent domain in the same way that any PCE does.
any PCE does.
The parent domain may just be the collection of child domains and The parent domain may just be the collection of child domains and
their interconnectivity, may include details of the inter-domain TE their interconnectivity, may include details of the inter-domain TE
links, and may contain nodes and links in its own right. links, and may contain nodes and links in its own right.
The mechanism for building the parent TED is likely to rely heavily The mechanism for building the parent TED is likely to rely heavily
on administrative configuration and commercial issues because the on administrative configuration and commercial issues because the
network was probably partitioned into domains specifically to address network was probably partitioned into domains specifically to address
these issues. these issues.
In practice, certain information may be passed from the child domains In practice, certain information may be passed from the child domains
to the parent PCE to help build the parent TED. In theory, the parent to the parent PCE to help build the parent TED. In theory, the
PCE could listen to the routing protocols in the child domains, but parent PCE could listen to the routing protocols in the child
this would violate the confidentiality and scaling issues that may be domains, but this would violate the confidentiality and scaling
responsible for the partition of the network into domains. So it is principles that may be responsible for the partition of the network
much more likely that a suitable solution will involve specific into domains. So, it is much more likely that a suitable solution
communication from an entity in the child domain (such as the child will involve specific communication from an entity in the child
PCE) to convey the necessary information. As already mentioned, the domain (such as the child PCE) to convey the necessary information.
"necessary information" relates to how the child domains are inter- As already mentioned, the "necessary information" relates to how the
connected. The topology and available resources within the child child domains are inter-connected. The topology and available
domain do not need to be communicated to the parent PCE: doing so resources within the child domain do not need to be communicated to
would violate the PCE architecture. Mechanisms for reporting this the parent PCE: doing so would violate the PCE architecture.
information are described in the examples in Section 4.6 in abstract Mechanisms for reporting this information are described in the
terms as "a child PCE reports its neighbor domain connectivity to its examples in Section 4.6 in abstract terms as a child PCE "reports its
parent PCE"; the specifics of a solution are out of scope of this neighbor domain connectivity to its parent PCE"; the specifics of a
document, but the requirements are indicated in Section 4.8. See solution are out of scope of this document, but the requirements are
Section 6 for a brief discussion of BGP-TE. indicated in Section 4.8. See Section 6 for a brief discussion of
BGP-TE.
In models such as ASON (see Section 5.2), it is possible to consider In models such as ASON (see Section 5.2), it is possible to consider
a separate instance of an IGP running within the parent domain where a separate instance of an IGP running within the parent domain where
the participating protocol speakers are the nodes directly present in the participating protocol speakers are the nodes directly present in
that domain and the PCEs (Routing Controllers) responsible for each that domain and the PCEs (Routing Controllers) responsible for each
of the child domains. of the child domains.
4.5 Determination of Destination Domain 4.5. Determination of Destination Domain
The PCC asking for an inter-domain path computation is aware of the The PCC asking for an inter-domain path computation is aware of the
identity of the destination node by definition. If it knows the identity of the destination node by definition. If it knows the
egress domain it can supply this information as part of the path egress domain, it can supply this information as part of the path
computation request. However, if it does not know the egress domain computation request. However, if it does not know the egress domain,
this information must be known by the child PCE or known/determined this information must be known by the child PCE or known/determined
by the parent PCE. by the parent PCE.
In some specialist topologies the parent PCE could determine the In some specialist topologies the parent PCE could determine the
destination domain based on the destination address, for example from destination domain based on the destination address, for example,
configuration. However, this is not appropriate for many multi-domain from configuration. However, this is not appropriate for many multi-
addressing scenarios. In IP-based multi-domain networks the domain addressing scenarios. In IP-based multi-domain networks, the
parent PCE may be able to determine the destination domain by parent PCE may be able to determine the destination domain by
participating in inter-domain routing. Finally, the parent PCE could participating in inter-domain routing. Finally, the parent PCE could
issue specific requests to the child PCEs to discover if they contain issue specific requests to the child PCEs to discover if they contain
the destination node, but this has scaling implications. the destination node, but this has scaling implications.
For the purposes of this document, the precise mechanism of the For the purposes of this document, the precise mechanism of the
discovery of the destination domain is left out of scope. Suffice to discovery of the destination domain is left out of scope. Suffice to
say that for each multi-domain path computation some mechanism will say that for each multi-domain path computation some mechanism will
be required to determine the location of the destination. be required to determine the location of the destination.
4.6 Hierarchical PCE Examples 4.6. Hierarchical PCE Examples
The following example describes the generic hierarchical domain The following example describes the generic hierarchical domain
topology. Figure 1 demonstrates four interconnected domains within a topology. Figure 1 demonstrates four interconnected domains within a
fifth, parent domain. Each domain contains a single PCE: fifth, parent domain. Each domain contains a single PCE:
o Domain 1 is the ingress domain and child PCE 1 is able to compute o Domain 1 is the ingress domain and child PCE 1 is able to compute
paths within the domain. Its neighbors are Domain 2 and Domain 4. paths within the domain. Its neighbors are Domain 2 and Domain 4.
The domain also contains the source LSR (S) and three egress The domain also contains the source LSR (S) and three egress
boundary nodes (BN11, BN12, and BN13). boundary nodes (BN11, BN12, and BN13).
o Domain 2 is served by child PCE 2. Its neighbors are Domain 1 and o Domain 2 is served by child PCE 2. Its neighbors are Domain 1 and
Domain 3. The domain also contains four boundary nodes (BN21, BN22, Domain 3. The domain also contains four boundary nodes (BN21,
BN23, and BN24). BN22, BN23, and BN24).
o Domain 3 is the egress domain and is served by child PCE 3. Its o Domain 3 is the egress domain and is served by child PCE 3. Its
neighbors are Domain 2 and Domain 4. The domain also contains the neighbors are Domain 2 and Domain 4. The domain also contains the
destination LSR (D) and three ingress boundary nodes (BN31, BN32, destination LSR (D) and three ingress boundary nodes (BN31, BN32,
and BN33). and BN33).
o Domain 4 is served by child PCE 4. Its neighbors are Domain 2 and o Domain 4 is served by child PCE 4. Its neighbors are Domain 2 and
Domain 3. The domain also contains two boundary nodes (BN41 and Domain 3. The domain also contains two boundary nodes (BN41 and
BN42). BN42).
All of these domains are contained within Domain 5 which is served All of these domains are contained within Domain 5, which is served
by the parent PCE (PCE 5). by the parent PCE (PCE 5).
----------------------------------------------------------------- -----------------------------------------------------------------
| Domain 5 | | Domain 5 |
| ----- | | ----- |
| |PCE 5| | | |PCE 5| |
| ----- | | ----- |
| | | |
| ---------------- ---------------- ---------------- | | ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | | | | Domain 1 | | Domain 2 | | Domain 3 | |
skipping to change at page 16, line 37 skipping to change at page 17, line 37
| | ----| |---- ----| |---- | | | | ----| |---- ----| |---- | |
| | | | | | | | | | | | | | | |
| | ---- | | | | ---- | | | | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | | | | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- | | -----------+---- ---------------- ----+----------- |
| \ / | | \ / |
| \ ---------------- / | | \ ---------------- / |
| \ | | / | | \ | | / |
| \ |---- ----| / | | \ |---- ----| / |
| ----+BN41| |BN42+---- | | ----+BN41| |BN42+---- |
| |---- ----| | | |---- ----| |
| | | | | | | |
| | ----- | | | | ----- | |
| | |PCE 4| | | | | |PCE 4| | |
| | ----- | | | | ----- | |
| | | | | | | |
| | Domain 4 | | | | Domain 4 | |
| ---------------- | | ---------------- |
| | | |
----------------------------------------------------------------- -----------------------------------------------------------------
Figure 1 : Sample Hierarchical Domain Topology Figure 1: Sample Hierarchical Domain Topology
Figure 2, shows the view of the domain topology as seen by the parent Figure 2 shows the view of the domain topology as seen by the parent
PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of
domain connectivity, but not of the internal topology within each domain connectivity but not of the internal topology within each
domain. domain.
---------------------------- ----------------------------
| Domain 5 | | Domain 5 |
| ---- | | ---- |
| |PCE5| | | |PCE5| |
| ---- | | ---- |
| | | |
| ---- ---- ---- | | ---- ---- ---- |
| | |---| |---| | | | | |---| |---| | |
| | D1 | | D2 | | D3 | | | | D1 | | D2 | | D3 | |
| | |---| |---| | | | | |---| |---| | |
| ---- ---- ---- | | ---- ---- ---- |
| \ ---- / | | \ ---- / |
| \ | | / | | \ | | / |
| ----| D4 |---- | | ----| D4 |---- |
| | | | | | | |
| ---- | | ---- |
| | | |
---------------------------- ----------------------------
Figure 2 : Abstract Domain Topology as Seen by the Parent PCE Figure 2: Abstract Domain Topology as Seen by the Parent PCE
4.6.1 Hierarchical PCE Initial Information Exchange 4.6.1. Hierarchical PCE Initial Information Exchange
Based on the Figure 1 topology, the following is an illustration of Based on the topology in Figure 1, the following is an illustration
the initial hierarchical PCE information exchange. of the initial hierarchical PCE information exchange.
1. Child PCE 1, the PCE responsible for Domain 1, is configured 1. Child PCE 1, the PCE responsible for Domain 1, is configured with
with the location of its parent PCE (PCE5). the location of its parent PCE (PCE 5).
2. Child PCE 1 establishes contact with its parent PCE. The parent 2. Child PCE 1 establishes contact with its parent PCE. The parent
applies policy to ensure that communication with PCE 1 is allowed. applies policy to ensure that communication with PCE 1 is
allowed.
3. Child PCE 1 listens to the IGP in its domain and learns its 3. Child PCE 1 listens to the IGP in its domain and learns its
inter-domain connectivity. That is, it learns about the links inter-domain connectivity. That is, it learns about the links
BN11-BN21, BN12-BN22, and BN13-BN41. BN11-BN21, BN12-BN22, and BN13-BN41.
4. Child PCE 1 reports its neighbor domain connectivity to its parent 4. Child PCE 1 reports its neighbor domain connectivity to its
PCE. parent PCE.
5. Child PCE 1 reports any change in the resource availability on its 5. Child PCE 1 reports any change in the resource availability on
inter-domain links to its parent PCE. its inter-domain links to its parent PCE.
Each child PCE performs steps 1 through 5 so that the parent PCE can Each child PCE performs steps 1 through 5 so that the parent PCE can
create a domain topology view as shown in Figure 2. create a domain topology view as shown in Figure 2.
4.6.2 Hierarchical PCE End-to-End Path Computation Procedure 4.6.2. Hierarchical PCE End-to-End Path Computation Procedure
The procedure below is an example of a source PCC requesting an The procedure below is an example of a source PCC requesting an end-
end-to-end path in a multi-domain environment. The topology is to-end path in a multi-domain environment. The topology is
represented in Figure 1. It is assumed that the each child PCE has represented in Figure 1. It is assumed that the each child PCE has
connected to its parent PCE and exchanged the initial information connected to its parent PCE and exchanged the initial information
required for the parent PCE to create its domain topology view as required for the parent PCE to create its domain topology view as
described in Section 4.6.1. described in Section 4.6.1.
1. The source PCC (the ingress LSR in our example), sends a request 1. The source PCC (the ingress LSR in our example) sends a request
to the PCE responsible for its domain (PCE 1) for a path to the to the PCE responsible for its domain (PCE 1) for a path to the
destination LSR (D). destination LSR (D).
2. PCE 1 determines the destination is not in domain 1. 2. PCE 1 determines the destination is not in domain 1.
3. PCE 1 sends a computation request to its parent PCE (PCE 5). 3. PCE 1 sends a computation request to its parent PCE (PCE 5).
4. The parent PCE determines that the destination is in Domain 3. 4. The parent PCE determines that the destination is in Domain 3.
(See Section 4.5). (See Section 4.5.)
5. PCE 5 determines the likely domain paths according to the domain 5. PCE 5 determines the likely domain paths according to the domain
interconnectivity and TE capabilities between the domains. For interconnectivity and TE capabilities between the domains. For
example, assuming that the link BN12-BN22 is not suitable for the example, assuming that the link BN12-BN22 is not suitable for the
requested path, three domain paths are determined: requested path, three domain paths are determined:
S-BN11-BN21-D2-BN23-BN31-D S-BN11-BN21-D2-BN23-BN31-D
S-BN11-BN21-D2-BN24-BN32-D S-BN11-BN21-D2-BN24-BN32-D
S-BN13-BN41-D4-BN42-BN33-D S-BN13-BN41-D4-BN42-BN33-D
6. PCE 5 sends edge-to-edge path computation requests to PCE 2 6. PCE 5 sends edge-to-edge path computation requests to PCE 2,
which is responsible for Domain 2 (i.e., BN21-to-BN23 and BN21- which is responsible for Domain 2 (i.e., BN21-to-BN23 and
to-BN24), and to PCE 4 for Domain 4 (i.e., BN41-to-BN42). BN21-to-BN24), and to PCE 4 for Domain 4 (i.e., BN41-to-BN42).
7. PCE 5 sends source-to-edge path computation requests to PCE 1 7. PCE 5 sends source-to-edge path computation requests to PCE 1,
which is responsible for Domain 1 (i.e., S-to-BN11 and S-to- which is responsible for Domain 1 (i.e., S-to-BN11 and
BN13). S-to-BN13).
8. PCE 5 sends edge-to-egress path computation requests to PCE3 8. PCE 5 sends edge-to-egress path computation requests to PCE 3,
which is responsible for Domain 3 (i.e., BN31-to-D, BN32-to-D, which is responsible for Domain 3 (i.e., BN31-to-D, BN32-to-D,
and BN33-to-D). and BN33-to-D).
9. PCE 5 correlates all the computation responses from each child 9. PCE 5 correlates all the computation responses from each child
PCE, adds in the information about the inter-domain links, and PCE, adds in the information about the inter-domain links, and
applies any requested and locally configured policies. applies any requested and locally configured policies.
10. PCE 5 then selects the optimal end-to-end multi-domain path 10. PCE 5 then selects the optimal end-to-end multi-domain path that
that meets the policies and objective functions, and supplies the meets the policies and objective functions, and supplies the
resulting path to PCE 1. resulting path to PCE 1.
11. PCE 1 forwards the path to the PCC (the ingress LSR). 11. PCE 1 forwards the path to the PCC (the ingress LSR).
Note that there is no requirement for steps 6, 7, and 8 to be carried Note that there is no requirement for steps 6, 7, and 8 to be carried
out in parallel or in series. Indeed, they could be overlapped with out in parallel or in series. Indeed, they could be overlapped with
step 5. This is an implementation issue. step 5. This is an implementation issue.
4.7 Hierarchical PCE Error Handling 4.7. Hierarchical PCE Error Handling
In the event that a child PCE in a domain cannot find a suitable In the event that a child PCE in a domain cannot find a suitable path
path to the egress, the child PCE should return the relevant to the egress, the child PCE should return the relevant error to
error to notify the parent PCE. Depending on the error response the notify the parent PCE. Depending on the error response, the parent
parent PCE can elect to: PCE selects one of the following actions:
o Cancel the request and send the relevant response back to the o Cancel the request and send the relevant response back to the
initial child PCE that requested an end-to-end path; initial child PCE that requested an end-to-end path;
o Relax some of the constraints associated with the initial path
request; o Relax some of the constraints associated with the initial path
o Select another candidate domain and send the path request to the request; or
child PCE responsible for the domain.
o Select another candidate domain and send the path request to the
child PCE responsible for the domain.
If the parent PCE does not receive a response from a child PCE within If the parent PCE does not receive a response from a child PCE within
an allotted time period. The parent PCE can elect to: an allotted time period, the parent PCE can elect to:
o Cancel the request and send the relevant response back to the o Cancel the request and send the relevant response back to the
initial child PCE that requested an end-to-end path; initial child PCE that requested an end-to-end path; o Send the path
o Send the path request to another child PCE in the same domain, if a request to another child PCE in the same domain, if a secondary child
secondary child PCE exists; PCE exists; o Select another candidate domain and send the path
o Select another candidate domain and send the path request to the request to the child PCE responsible for that domain.
child PCE responsible for that domain.
The parent PCE may also want to prune any unresponsive child PCE The parent PCE may also want to prune any unresponsive child PCE
domain paths from the candidate set. domain paths from the candidate set.
4.8 Requirements for Hierarchical PCEP Protocol Extensions 4.8. Requirements for Hierarchical PCEP Protocol Extensions
This section lists the high-level requirements for extensions to the This section lists the high-level requirements for extensions to the
PCEP to support the hierarchical PCE model. It is provided to offer PCEP to support the hierarchical PCE model. It is provided to offer
guidance to PCEP protocol developers in designing a solution suitable guidance to PCEP protocol developers in designing a solution suitable
for use in a hierarchical PCE framework. for use in a hierarchical PCE framework.
4.8.1 PCEP Request Qualifiers 4.8.1. PCEP Request Qualifiers
PCEP request (PCReq) messages are used by a PCC or a PCE to make a Path Computation Request (PCReq) messages are used by a PCC or a PCE
computation request or enquiry to a PCE. The requests are qualified to make a computation request or enquiry to a PCE. The requests are
so that the PCE knows what type of action is required. qualified so that the PCE knows what type of action is required.
Support of the hierarchical PCE architecture will introduce two new Support of the hierarchical PCE architecture will introduce two new
qualifications as follows: qualifications as follows:
o It must be possible for a child PCE to indicate that the response o It must be possible for a child PCE to indicate that the response
it receives from the parent PCE should consist of a domain sequence it receives from the parent PCE should consist of a domain
only (i.e., not a fully-specified end-to-end path). This allows the sequence only (i.e., not a fully specified end-to-end path). This
child PCE to initiate per-domain or backward recursive path allows the child PCE to initiate Per-Domain or BRPC.
computation.
o A parent PCE may need to be able to ask a child PCE whether a o A parent PCE may need to be able to ask a child PCE whether a
particular node address (the destination of an end-to-end path) is particular node address (the destination of an end-to-end path) is
present in the domain that the child PCE serves. present in the domain that the child PCE serves.
In PCEP, such request qualifications are carried as bit-flags in the In PCEP, such request qualifications are carried as bit flags in the
RP object within the PCReq message. RP object (Request Parameter object) within the PCReq message.
4.8.2 Indication of Hierarchical PCE Capability 4.8.2. Indication of Hierarchical PCE Capability
Although parent/child PCE relationships are likely configured, it Although parent/child PCE relationships are likely configured, it
will assist network operations if the parent PCE is able to indicate will assist network operations if the parent PCE is able to indicate
to the child that it really is capable of acting as a parent PCE. to the child that it really is capable of acting as a parent PCE.
This will help to trap misconfigurations. This will help to trap misconfigurations.
In PCEP, such capabilities are carried in the Open Object within the In PCEP, such capabilities are carried in the Open Object within the
Open message. Open message.
4.8.3 Intention to Utilize Parent PCE Capabilities 4.8.3. Intention to Utilize Parent PCE Capabilities
A PCE that is capable of acting as a parent PCE might not be A PCE that is capable of acting as a parent PCE might not be
configured or willing to act as the parent for a specific child PCE. configured or willing to act as the parent for a specific child PCE.
This fact could be determined when the child sends a PCReq that This fact could be determined when the child sends a PCReq that
requires parental activity (such as querying other child PCEs), and requires parental activity (such as querying other child PCEs), and
could result in a negative response in a PCEP Error (PCErr) message. could result in a negative response in a PCEP Error (PCErr) message.
However, the expense of a poorly targeted PCReq can be avoided if However, the expense of a poorly targeted PCReq can be avoided if the
the child PCE indicates that it might wish to use the parent-capable child PCE indicates that it might wish to use the parent-capable PCE
as a parent (for example, on the Open message), and if the as a parent (for example, on the Open message), and if the parent-
parent-capable determines at that time whether it is willing to act capable PCE determines at that time whether it is willing to act as a
as a parent to this child. parent to this child.
4.8.4 Communication of Domain Connectivity Information 4.8.4. Communication of Domain Connectivity Information
Section 4.4 describes how the parent PCE needs a parent TED and Section 4.4 describes how the parent PCE needs a parent TED and
indicates that the information might be supplied from the child PCEs indicates that the information might be supplied from the child PCEs
in each domain. This requires a mechanism whereby information about in each domain. This requires a mechanism whereby information about
inter-domain links can be supplied by a child PCE to a parent PCE, inter-domain links can be supplied by a child PCE to a parent PCE,
for example on a PCEP Notify (PCNtf) message. for example, on a PCEP Notify (PCNtf) message.
The information that would be exchanged includes: The information that would be exchanged includes:
o Identifier of advertising child PCE o Identifier of advertising child PCE
o Identifier of PCE's domain o Identifier of PCE's domain
o Identifier of the link o Identifier of the link
o TE properties of the link (metrics, bandwidth) o TE properties of the link (metrics, bandwidth)
o Other properties of the link (technology-specific) o Other properties of the link (technology-specific)
o Identifier of link end-points o Identifier of link endpoints
o Identifier of adjacent domain o Identifier of adjacent domain
It may be desirable for this information to be periodically updated, It may be desirable for this information to be periodically updated,
for example, when available bandwidth changes. In this case, the for example, when available bandwidth changes. In this case, the
parent PCE might be given the ability to configure thresholds in the parent PCE might be given the ability to configure thresholds in the
child PCE to prevent flapping of information. child PCE to prevent flapping of information.
4.8.5 Domain Identifiers 4.8.5. Domain Identifiers
Domain identifiers are already present in PCEP to allow a PCE to Domain identifiers are already present in PCEP to allow a PCE to
indicate which domains it serves, and to allow the representation of indicate which domains it serves, and to allow the representation of
domains as abstract nodes in paths. The wider use of domains in the domains as abstract nodes in paths. The wider use of domains in the
context of this work on hierarchical PCE will require that domains context of this work on hierarchical PCE will require that domains
can be identified in more places within objects in PCEP messages. can be identified in more places within objects in PCEP messages.
This should pose no problems. This should pose no problems.
However, more attention may need to be applied to the precision of However, more attention may need to be applied to the precision of
domain identifier definitions to ensure that it is always possible to domain identifier definitions to ensure that it is always possible to
unambiguously identify a domain from its identifier. This work will unambiguously identify a domain from its identifier. This work will
be necessary in configuration, and also in protocol specifications be necessary in configuration, and also in protocol specifications
(for example, an OSPF area identifier is sufficient within an (for example, an OSPF area identifier is sufficient within an
Autonomous System, but becomes ambiguous in a path that crosses Autonomous System, but becomes ambiguous in a path that crosses
multiple Autonomous Systems). multiple Autonomous Systems).
5. Hierarchical PCE Applicability 5. Hierarchical PCE Applicability
As per [RFC4655], PCE can inherently support inter-domain path As per [RFC4655], PCE can inherently support inter-domain path
computation for any definition of a domain as set out in Section 1.2 computation for any definition of a domain as set out in Section 1.2
of this document. of this document.
Hierarchical PCE can be applied to inter-domain environments, Hierarchical PCE can be applied to inter-domain environments,
including autonomous Systems and IGP areas. The hierarchical PCE including autonomous Systems and IGP areas. The hierarchical PCE
procedures make no distinction between, autonomous Systems and IGP procedures make no distinction between, autonomous Systems and IGP
area applications, although it should be noted that the TED area applications, although it should be noted that the TED
maintained by a parent PCE must be able to support the concept of maintained by a parent PCE must be able to support the concept of
child domains connected by inter-domain links or directly connected child domains connected by inter-domain links or directly connected
at boundary nodes (see Section 3). at boundary nodes (see Section 3).
This section sets out the applicability of hierarchical PCE to three This section sets out the applicability of hierarchical PCE to three
environments: environments:
o MPLS traffic engineering across multiple Autonomous Systems o MPLS traffic engineering across multiple Autonomous Systems
o MPLS traffic engineering across multiple IGP areas o MPLS traffic engineering across multiple IGP areas
o GMPLS traffic engineering in the ASON architecture o GMPLS traffic engineering in the ASON architecture
5.1 autonomous Systems and Areas 5.1. Autonomous Systems and Areas
Networks are comprised of domains. A domain can be considered to be Networks are comprised of domains. A domain can be considered to be
a collection of network elements within an AS or area that has a a collection of network elements within an AS or area that has a
common sphere of address management or path computational common sphere of address management or path computational
responsibility. responsibility.
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
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 a router's information to within area boundaries. This restricts a router's
visibility to information about links and other routers within the visibility to information about links and other routers within the
single area. If a router needs to compute a route to destination single area. If a router needs to compute a route to destination
located in another area, a method is required to compute a path located in another area, a method is required to compute a path
across the area boundary. across the area boundary.
When an LSR within an AS or area needs to compute a path across an When an LSR within an AS or area needs to compute a path across an
area or AS boundary it must also use an inter-AS computation area or AS boundary, it must also use an inter-AS computation
technique. Hierarchical PCE is equally applicable to computing technique. Hierarchical PCE is equally applicable to computing
inter-area and inter-AS MPLS and GMPLS paths across domain inter-area and inter-AS MPLS and GMPLS paths across domain
boundaries. boundaries.
5.2 ASON Architecture 5.2. ASON Architecture
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.
Note that the RA hierarchy can be recursive. Note that the RA hierarchy can be recursive.
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 termed a Switched Connection (SC) or a Soft Permanent
Connection (SPC). [G-7715-2] defines the requirements and 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 (RCs)
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. For an end-to-end connection, the route may be computed with a PCE. For an end-to-end connection, the route may be computed
by a single RC or multiple RCs in a collaborative manner (i.e., RC by a single RC or multiple RCs in a collaborative manner (i.e., RC
federations). In the case of RC federations, [G-7715-2] describes federations). In the case of RC federations, [G-7715-2] describes
three styles during remote route query operation: three styles during remote route query operation:
o Step-by-step remote path computation o step-by-step remote path computation
o Hierarchical remote path computation o hierarchical remote path computation
o A combination of the above. o a combination of the above.
In a hierarchical ASON routing environment, a child RC may In a hierarchical ASON routing environment, a child RC may
communicate with its parent RC (at the next higher level of the ASON communicate with its parent RC (at the next higher level of the ASON
routing hierarchy) to request the computation of an end-to-end path routing hierarchy) to request the computation of an end-to-end path
across several RAs. It does this using a route query message (known across several RAs. It does this using a route query message (known
as the abstract message RI_QUERY). The corresponding parent RC may as the abstract message RI_QUERY). The corresponding parent RC may
communicate with other child RCs that belong to other child RAs at communicate with other child RCs that belong to other child RAs at
the next lower hierarchical level. Thus, a parent RC can act as the next lower hierarchical level. Thus, a parent RC can act as
either a Route Query Requester or Route Query Responder. either a Route Query Requester or Route Query Responder.
It can be seen that the hierarchical PCE architecture fits the It can be seen that the hierarchical PCE architecture fits the
hierarchical ASON routing architecture well. It can be used to hierarchical ASON routing architecture well. It can be used to
provide paths across subnetworks, and to determine end-to-end paths provide paths across subnetworks and to determine end-to-end paths in
in networks constructed from multiple subnetworks or RAs. networks constructed from multiple subnetworks or RAs.
When hierarchical PCE is applied to implement hierarchical remote When hierarchical PCE is applied to implement hierarchical remote
path computation in [G-7715-2], it is very important for operators to path computation in [G-7715-2], it is very important for operators to
understand the different terminology and implicit consistency understand the different terminology and implicit consistency between
between hierarchical PCE and [G-7715-2]. hierarchical PCE and [G-7715-2].
5.2.1 Implicit Consistency Between Hierarchical PCE and G.7715.2 5.2.1. Implicit Consistency between Hierarchical PCE and G.7715.2
This section highlights the correspondence between features of the This section highlights the correspondence between features of the
hierarchical PCE architecture and the ASON routing architecture. hierarchical PCE architecture and the ASON routing architecture.
(1) RC (Routing Controller) and PCE (Path Computation Element) (1) RC (Routing Controller) and PCE (Path Computation Element)
[G-8080] describes the Routing Controller component as an [G-8080] describes the Routing Controller component as an
abstract entity, which is responsible for responding to requests abstract entity, which is responsible for responding to requests
for path (route) information and topology information. It can be for path (route) information and topology information. It can be
implemented as a single entity, or as a distributed set of implemented as a single entity, or as a distributed set of
entities that make up a cooperative federation. entities that make up a cooperative federation.
[RFC4655] describes PCE (Path Computation Element) is an entity [RFC4655] describes PCE (Path Computation Element) is an entity
(component, application, or network node) that is capable of (component, application, or network node) that is capable of
computing a network path or route based on a network graph and computing a network path or route based on a network graph and
applying computational constraints. applying computational constraints.
Therefore, in the ASON architecture, a PCE can be regarded as a Therefore, in the ASON architecture, a PCE can be regarded as a
realizations of the RC. realization of the RC.
(2) Route Query Requester/Route Query Responder and PCC/PCE (2) Route Query Requester/Route Query Responder and PCC/PCE
[G-7715-2] describes the Route Query Requester as a Connection [G-7715-2] describes the Route Query Requester as a Connection
Controller or Routing Controller that sends a route query message Controller or Routing Controller that sends a route query message
to a Routing Controller requesting one or more paths that to a Routing Controller requesting one or more paths that satisfy
satisfy a set of routing constraints. The Route Query Responder a set of routing constraints. The Route Query Responder is a
is a Routing Controller that performs path computation upon Routing Controller that performs path computation upon receipt of
receipt of a route query message from a Route Query Requester, a route query message from a Route Query Requester, sending a
sending a response back at the end of the path computation. response back at the end of the path computation.
In the context of ASON, a Signaling Controller initiates and In the context of ASON, a Signaling Controller initiates and
processes signaling messages and is closely coupled to a processes signaling messages and is closely coupled to a
Signaling Protocol Speaker. A Routing Controller makes routing Signaling Protocol Speaker. A Routing Controller makes routing
decisions and is usually coupled to configuration entities decisions and is usually coupled to configuration entities and/or
and/or a Routing Protocol Speaker. a Routing Protocol Speaker.
It can be seen that a PCC corresponds to a Route Query Requester, It can be seen that a PCC corresponds to a Route Query Requester,
and a PCE corresponds to a Route Query Responder. A PCE/RC can and a PCE corresponds to a Route Query Responder. A PCE/RC can
also act as a Route Query Requester sending requests to another also act as a Route Query Requester sending requests to another
Route Query Responder. Route Query Responder.
The PCEP path computation request (PCReq) and path computation The Path Computation Request (PCReq) and Path Computation Reply
reply (PCRep) messages between PCC and PCE correspond to the (PCRep) messages between PCC and PCE correspond to the RI_QUERY
RI_QUERY and RI_UPDATE messages in [G-7715-2]. and RI_UPDATE messages in [G-7715-2].
(3) Routing Area Hierarchy and Hierarchical Domain (3) Routing Area Hierarchy and Hierarchical Domain
The ASON routing hierarchy model is shown in Figure 6 of The ASON routing hierarchy model is shown in Figure 6 of [G-7715]
[G-7715] through an example that illustrates routing area levels. through an example that illustrates routing area levels. If the
If the hierarchical remote path computation mechanism of hierarchical remote path computation mechanism of [G-7715-2] is
[G-7715-2] is applied in this scenario, each routing area should applied in this scenario, each routing area should have at least
have at least one RC for route query function and there is a one RC to perform the route query function, and the child RCs
parent RC for the child RCs in each routing area. within the area should have a parent RC.
According to [G-8080], the parent RC has visibility of the According to [G-8080], the parent RC has visibility of the
structure of the lower level, so it knows the interconnectivity structure of the lower level, so it knows the interconnectivity
of the RAs in the lower level. Each child RC can compute edge-to- of the RAs in the lower level. Each child RC can compute edge-
edge paths across its own child RA. to-edge paths across its own child RA.
Thus, an RA corresponds to a domain in the PCE architecture, and Thus, an RA corresponds to a domain in the PCE architecture, and
the hierarchical relationship between RAs corresponds to the the hierarchical relationship between RAs corresponds to the
hierarchical relationship between domains in the hierarchical PCE hierarchical relationship between domains in the hierarchical PCE
architecture. Furthermore, a parent PCE in a parent domain can be architecture. Furthermore, a parent PCE in a parent domain can
regarded as parent RC in a higher routing level, and a child PCE be regarded as parent RC in a higher routing level, and a child
in a child domain can be regarded as child RC in a lower routing PCE in a child domain can be regarded as child RC in a lower
level. routing level.
5.2.2 Benefits of Hierarchical PCEs in ASON 5.2.2. Benefits of Hierarchical PCEs in ASON
RCs in an ASON environment can use the hierarchical PCE model to RCs in an ASON environment can use the hierarchical PCE model to
fully match the ASON hierarchical routing model, so the hierarchical fully match the ASON hierarchical routing model, so the hierarchical
PCE mechanisms can be applied to fully satisfy the architecture and PCE mechanisms can be applied to fully satisfy the architecture and
requirements of [G-7715-2] without any changes. If the hierarchical requirements of [G-7715-2] without any changes. If the hierarchical
PCE mechanism is applied in ASON, it can be used to determine end-to- PCE mechanism is applied in ASON, it can be used to determine end-to-
end optimized paths across sub-networks and RAs before initiating end optimized paths across subnetworks and RAs before initiating
signaling to create the connection. It can also improve the signaling to create the connection. It can also improve the
efficiency of connection setup to avoid crankback. efficiency of connection setup to avoid crankback.
6. A Note on BGP-TE 6. A Note on BGP-TE
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-TE]. The information exchanged in this (ASes) is discussed in [BGP-TE]. 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 There are a number of discussion points associated with the use of
[BGP-TE] concerning the volume of information, the rate of churn of [BGP-TE] concerning the volume of information, the rate of churn of
information, the confidentiality of information, the accuracy of information, the confidentiality of information, the accuracy of
aggregated or potential-connectivity information, and the processing aggregated or potential-connectivity information, and the processing
required to generate aggregated information. The PCE architecture and required to generate aggregated information. The PCE architecture
the architecture enabled by [BGP-TE] make different assumptions about and the architecture enabled by [BGP-TE] make different assumptions
the operational objectives of the networks, and this document does about the operational objectives of the networks, and this document
not attempt to make one of the approaches "right" and the other 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 "wrong". Instead, this work assumes that a decision has been made to
utilize the PCE architecture. utilize the PCE architecture.
6.1 Use of BGP for TED Synchronization 6.1. Use of BGP for TED Synchronization
Indeed, [BGP-TE] may have some uses within the PCE model. For Indeed, [BGP-TE] may have some uses within the PCE model. For
example, [BGP-TE] could be used as a "northbound" TE advertisement example, [BGP-TE] could be used as a "northbound" TE advertisement
such that a PCE does not need to listen to an IGP in its domain, but 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 has its TED populated by messages received (for example) from a Route
Route Reflector. Furthermore, the inter-domain connectivity and Reflector. Furthermore, the inter-domain connectivity and
connectivity capabilities that is required information for a parent capabilities that are required information for a parent PCE could be
PCE could be obtained as a filtered subset of the information obtained as a filtered subset of the information available in
available in [BGP-TE]. This scenario is discussed further in [BGP-TE]. This scenario is discussed further in [PCE-AREA-AS].
[PCE-AREA-AS].
7. Management Considerations 7. Management Considerations
General PCE management considerations are discussed in [RFC4655]. In General PCE management considerations are discussed in [RFC4655]. In
the case of the hierarchical PCE architecture, there are additional the case of the hierarchical PCE architecture, there are additional
management considerations. management considerations.
The administrative entity responsible for the management of the The administrative entity responsible for the management of the
parent PCEs must be determined. In the case of multi-domains (e.g., parent PCEs must be determined. In the case of multi-domains (e.g.,
IGP areas or multiple ASes) within a single service provider IGP areas or multiple ASes) within a single service provider network,
network, the management responsibility for the parent PCE would most the management responsibility for the parent PCE would most likely be
likely be handled by the service provider. In the case of multiple handled by the service provider. In the case of multiple ASes within
ASes within different service provider networks, it may be necessary different service provider networks, it may be necessary for a third
for a third-party to manage the parent PCEs according to commercial party to manage the parent PCEs according to commercial and policy
and policy agreements from each of the participating service agreements from each of the participating service providers.
providers.
7.1 Control of Function and Policy 7.1. Control of Function and Policy
7.1.1 Child PCE 7.1.1. Child PCE
Support of the hierarchical procedure will be controlled by the Support of the hierarchical procedure will be controlled by the
management organization responsible for each child PCE. A child PCE management organization responsible for each child PCE. A child PCE
must be configured with the address of its parent PCE in order for must be configured with the address of its parent PCE in order for it
it to interact with its parent PCE. The child PCE must also be to interact with its parent PCE. The child PCE must also be
authorized to peer with the parent PCE. authorized to peer with the parent PCE.
7.1.2 Parent PCE 7.1.2. Parent PCE
The parent PCE must only accept path computation requests from The parent PCE must only accept path computation requests from
authorized child PCEs. If a parent PCE receives requests from an authorized child PCEs. If a parent PCE receives requests from an
unauthorized child PCE, the request should be dropped. unauthorized child PCE, the request should be dropped.
This means that a parent PCE must be configured with the identities This means that a parent PCE must be configured with the identities
and security credentials of all of its child PCEs, or there must be and security credentials of all of its child PCEs, or there must be
some form of shared secret that allows an unknown child PCE to be some form of shared secret that allows an unknown child PCE to be
authorized by the parent PCE. authorized by the parent PCE.
7.1.3 Policy Control 7.1.3. Policy Control
It may be necessary to maintain a policy module on the parent PCE It may be necessary to maintain a policy module on the parent PCE
[RFC5394]. This would allow the parent PCE to apply commercially [RFC5394]. This would allow the parent PCE to apply commercially
relevant constraints such as SLAs, security, peering preferences, and relevant constraints such as SLAs, security, peering preferences, and
monetary costs. monetary costs.
It may also be necessary for the parent PCE to limit end-to-end path It may also be necessary for the parent PCE to limit end-to-end path
selection by including or excluding specific domains based on selection by including or excluding specific domains based on
commercial relationships, security implications, and reliability. commercial relationships, security implications, and reliability.
7.2 Information and Data Models 7.2. Information and Data Models
A PCEP MIB module is defined in [PCEP-MIB] that describes managed A PCEP MIB module is defined in [PCEP-MIB] that describes managed
objects for modeling of PCEP communication. An additional PCEP MIB objects for modeling of PCEP communication. An additional PCEP MIB
will be required to report parent PCE and child PCE information, will be required to report parent PCE and child PCE information,
including: including:
o Parent PCE configuration and status, o parent PCE configuration and status,
o Child PCE configuration and information, o child PCE configuration and information,
o Notifications to indicate session changes between parent PCEs and o notifications to indicate session changes between parent PCEs and
child PCEs. child PCEs, and
o Notification of parent PCE TED updates and changes. o notification of parent PCE TED updates and changes.
7.3 Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
The hierarchical procedure requires interaction with multiple PCEs. The hierarchical procedure requires interaction with multiple PCEs.
Once a child PCE requests an end-to-end path, a sequence of events Once a child PCE requests an end-to-end path, a sequence of events
occurs that requires interaction between the parent PCE and each occurs that requires interaction between the parent PCE and each
child PCE. If a child PCE is not operational, and an alternate child PCE. If a child PCE is not operational, and an alternate
transit domain is not available, then a failure must be reported. transit domain is not available, then a failure must be reported.
7.4 Verifying Correct Operation 7.4. Verifying Correct Operation
Verifying the correct operation of a parent PCE can be performed by Verifying the correct operation of a parent PCE can be performed by
monitoring a set of parameters. The parent PCE implementation should monitoring a set of parameters. The parent PCE implementation should
provide the following parameters monitored by the parent PCE: provide the following parameters monitored by the parent PCE:
o Number of child PCE requests. o number of child PCE requests,
o Number of successful hierarchical PCE procedures completions on a o number of successful hierarchical PCE procedures completions on a
per-PCE-peer basis. per-PCE-peer basis,
o Number of hierarchical PCE procedure completion failures on a per- o number of hierarchical PCE procedure completion failures on a per-
PCE-peer basis. PCE-peer basis, and
o Number of hierarchical PCE procedure requests from unauthorized o number of hierarchical PCE procedure requests from unauthorized
child PCEs. child PCEs.
7.5. Impact on Network Operation 7.5. Impact on Network Operation
The hierarchical PCE procedure is a multiple-PCE path computation The hierarchical PCE procedure is a multiple-PCE path computation
scheme. Subsequent requests to and from the child and parent PCEs do scheme. Subsequent requests to and from the child and parent PCEs do
not differ from other path computation requests and should not have not differ from other path computation requests and should not have
any significant impact on network operations. any significant impact on network operations.
8. Security Considerations 8. Security Considerations
The hierarchical PCE procedure relies on PCEP and inherits the The hierarchical PCE procedure relies on PCEP and inherits the
security requirements defined [RFC5440]. As noted in Section 7, security requirements defined in [RFC5440]. As noted in Section 7,
there is a security relationship between child and parent PCEs. there is a security relationship between child and parent PCEs. This
This relationship, like any PCEP relationship assumes relationship, like any PCEP relationship, assumes pre-configuration
pre-configuration of identities, authority, and keys, or can of identities, authority, and keys, or can operate through any key
operate through any key distribution mechanism outside the scope of distribution mechanism outside the scope of PCEP. As PCEP operates
PCEP. As PCEP operates over TCP, it may make use of any TCP security over TCP, it may make use of any TCP security mechanism.
mechanism.
The hierarchical PCE architecture makes use of PCE policy The hierarchical PCE architecture makes use of PCE policy [RFC5394]
[RFC5394] and the security aspects of the PCE communication protocol and the security aspects of the PCE Communication Protocol documented
documented in [RFC5440]. It is expected that the parent PCE will in [RFC5440]. It is expected that the parent PCE will require all
require all child PCEs to use full security when communicating with child PCEs to use full security when communicating with the parent
the parent and that security will be maintained by not supporting the and that security will be maintained by not supporting the discovery
discovery by a parent of child PCEs. by a parent of child PCEs.
PCE operation also relies on information used to build the TED. PCE operation also relies on information used to build the TED.
Attacks on a PCE system may be achieved by falsifying or impeding Attacks on a PCE system may be achieved by falsifying or impeding
this flow of information. The child PCE TEDs are constructed as this flow of information. The child PCE TEDs are constructed as
described in [RFC4655] and are unchanged in this document: if the PCE described in [RFC4655] and are unchanged in this document: if the PCE
listens to the IGP for this information, then normal IGP security listens to the IGP for this information, then normal IGP security
measures may be applied, and it should be noted that an IGP routing measures may be applied, and it should be noted that an IGP routing
system is generally assumed to be a trusted domain such that router system is generally assumed to be a trusted domain such that router
subversion is not a risk. The parent PCE TED is constructed as subversion is not a risk. The parent PCE TED is constructed as
described in this document and may involve: described in this document and may involve:
- multiple parent-child relationships using PCEP (as already - multiple parent-child relationships using PCEP (as already
described) described)
- the parent PCE listening to child domain IGPs (with the same - the parent PCE listening to child domain IGPs (with the same
security features as a child PCE listening to its IGP) security features as a child PCE listening to its IGP)
- an external mechanism (such as [BGP-TE]) which will need to be - an external mechanism (such as [BGP-TE]), which will need to be
authorized and secured. authorized and secured.
Any multi-domain operation necessarily involves the exchange of Any multi-domain operation necessarily involves the exchange of
information across domain boundaries. This is bound to represent a information across domain boundaries. This is bound to represent a
significant security and confidentiality risk especially when the significant security and confidentiality risk especially when the
child domains are controlled by different commercial concerns. PCEP child domains are controlled by different commercial concerns. PCEP
allows individual PCEs to maintain confidentiality of their domain allows individual PCEs to maintain confidentiality of their domain
path information using Path Keys [RFC5520], and the hierarchical path information using path-keys [RFC5520], and the hierarchical PCE
PCE architecture is specifically designed to enable as much isolation architecture is specifically designed to enable as much isolation of
of domain topology and capabilities information as is possible. domain topology and capabilities information as is possible.
Further considerations of the security issues related to inter-AS
path computation see [RFC5376].
9. IANA Considerations
This document makes no requests for IANA action. For further considerations of the security issues related to inter-AS
path computation, see [RFC5376].
10. Acknowledgements 9. Acknowledgements
The authors would like to thank David Amzallag, Oscar Gonzalez de The authors would like to thank David Amzallag, Oscar Gonzalez de
Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini, Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini,
Dhruv Dhody and Julien Meuric for their comments and suggestions. Dhruv Dhody, and Julien Meuric for their comments and suggestions.
11. References
11.1 Normative References 10. References
[RFC4655] Farrel, A., Vasseur, J., Ash, J., "A Path Computation 10.1. Normative References
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Path Computation Method for Establishing Inter-Domain Computation Element (PCE)-Based Architecture", RFC
Traffic Engineering (TE) Label Switched Paths (LSPs)", 4655, August 2006.
RFC 5152, February 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
"Policy-Enabled Path Computation Framework", RFC 5394, Per-Domain Path Computation Method for Establishing
December 2008. Inter-Domain Traffic Engineering (TE) Label Switched
Paths (LSPs)", RFC 5152, February 2008.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Policy-Enabled Path Computation Framework", RFC 5394,
"Path Computation Element (PCE) Communication Protocol December 2008.
(PCEP)", RFC 5440, March 2009.
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation (BRPC) procedure to compute shortest inter- Computation Element (PCE) Communication Protocol
domain Traffic Engineering Label Switched Paths", RFC (PCEP)", RFC 5440, March 2009.
5441, April 2009.
[RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le
Topology Confidentiality in Inter-Domain Path Roux, "A Backward-Recursive PCE-Based Computation
Computation Using a Key-Based Mechanism (BRPC) Procedure to Compute Shortest Constrained Inter-
RFC5520, April 2009. Domain Traffic Engineering Label Switched Paths", RFC
5441, April 2009.
11.2. Informative References [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism", RFC
5520, April 2009.
[RFC4105] Le Roux, JL., Vasseur, J., Boyle, J., 10.2. Informative References
"Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005.
[RFC4216] Zhang, R., and Vasseur, J., "MPLS Inter-Autonomous [RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
System (AS) Traffic Engineering (TE) Requirements", RFC Ed., "Requirements for Inter-Area MPLS Traffic
4216, November 2005. Engineering", RFC 4105, June 2005.
[RFC4726] Farrel, A., Vasseur, J., Ayyangar, A., "A Framework [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
for Inter-Domain Multiprotocol Label Switching Traffic Autonomous System (AS) Traffic Engineering (TE)
Engineering", RFC 4726, November 2006. Requirements", RFC 4216, November 2005.
[RFC5152] Vasseur, JP., Ayyangar, A., Zhang, R., "A Per-Domain [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Path Computation Method for Establishing Inter-Domain Framework for Inter-Domain Multiprotocol Label
Traffic Engineering (TE) Label Switched Paths (LSPs)", Switching Traffic Engineering", RFC 4726, November
RFC 5152, February 2008. 2006.
[RFC5316] Chen, M., Zhang, R., Duan, X., "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008. Traffic Engineering", RFC 5316, December 2008.
[RFC5376] Bitar, N., et al., "Inter-AS Requirements for the [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Path Computation Element Communication Protocol Requirements for the Path Computation Element
(PCECP)", RFC 5376, November 2008. Communication Protocol (PCECP)", RFC 5376, November
2008.
[RFC5392] Chen, M., Zhang, R., Duan, X., "OSPF Extensions in [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009. Traffic Engineering", RFC 5392, January 2009.
[RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
of Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC5541, December 2008. Communication Protocol (PCEP)", RFC 5541, June 2009.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON). the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture [G-7715] ITU-T Recommendation G.7715 (2002), Architecture and
and Requirements for the Automatically Requirements for the Automatically Switched Optical
Switched Optical Network (ASON). Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing
routing architecture and requirements for remote route architecture and requirements for remote route query.
query.
[BGP-TE] Gredler, H., Medved, J, Farrel, A. Previdi, S., [BGP-TE] Gredler, H., Medved, J., Previdi, S., Farrel, A., and
"North-Bound Distribution of Link-State and TE S. Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-gredler-idr-ls-distribution, Information using BGP", Work in Progress, October 2012.
work in progress.
[PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de [PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de
Dios, O., "Applicability of the Path Computation Element Dios, O., and F. Chico, "Applicability of the Path
to Inter-Area and Inter-AS MPLS and GMPLS Traffic Computation Element to Inter-Area and Inter-AS MPLS and
Engineering", draft-ietf-pce-inter-area-as-applicability, GMPLS Traffic Engineering", Work in Progress, January
work in progress. 2012.
[PCEP-MIB] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE
Communication Protocol (PCEP) Management Information
Base", work in progress.
12. Authors' Addresses
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Adrian Farrel [PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D., and J.
Old Dog Consulting Hardwick, "PCE communication protocol (PCEP) Management
UK Information Base", Work in Progress, July 2012.
Email: adrian@olddog.co.uk 11. Contributors
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
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
P.R. China
Email: zhangfatai@huawei.com EMail: zhangfatai@huawei.com
Authors' Addresses
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Adrian Farrel
Old Dog Consulting
UK
EMail: adrian@olddog.co.uk
 End of changes. 299 change blocks. 
762 lines changed or deleted 750 lines changed or added

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