draft-ietf-pce-hierarchy-fwk-02.txt   draft-ietf-pce-hierarchy-fwk-03.txt 
Network Working Group D. King (Ed.) Network Working Group D. King (Ed.)
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended Status: Informational A. Farrel (Ed.) Intended Status: Informational A. Farrel (Ed.)
Expires: 10 October 2012 Old Dog Consulting Expires: 27 November 2012 Old Dog Consulting
10 May 2012 27 June 2012
The Application of the Path Computation Element Architecture to the The Application of the Path Computation Element Architecture to the
Determination of a Sequence of Domains in MPLS and GMPLS Determination of a Sequence of Domains in MPLS and GMPLS
draft-ietf-pce-hierarchy-fwk-02.txt draft-ietf-pce-hierarchy-fwk-03.txt
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.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 10 October 2012. This Internet-Draft will expire on 27 November 2012.
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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1 Problem Statement.........................................4 1.1 Problem Statement.........................................4
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..............................5
1.3.1 Metric Objectives...................................6 1.3.1 Metric Objectives...................................6
1.3.2 Domain Diversity....................................7 1.3.2 Diversity...........................................6
1.3.2.1 Physical Diversity..........................6
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..............................7
1.3.5 Domain Confidentiality..............................7 1.3.5 Domain Confidentiality..............................7
1.3.6 Limiting Information Aggregation....................7 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 Path Computation.......................10
2.2.1 Applicability of BRPC when the Domain Path is not 2.2.1 Applicability of BRPC when the Domain Path is not
Known.................................................10 Known.................................................10
3. Hierarchical PCE..............................................11 3. Hierarchical PCE..............................................11
4. Hierarchical PCE Procedures...................................12 4. Hierarchical PCE Procedures...................................12
4.1 Objective Functions and Policy............................12 4.1 Objective Functions and Policy............................12
4.2 Maintaining Domain Confidentiality........................13 4.2 Maintaining Domain Confidentiality........................13
4.3 PCE Discovery.............................................13 4.3 PCE Discovery.............................................13
4.4 Parent Domain Traffic Engineering Database................14 4.4 Parent Domain Traffic Engineering Database................14
4.5 Determination of Destination Domain ......................14 4.5 Determination of Destination Domain ......................15
4.6 Hierarchical PCE Examples.................................15 4.6 Hierarchical PCE Examples.................................15
4.6.1 Hierarchical PCE Initial Information Exchange.......17 4.6.1 Hierarchical PCE Initial Information Exchange.......17
4.6.2 Hierarchical PCE End-to-End Path Computation 4.6.2 Hierarchical PCE End-to-End Path Computation
Procedure Example.........................................17 Procedure Example.........................................17
4.7 Hierarchical PCE Error Handling...........................19 4.7 Hierarchical PCE Error Handling...........................19
4.8 Hierarchical PCEP Protocol Extensions.....................19 4.8 Hierarchical PCEP Protocol Extensions.....................19
4.8.1 PCEP Request Qualifiers.............................19 4.8.1 PCEP Request Qualifiers.............................19
4.8.2 Indication of H-PCE Capability......................20 4.8.2 Indication of H-PCE Capability......................20
4.8.3 Intention to Utilize Parent PCE Capabilities........20 4.8.3 Intention to Utilize Parent PCE Capabilities........20
4.8.4 Communication of Domain Connectivity Information....20 4.8.4 Communication of Domain Connectivity Information....20
4.8.5 Domain Identifiers..................................21 4.8.5 Domain Identifiers..................................21
5. Hierarchical PCE Applicability................................21 5. Hierarchical PCE Applicability................................21
5.1 Antonymous Systems and Areas..............................21 5.1 Antonymous Systems and Areas..............................21
5.2 ASON architecture (G-7715-2)..............................22 5.2 ASON architecture (G-7715-2)..............................22
5.2.1 Implicit Consistency Between Hierarchical PCE and 5.2.1 Implicit Consistency Between Hierarchical PCE and
G.7715.2..................................................23 G.7715.2..................................................23
5.2.2 Benefits of Hierarchical PCEs in ASON...............24 5.2.2 Benefits of Hierarchical PCEs in ASON...............24
6. A Note on BGP-TE..............................................24 6. A Note on BGP-TE..............................................24
7. Management Considerations ....................................26 6.1 Use of BGP for TED Synchronization........................25
7.1 Control of Function and Policy............................26 7. Management Considerations ....................................25
7.1.1 Child PCE...........................................26 7.1 Control of Function and Policy............................25
7.1.1 Child PCE...........................................25
7.1.2 Parent PCE..........................................26 7.1.2 Parent PCE..........................................26
7.1.3 Policy Control......................................27 7.1.3 Policy Control......................................26
7.2 Information and Data Models...............................27 7.2 Information and Data Models...............................26
7.3 Liveness Detection and Monitoring.........................27 7.3 Liveness Detection and Monitoring.........................26
7.4 Verifying Correct Operation...............................27 7.4 Verifying Correct Operation...............................26
7.5. Impact on Network Operation..............................28 7.5. Impact on Network Operation..............................27
8. Security Considerations ......................................28 8. Security Considerations ......................................27
9. IANA Considerations ..........................................29 9. IANA Considerations ..........................................28
10. Acknowledgements ............................................29 10. Acknowledgements ............................................28
11. References ..................................................29 11. References ..................................................28
11.1. Normative References....................................29 11.1. Normative References....................................28
11.2. Informative References .................................20 11.2. Informative References .................................29
12. Authors' Addresses ..........................................31 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 (TE) and GMPLS Label Switched Paths (LSPs) is
expressed as requirements in [RFC4105] and [RFC4216]. This capability expressed as requirements in [RFC4105] and [RFC4216]. This capability
may be realized by a Path Computation Element (PCE). The PCE may be realized by a Path Computation Element (PCE). The PCE
architecture is defined in [RFC4655]. The methods for establishing architecture is defined in [RFC4655]. The methods for establishing
and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in
[RFC4726]. [RFC4726].
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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 path 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 egress in known in advance. and 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 PCE
architecture can be extended to allow the optimum sequence of domains architecture can be extended to allow the optimum sequence of domains
to be selected, and the optimum end-to-end path to be derived. 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 more
advanced deployments (such as optical networks constructed from 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.
This document introduces the concept of a hierarchical PCE
architecture and shows how to coordinate PCEs in peer domains in
order to derive an optimal end-to-end path.
The work is scoped to operate with a small group of domains, and
there is no intent to apply this model to a large group of domains,
e.g., to the Internet.
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 areas and Autonomous Systems. Wholly or partially overlapping IGP 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, computation of an end-to-end path requires [G-8080]. In this case, a domain might be an ASON Routing Area
the selection of nodes and links within a parent domain where some [G-7715]. Furthermore, computation of an end-to-end path requires
nodes may, in fact, be subnetworks. Furthermore, a domain might be an the selection of nodes and links within a routing area where some
ASON Routing Area [G-7715]. A PCE may perform the path computation nodes may, in fact, be subnetworks. A PCE may perform the path
function of an ASON Routing Controller as described in [G-7715-2]. computation function of an ASON Routing Controller as described in
See Section 6.2 for a further discussion of the applicability to the [G-7715-2]. See Section 5.2 for a further discussion of 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 paradigms) is used to determine the sequence of domains. The of 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
skipping to change at page 6, line 15 skipping to change at page 6, line 9
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 7 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
skipping to change at page 7, line 5 skipping to change at page 6, line 47
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 [RFC5541]
o Minimize aggregate bandwidth consumption [RFC5541] o Minimize aggregate bandwidth consumption [RFC5541]
o Minimize the Load of the most loaded Link [RFC5541] o Minimize the Load of the most loaded Link [RFC5541]
o Minimize the Cumulative Cost of a set of paths [RFC5541] o Minimize the Cumulative Cost of a set of paths [RFC5541]
o Minimize or cap the number of domains crossed o Minimize or cap the number of domains crossed
o Disallow domain re-entry o Disallow domain re-entry
See Section 5.1 for further discussion of objective functions. See Section 5.1 for further discussion of objective functions.
1.3.2 Domain Diversity 1.3.2 Diversity
1.3.2.1 Physical Diversity
Within a Carrier's Carrier environment MPLS services may share common
underlying equipment and resources, including optical fiber and
nodes. An MPLS service request may require a path for traffic that is
physically disjointed from another service. Thus, if a physical link
or node fails on one of the disjoint paths, not all traffic is lost.
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
skipping to change at page 7, line 35 skipping to change at page 7, line 38
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, SLAs, security, peering
preferences, and dollar costs. 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 that specific domains are included or excluded based on request that specific domains are included or excluded based on
commercial relationships, security implications, and reliability. commercial 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
skipping to change at page 8, line 16 skipping to change at page 8, line 21
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 inter-connections. 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. preference for the choice of points of interconnection.
1.4 Terminology 1.4 Terminology
This document uses PCE terminology defined in [RFC4655], [RFC4875], 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 domain for a specific path. neighbor 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.
skipping to change at page 9, line 39 skipping to change at page 9, line 42
best path across the domain to provide connectivity to the next best path across the domain to provide connectivity to the next
domain in the domain sequence (usually indicated in signalling by an domain in the domain sequence (usually indicated in signalling by an
identifier of the next domain or the identity of the next entry BN). 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 sub-optimal 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 PCE must select an exit BN based on boundary nodes) is not known, the path computing entity must select
some determination of how to reach the destination that is outside an exit BN based on some determination of how to reach the
the domain for which the PCE has computational responsibility. destination that is outside the domain for which the path computing
[RFC5152] suggest that this might be achieved using the IP shortest entity has computational responsibility. [RFC5152] suggest that this
path as advertise by BGP. Note, however, that the existence of an IP might be achieved using the IP shortest path as advertise by BGP.
forwarding path does not guarantee the presence of sufficient Note, however, that the existence of an IP forwarding path does not
bandwidth, let alone an optimal TE path. Furthermore, in many GMPLS guarantee the presence of sufficient bandwidth, let alone an optimal
systems inter-domain IP routing will not be present. Thus, per-domain TE path. Furthermore, in many GMPLS systems inter-domain IP routing
path computation may require a significant number of crankback will not be present. Thus, per-domain path computation may require a
routing attempts to establish even a sub-optimal path. significant number of crankback routing attempts to establish even a
sub-optimal path.
Note also that the PCEs in each domain may have different computation Note also that the path computing entities in each domain may have
capabilities, may run different path computation algorithms, and may different computation capabilities, may run different path
apply different sets of constraints and optimization criteria, etc. computation algorithms, and may apply different sets of constraints
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 sub-
optimal. optimal.
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 Path Computation
The Backward Recursive Path Computation (BRPC) [RFC5441] procedure The Backward Recursive Path Computation (BRPC) [RFC5441] procedure
involves cooperation and communication between PCEs in order to involves cooperation and communication between PCEs in order to
compute an optimal end-to-end path across multiple domains. The compute an optimal end-to-end path across multiple domains. The
sequence of domains to be traversed can either be determined before sequence of domains to be traversed can either be determined before
or during the path computation. In the case where the sequence of or during the path computation. In the case where the sequence of
domains is known, the ingress Path Computation Client (PCC) sends a domains is known, the ingress Path Computation Client (PCC) sends a
path computation request to the PCE responsible for the ingress path computation request to a PCE responsible for the ingress
domain. This request is forwarded between PCEs, domain-by-domain, to domain. This request is forwarded between PCEs, domain-by-domain, to
the PCE responsible for the egress domain. The PCE in the egress a PCE responsible for the egress domain. The PCE in the egress
domain creates a set of optimal paths from all of the domain entry domain creates a set of optimal paths from all of the domain entry
BNs to the egress LSR. This set is represented as a tree of potential BNs to the egress LSR. This set is represented as a tree of potential
paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes
it back to the previous PCE on the domain path. As the VSPT is passed it back to the previous PCE on the domain path. As the VSPT is passed
back toward the ingress domain, each PCE computes the optimal paths back toward the ingress domain, each PCE computes the optimal paths
from its entry BNs to its exit BNs that connect to the rest of the from its entry BNs to its exit BNs that connect to the rest of the
tree. It adds these paths to the VSPT and passes the VSPT on until tree. It adds these paths to the VSPT and passes the VSPT on until
the PCE for the ingress domain is reached and computes paths from the the PCE for the ingress domain is reached and computes paths from the
ingress LSR to connect to the rest of the tree. The ingress PCE then ingress LSR to connect to the rest of the tree. The ingress PCE then
skipping to change at page 10, line 47 skipping to change at page 10, line 52
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 can also be used when the domain path
is not known. 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 sequence
of domains is not known BRPC could be used as follows. of domains is not known BRPC could be used as follows.
o The PCC sends a request to the 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 the o The ingress PCE sends the path computation request direct to a
PCE responsible for the domain containing the destination node (the PCE 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.
skipping to change at page 12, line 8 skipping to change at page 12, line 13
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
5.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 may
be sequential or parallel depending on implementation details. 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 which 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
this document. However the hierarchical PCE architecture described
does support the function of parent PCE and child PCE being
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 Deriving the optimal end-to-end domain path sequence is dependent on
the policy applied during domain path computation. An Objective the policy applied during domain path computation. An Objective
Function (OF) [RFC5541], or set of OFs, may be applied to define the Function (OF) [RFC5541], or set of OFs, may be applied to define the
policy being applied to the domain path computation. policy being applied to the domain path computation.
The OF specifies the desired outcome of the computation. It does The OF specifies the desired outcome of the computation. It does
skipping to change at page 12, line 47 skipping to change at page 13, line 8
domain paths, required OFs may include (see Section 1.3.1): domain paths, required OFs may include (see Section 1.3.1):
o Minimum cost path o Minimum cost path
o Minimum load path o Minimum load path
o Maximum residual bandwidth path o Maximum residual bandwidth path
o Minimize aggregate bandwidth consumption o Minimize aggregate bandwidth consumption
o Minimize or cap the number of transit domains o Minimize or cap the number of transit domains
o Disallow domain re-entry 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 maybe applied by the domain PCE (according to local policy), or applied by the parent PCE
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 OFs
may include weightings and preferences for the fulfillment of pieces may include weightings and preferences for the fulfillment of pieces
of the desired outcome. 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
skipping to change at page 13, line 45 skipping to change at page 14, line 8
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. 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 capabilities [RFC5316], [RFC5392]. This information can be link capabilities [RFC5316], [RFC5392]. This information can be
collected by the child PCEs and forwarded to the parent PCE, or the collected by the child PCEs and forwarded to the parent PCE, or the
parent PCE could participate in the IGP in the child domains. parent PCE could participate in the IGP in the child domains.
4.4 Parent Domain Traffic Engineering Database 4.4 Parent Domain Traffic Engineering Database
skipping to change at page 19, line 16 skipping to change at page 19, line 14
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 to the egress. The child PCE should return the relevant path to the egress. The child PCE should return the relevant
error to notify the parent PCE. Depending on the error response the error to notify the parent PCE. Depending on the error response the
parent PCE can elect to: 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 Relax the constraints associated with the initial path request; o Relax some of the constraints associated with the initial path
request;
o Select another candidate domain and send the path request to the o Select another candidate domain and send the path request to the
child PCE responsible for the domain. 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 either: an allotted time period. The parent PCE can either:
o Send the path request to another child PCE in the same domain, if a o Send the path request to another child PCE in the same domain, if a
secondary child PCE exists; secondary child PCE exists;
o Select another candidate domain and send the path request to the o Select another candidate domain and send the path 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
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 PCEP request (PCReq) messages are used by a PCC or a PCE to make a
skipping to change at page 20, line 6 skipping to change at page 20, line 6
it receives from the parent PCE should consist of a domain sequence it receives from the parent PCE should consist of a domain sequence
only (i.e., not a fully-specified end-to-end path). This allows the only (i.e., not a fully-specified end-to-end path). This allows the
child PCE to initiate per-domain or backward recursive path child PCE to initiate per-domain or backward recursive path
computation. 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 carried within the PCReq message. RP 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 child PCE indicates that it might wish to use the parent as a the child PCE indicates that it might wish to use the parent-capable
parent (for example, on the Open message), and if the parent as a parent (for example, on the Open message), and if the
determines at that time whether it is willing to act as a parent to parent-capable determines at that time whether it is willing to act
this child. as a parent to this child.
4.8.4 Communication of Domain Connectivity Information 4.8.4 Communication of Domain Connectivity Information
Section 5.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
skipping to change at page 21, line 34 skipping to change at page 21, line 34
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 Antonymous Systems and IGP areas. The hierarchical PCE including Antonymous Systems and IGP areas. The hierarchical PCE
procedures make no distinction between, Antonymous Systems and IGP procedures make no distinction between, Antonymous 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 4). 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 Antonymous Systems and Areas 5.1 Antonymous Systems and Areas
skipping to change at page 26, line ? skipping to change at page 25, line 16
[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 and
the architecture enabled by [BGP-TE] make different assumptions about the architecture enabled by [BGP-TE] make different assumptions about
the operational objectives of the networks, and this document does the operational objectives of the networks, and this document does
not attempt to make one of the approaches "right" and the other 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
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 Reflector. Furthermore, the inter-domain connectivity and Route Reflector. Furthermore, the inter-domain connectivity and
connectivity capabilities that is required information for a parent connectivity capabilities that is required information for a parent
PCE could be obtained as a filtered subset of the information PCE could be obtained as a filtered subset of the information
available in [BGP-TE]. available in [BGP-TE]. This scenario is discussed further in
[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
skipping to change at page 27, line 18 skipping to change at page 26, line 21
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
dollar 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,
skipping to change at page 29, line 30 skipping to change at page 28, line 33
Further considerations of the security issues related to inter-AS Further considerations of the security issues related to inter-AS
path computation see [RFC5376]. path computation see [RFC5376].
9. IANA Considerations 9. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank David Amzallag, Oscar Gonzalez de The authors would like to thank David Amzallag, Oscar Gonzalez de
Diosm, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini, Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini,
and Dhruv Dhody for their comments and suggestions. Dhruv Dhody and Julien Meuric for their comments and suggestions.
11. References 11. References
11.1 Normative References 11.1 Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., Ash, J., "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)", Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008. RFC 5152, February 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
December 2008. December 2008.
skipping to change at page 30, line 20 skipping to change at page 29, line 20
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter- Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths", RFC domain Traffic Engineering Label Switched Paths", RFC
5441, April 2009. 5441, April 2009.
[RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving [RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving
Topology Confidentiality in Inter-Domain Path Topology Confidentiality in Inter-Domain Path
Computation Using a Key-Based Mechanism Computation Using a Key-Based Mechanism
RFC5520, April 2009. RFC5520, April 2009.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture
and Requirements for the Automatically
Switched Optical Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON
routing architecture and requirements for remote route
query.
11.2. Informative References 11.2. Informative References
[RFC4105] Le Roux, J.-L., Vasseur, J.-P, and Boyle, J., [RFC4105] Le Roux, JL., Vasseur, J., Boyle, J.,
"Requirements for Inter-Area MPLS Traffic Engineering", "Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005. RFC 4105, June 2005.
[RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-Autonomous [RFC4216] Zhang, R., and Vasseur, J., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", RFC System (AS) Traffic Engineering (TE) Requirements", RFC
4216, November 2005. 4216, November 2005.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework [RFC4726] Farrel, A., Vasseur, J., Ayyangar, A., "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., [RFC5152] Vasseur, JP., Ayyangar, A., Zhang, R., "A Per-Domain
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)", Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008. RFC 5152, February 2008.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., Duan, X., "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., et al., "Inter-AS Requirements for the
Path Computation Element Communication Protocol Path Computation Element Communication Protocol
(PCECP)", RFC 5376, November 2008. (PCECP)", RFC 5376, November 2008.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in [RFC5392] Chen, M., Zhang, R., Duan, X., "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] Roux, J., Vasseur, J., and Y. Lee, "Encoding [RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding
of Objective Functions in the Path of Objective Functions in the Path Computation Element
Computation Element Communication Communication Protocol (PCEP)", RFC5541, December 2008.
Protocol (PCEP)", RFC5541, December 2008.
[BGP-TE] Gredler, H., Medved, J, Farrel, A. and Previdi, S., [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture
and Requirements for the Automatically
Switched Optical Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON
routing architecture and requirements for remote route
query.
[BGP-TE] Gredler, H., Medved, J, Farrel, A. Previdi, S.,
"North-Bound Distribution of Link-State and TE "North-Bound Distribution of Link-State and TE
Information using BGP", draft-gredler-idr-ls-distribution, Information using BGP", draft-gredler-idr-ls-distribution,
work in progress. work in progress.
[PCEP-MIB] Stephan, E., Koushik, K., Zhao, Q., and King, D., "PCE [PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de
Dios, O., "Applicability of the Path Computation Element
to Inter-Area and Inter-AS MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-area-as-applicability,
work in progress.
[PCEP-MIB] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE
Communication Protocol (PCEP) Management Information Communication Protocol (PCEP) Management Information
Base", work in progress. Base", work in progress.
12. Authors' Addresses 12. Authors' Addresses
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
UK
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
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
 End of changes. 50 change blocks. 
104 lines changed or deleted 129 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/