draft-ietf-pce-inter-area-as-applicability-01.txt   draft-ietf-pce-inter-area-as-applicability-02.txt 
PCE Working Group D. King PCE Working Group D. King
Internet Draft Old Dog Consulting Internet Draft Old Dog Consulting
Intended status: Informational J. Meuric Intended status: Informational J. Meuric
Expires: October 18, 2011 O. Dugeon Expires: June 16, 2012 O. Dugeon
France Telecom France Telecom
Q. Zhao Q. Zhao
Huawei Technologies Huawei Technologies
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Francisco Javier Jimenex Chico Francisco Javier Jimenex Chico
Telefonica I+D Telefonica I+D
April 18, 2011 January 16, 2012
Applicability of the Path Computation Element to Inter-Area and Applicability of the Path Computation Element to Inter-Area and
Inter-AS MPLS and GMPLS Traffic Engineering Inter-AS MPLS and GMPLS Traffic Engineering
draft-ietf-pce-inter-area-as-applicability-01 draft-ietf-pce-inter-area-as-applicability-02
Abstract Abstract
The Path Computation Element (PCE) may be used for computing services The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-AS Multiprotocol Label Switching that traverse multi-area and multi-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.
This document examines the applicability of the PCE architecture, This document examines the applicability of the PCE architecture,
protocols, and protocol extensions for computing multi-area and protocols, and protocol extensions for computing multi-area and
multi-AS paths in MPLS and GMPLS networks. multi-AS paths in MPLS and GMPLS networks.
skipping to change at page 1, line 50 skipping to change at page 1, line 50
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 18, 2011. This Internet-Draft will expire on October 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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.
Table of Contents Table of Contents
1. Introduction.................................................3 1. Introduction.................................................3
1.1. Domains....................................................4 1.1. Domains....................................................4
1.2. Path Computation...........................................5 1.2. Path Computation...........................................4
1.2.1 PCE-based Path Computation Procedure......................5
1.3. Traffic Engineering Aggregation and Abstraction............5 1.3. Traffic Engineering Aggregation and Abstraction............5
1.4. Traffic Engineered Label Switched Paths....................5 1.4. Traffic Engineered Label Switched Paths....................6
1.5. Inter-area and Inter AS Connectivity Discovery.............5 1.5. Inter-area and Inter AS Connectivity Discovery.............6
2. Terminology..................................................6 2. Terminology..................................................6
3. Issues and Considerations....................................6 3. Issues and Considerations....................................7
3.1 Multi-homed domains......................................6 3.1 Multi-homing.............................................7
3.2 Domain meshes............................................6 3.2 Domain Confidentiality ..................................7
3.3 Destination location.....................................6 3.3 Destination Location.....................................7
4. Applicability of the PCE to Inter-area Traffic Engineering...7 4. Domain Topologies............................................8
4.1. Inter-area Routing......................................7 4.1 Selecting Domain Paths...................................8
4.1.1. Area Inclusion and Exclusion..........................7 4.2 Multi-Homed Domains......................................8
4.1.2. Strict Explicit Path and Loose Path...................7 4.3 Domain Meshes............................................8
4.1.3. Inter-Area Diverse Path Computation...................7 4.4 Domain Diversity.........................................8
4.2. Control and Recording of Area Crossing..................7 4.5 Synchronized Path Computations...........................9
4.3. Inter-Area Policies ....................................7 5. Applicability of the PCE to Inter-area Traffic Engineering...9
4.4. Loop Avoidance .........................................7 5.1. Inter-area Routing......................................10
5. Applicability of the PCE to Inter-AS Traffic Engineering.....7 5.1.1. Area Inclusion and Exclusion..........................10
5.1. Inter-AS Routing........................................8 5.1.2. Strict Explicit Path and Loose Path...................11
5.1.1. AS Inclusion and Exclusion............................8 5.1.3. Inter-Area Diverse Path Computation...................11
5.1.2. Strict Explicit Path and Loose Path...................8 5.2. Control and Recording of Area Crossing..................11
5.1.3. AS Inclusion and Exclusion............................8 6. Applicability of the PCE to Inter-AS Traffic Engineering.....11
5.2. Inter-AS Bandwidth Guarantees...........................8 6.1. Inter-AS Routing........................................12
5.3. Inter-AS Recovery.......................................9 6.1.1. AS Inclusion and Exclusion............................12
5.4. Inter-AS PCE Peering Policies...........................9 6.1.2. Strict Explicit Path and Loose Path...................12
6. Multi-Domain PCE Deployment..................................9 6.1.3. AS Inclusion and Exclusion............................12
6.1 Overview of Techniques...................................10 6.2. Inter-AS Bandwidth Guarantees...........................12
6.2 Traffic Engineering Database.............................10 6.3. Inter-AS Recovery.......................................13
6.3 Provisioning Techniques..................................11 6.4. Inter-AS PCE Peering Policies...........................13
6.4 Pre-Planning and Management-Based Solutions..............11
6.5 Per-Domain Computation...................................11 7. Multi-Domain PCE Deployment..................................13
6.6 Cooperative PCEs.........................................11 7.1 Traffic Engineering Database.............................14
6.7 Hierarchical PCEs ......................................12 7.2 Provisioning Techniques..................................15
7. Domain Topologies............................................12 7.3 Pre-Planning and Management-Based Solutions..............15
7.1 Selecting Domain Paths...................................12 7.4 Per-Domain Computation...................................15
7.2 Multi-Homed Domains......................................12 7.5 Cooperative PCEs.........................................15
7.3 Domain Meshes............................................12 7.6 Hierarchical PCEs ......................................16
7.4 Route Diversity..........................................12 8. Domain Confidentiality.......................................16
7.5 Synchronized Path Computations...........................12 8.1 Loose Hops...............................................16
8. Domain Confidentiality.......................................13 8.2 Confidential Path Segments and Path Keys.................16
8.1 Loose Hops...............................................13 9. Point-to-Multipoint..........................................17
8.2 Confidential Path Segments and Path Keys.................13 10. Optical Domains.............................................17
9. Point-to-Multipoint..........................................13 10.1. PCE applied to the ASON Architecture......................17
10. Optical Domains.............................................13 11. Manageability Considerations................................18
10.1. PCE applied to the ASON Architecture......................14 12. Security Considerations.....................................18
11.1. Policy Control............................................14 13. IANA Considerations.........................................18
11.1.1 Inter-AS PCE Peering Policy Controls.....................14 14. References..................................................18
12. IANA Considerations.........................................15 14.1. Normative References......................................18
13. References..................................................15 14.2. Informative References....................................18
13.1. Normative References......................................15 15. Acknowledgements............................................20
13.2. Informative References....................................15 16. Author's Address............................................20
14. Acknowledgements............................................16
15. Author's Address............................................17
1. Introduction 1. Introduction
Computing paths across large multi-domain environments may Computing paths across large multi-domain environments may
require special computational components and cooperation between require special computational components and cooperation between
entities in different domains capable of complex path computation. entities in different domains capable of complex path computation.
The Path Computation Element (PCE) [RFC4655] provides an architecture The Path Computation Element (PCE) [RFC4655] provides an architecture
and a set of functional components to address this problem space. and a set of functional components to address this problem space.
Computing optimal routes for LSPs that cross domains in MPLS-TE and Computing optimal routes for LSPs that cross domains in MPLS-TE and
skipping to change at page 5, line 16 skipping to change at page 5, line 12
domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE
(as per [H-PCE]). (as per [H-PCE]).
It is entirely feasible that an operator could compute a path across It is entirely feasible that an operator could compute a path across
multiple domains without the use of a PCE if the relevant domain multiple domains without the use of a PCE if the relevant domain
information is available to the network planner or network management information is available to the network planner or network management
platform. The definition of what relevant information is required to platform. The definition of what relevant information is required to
perform this network planning operation and how that information is perform this network planning operation and how that information is
discovered and applied is outside the scope of this document. discovered and applied is outside the scope of this document.
1.2.1 PCE-based Path Computation Procedure
As discussed, the PCE is an entity capable of computing an
inter-domain TE path upon receiving a request from a PCC. There could
be a single PCE per domain, or single PCE responsible for all
domains. A PCE may or may not reside on the same node as the
requesting PCC. A path may be computed by either a single PCE node
or a set of distributed PCE nodes that collaborate during path
computation.
[RFC4655] defines that a PCC should send a path computation request
to a particular PCE, using [RFC5440] (PCC-to-PCE communication).
This negates the need to broadcast a request to all the PCEs. Each
PCC can maintain information about the computation capabilities
of the PCEs it is aware of. The PCC-PCE capability awareness can
configured using static configuration or by listening to
the periodic advertisements generated by PCEs.
One a path computation request is received, the PCC will send a
request to the PCE. A PCE may compute the end-to-end path
if it is aware of the topology and TE information required to
compute the entire path. If the PCE is unable to compute the
entire path, the PCE architecture provides co-operative PCE
mechanisms for the resolution of path computation requests when an
individual PCE does not have sufficient TE visibility.
A PCE may cooperate with other PCEs to determine intermediate loose
hops. End-to-end path segments may be kept confidential through the
application of path keys, to protect partial or full path
information. A path key that is a token that replaces a path segment
in an explicit route. The path key mechanism is described in
[RFC5520]
1.3 Traffic Engineering Aggregation and Abstraction 1.3 Traffic Engineering Aggregation and Abstraction
Networks are often constructed from multiple areas or ASs that are Networks are often constructed from multiple areas or ASs that are
interconnected via multiple interconnect points. To maintain interconnected via multiple interconnect points. To maintain
network confidentiality and scalability TE properties of each area network confidentiality and scalability TE properties of each area
and AS are not generally advertized outside each specific area or AS. and AS are not generally advertized outside each specific area or AS.
TE aggregation or abstraction provide mechanism to hide information TE aggregation or abstraction provide mechanism to hide information
but may cause failed path setups or the selection of suboptimal but may cause failed path setups or the selection of suboptimal
end-to-end paths [RFC4726]. The aggregation process may also have end-to-end paths [RFC4726]. The aggregation process may also have
skipping to change at page 5, line 51 skipping to change at page 6, line 29
Three signaling options are defined for setting up an inter-area or Three signaling options are defined for setting up an inter-area or
inter-AS LSP [RFC4726]: inter-AS LSP [RFC4726]:
- Contiguous LSP - Contiguous LSP
- Stitched LSP - Stitched LSP
- Nested LSP - Nested LSP
All three signaling methods are applicable to the architectures and All three signaling methods are applicable to the architectures and
procedures discussed in this document. procedures discussed in this document.
1.5 Inter-area and Inter AS Connectivity Discovery 1.5 Inter-area and Inter-AS Connectivity Discovery
When using a PCE-based approach for inter-area and inter-AS path When using a PCE-based approach for inter-area and inter-AS path
computation, a PCE in one area or AS may need to learn information computation, a PCE in one area or AS may need to learn information
related to inter-AS capable PCEs located in other ASs. The PCE related to inter-AS capable PCEs located in other ASs. The PCE
discovery mechanism defined in [RFC5088] and [RFC5089] allow discovery mechanism defined in [RFC5088] and [RFC5089] allow
the discovery of PCEs and disclosure of information related to the discovery of PCEs and disclosure of information related to
inter-area and inter-AS capable PCEs across area and AS boundaries. inter-area and inter-AS capable PCEs across area and AS boundaries.
2. Terminology 2. Terminology
Terminology used in this document. Terminology used in this document.
ABR: IGP Area Border Router, a router that is attached to more than ABR: IGP Area Border Router, a router that is attached to more than
one IGP area. one IGP area.
ASBR: Autonomous System Border Router, a router used to connect ASBR: Autonomous System Border Router, a router used to connect
together ASs of a different or the same Service Provider via one or together ASs of a different or the same Service Provider via one or
more inter-AS links. more inter-AS links.
CSPF: Constrained Shortest Path First.
Inter-area TE LSP: A TE LSP whose path transits through two or more Inter-area TE LSP: A TE LSP whose path transits through two or more
IGP areas. IGP areas.
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or
more ASs or sub-ASs (BGP confederations more ASs or sub-ASs (BGP confederations
LSP: Traffic Engineered Label Switched Path. SRLG: Shared Risk Link Group.
LSR: Label Switching Router.
TED: Traffic Engineering Database, which contains the topology and TED: Traffic Engineering Database, which contains the topology and
resource information of the domain. The TED may be fed by Interior resource information of the domain. The TED may be fed by Interior
Gateway Protocol (IGP) extensions or potentially by other means. Gateway Protocol (IGP) extensions or potentially by other means.
This document also uses the terminology defined in [RFC4655] and This document also uses the terminology defined in [RFC4655] and
[RFC5440]. [RFC5440].
3. Issues and Considerations 3. Issues and Considerations
3.1 Multi-homed domains 3.1 Multi-homing
3.2 Domain meshes Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid
single point failures disrupting primary and backup services.
3.3 Destination location Domain and path diversity may also be required when computing
end-to-end paths. Domain diversity should facilitate the selection
of paths that share ingress and egress domains, but do not share
transit domains. Therefore, there must be a method allowing the
inclusion or exclusion of specific domains when computing end-to-end
paths.
3.2 Domain Confidentiality
Where the end-to-end path crosses multiple domains, it may be
possible that each domain (AS or area) are administered by separate
Service Providers, it would break confidentiality rules for a PCE
to supply a path segment to a PCE in another domain, thus disclosing
AS-internal topology information.
If confidentiality is required between domains (ASes and areas)
belonging to different Service Providers. Then cooperating PCEs
cannot exchange path segments or else the receiving PCE PCC will be
able to see the individual hops through another domain.
3.3 Destination Location
The PCC asking for an inter-domain path computation is typically
aware of the identity of the destination node. Additionally, if the
PCC is aware of the destination domain, it can supply this
information as part of the path computation request. However,
if the PCC does not know the egress domain this information must
be determined by another method.
4. Domain Topologies
Constraint-based inter-domain path computation is a fundamental
requirement for operating traffic engineered MPLS [RFC3209] and
GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain)
environments. Path computation across multi-domain networks is
complex and requires computational cooperational entities like the
PCE.
4.1 Selecting Domain Paths
Where the sequence of domains is known a priori, various techniques
can be employed to derive an optimal multi-domain path. If the
domains are simply-connected, or if the preferred points of
interconnection are also known, the Per-Domain Path Computation
[RFC5152] technique can be used. Where there are multiple connections
between domains and there is no preference for the choice of points
of interconnection, BRPC [RFC5441] can be used to derive an optimal
path.
When the sequence of domains is not known in advance, the optimum
end-to-end path can be derived through the use of a hierarchical
relationship between domains [H-PCE].
4.2 Multi-Homed Domains
Networks constructed from multi-areas or multi-AS environments
may have multiple interconnect points (multi-homing). End-to-end path
computations may need to use different interconnect points to avoid
single point failures disrupting primary and backup services.
4.3 Domain Meshes
Very frequently network domains are composed by dozens or hundreds of
network elements. These network elements are usually interconnected
between them in a partial-mesh fashion, to provide survivability
against dual failures, and to benefit from the traffic engineering
capabilities from MPLS and GMPLS protocols. A typical node degree
ranges from 3 to 10 (4-5 is quite common), being the node degree the
number of neighbors per node.
Networks are sometimes divided into domains. Some reasons for it
range from manageability to separation into vendor-specific domains.
The size of the domain will be usually limited by control plane, but
it can also be stated by arbitrary design constraints.
4.4 Domain Diversity
Whenever an specific connectivity service is required to have 1+1
protection feature, two completely disjoint paths must be
established on an end to end fashion. In a multi-domain environment
without, this can be accomplished either by selecting domain
diversity, or by ensuring diverse connection within a domain. In
order to compute the route diversity, it could be helpful to have
SRLG information in the domains.
4.5 Synchronized Path Computations
In some scenarios, it would be beneficial for the operator to rely on
the capability of the PCE to perform synchronized path computation.
Synchronized path computations, known as Synchronization VECtors
(SVECs) are used for dependent path computations. [RFC6007] provides
an overview for the use of the PCE SVEC list for synchronized path
computations when computing dependent requests.
A non-comprehensive list of synchronized path computations include
the following examples:
o Route diversity: computation of two disjoint paths from a source to
a destination (as drafted in the previous section).
o Synchronous restoration: joint computation of a set of alternative
paths for a set of affected LSPs as a consequence of a failure
event. Note that in this case, the requests will potentially
involve different source-destination pairs. In this scenario, the
different path computation requests may arrive at different time
stamps.
o Batch provisioning: It is common that the operator sends a set of
LSPs requests together, e.g in a daily of weekly basis, mainly in
case of long lived LSPs. In order to optimize the resource usage,
a synchronized path computation is needed.
o Network optimization: After some time of operation, the
distribution of the established LSP paths results in a non optimal
use of resources. Also, inter-domain policies/agreements may have
been changed. In such cases, a full (or partial) network planning
action regarding the inter-domain connections will be triggered.
This will involve the request of potentially a big amount of
connections.
5. Applicability of the PCE to Inter-area Traffic Engineering
4. Applicability of the PCE to Inter-area Traffic Engineering
As networks increase in size and complexity it may be required to As networks increase in size and complexity it may be required to
introduce scaling methods to reduce the amount information flooded introduce scaling methods to reduce the amount information flooded
within the network and make the network more manageable. An IGP within the network and make the network more manageable. An IGP
hierarchy is designed to improve IGP scalability by dividing the hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of information to within area boundaries. This restricts visibility of
the area to routers in a single area. If a router needs to compute a the area to routers in a single area. If a router needs to compute a
route to destination located in another area a method is required to route to destination located in another area a method is required to
compute a path across area boundaries. compute a path across area boundaries.
skipping to change at page 7, line 26 skipping to change at page 10, line 23
useful to divide the network in vendor domains. Each vendor domain is useful to divide the network in vendor domains. Each vendor domain is
an IGP area, and the flooding scope of the topology (as well as any an IGP area, and the flooding scope of the topology (as well as any
other relevant information) is limited to the area boundaries. other relevant information) is limited to the area boundaries.
Per-domain path computation [RFC5152] exists to provide a method of Per-domain path computation [RFC5152] exists to provide a method of
inter-area path computation. The per-domain solution is based on inter-area path computation. The per-domain solution is based on
loose hop routing with an Explicit Route Object (ERO) expansion on loose hop routing with an Explicit Route Object (ERO) expansion on
each Area Border Router (ABR). This allows an LSP to be established each Area Border Router (ABR). This allows an LSP to be established
using a constrained path, however at least two issues exist: using a constrained path, however at least two issues exist:
- This method does not guarantee an optimal constrained path - This method does not guarantee an optimal constrained path.
- The method may require several crankback signaling messages - The method may require several crankback signaling messages
increasing signaling traffic and delaying the LSP setup increasing signaling traffic and delaying the LSP setup.
The PCE-based architecture [RFC4655] is designed to solve inter-area The PCE-based architecture [RFC4655] is designed to solve inter-area
path computation problems. The issue of limited topology visibility path computation problems. The issue of limited topology visibility
is resolved by introducing path computation entities that are able to is resolved by introducing path computation entities that are able to
cooperate in order to establish LSPs with source and destinations cooperate in order to establish LSPs with source and destinations
located in different areas. located in different areas.
4.1. Inter-area Routing 5.1. Inter-area Routing
4.1.1. Area Inclusion and Exclusion An inter-area TE-LSP is an LSP that transits through at least two
IGP areas. In a multi-area network, topology visibility remains
local to a given area, and a node in one area will not be able to
compute an end-to-end path across multiple areas without the use
of a PCE.
4.1.2. Strict Explicit Path and Loose Path 5.1.1. Area Inclusion and Exclusion
4.1.3. Inter-Area Diverse Path Computation [RFC5152] provides the mechanisms to compute an inter-area
path. It uses loose hop routing with an ERO expansion on each ABR.
This allows the end-to-end path to be set up following a constrained
path, but faces two major limitations:
4.2. Control and Recording of Area Crossing - The method does not guarantee the use of an optimal constrained
path.
4.3. Inter-Area Policies - This may lead to several crankback signaling messages and hence
delay the path setup.
4.4. Loop Avoidance [RFC5441] provides a more optimal method to specify inclusion or
exclusion of an ABR. Using this method, an operator might decide if
an area must be include or exclude from the inter-area path
computation.
5. Applicability of the PCE to Inter-AS Traffic Engineering 5.1.2. Strict Explicit Path and Loose Path
A strict explicit Path is defined as a set of strict hops, while a
loose path is defined as a set of at least one loose hop and zero,
one or more strict hops. It may be useful to indicate, during the
path computation request, if a strict explicit path is required or
not. An inter-area path may be strictly explicit or loose (e.g., a
list of ABRs as loose hops).
A PCC request to a PCE does allow the indication of if a strict
explicit path across specific areas is required or desired, or if
the path request is loose.
5.1.3. Inter-Area Diverse Path Computation
It may be neccessary (for protection or load-balancing) to compute
a path that is diverse, from a previously computed path. There are
various levels of diversity in the context of an inter-area network:
- Per-area diversity (intra-area path segments are link, node or
SRLG disjoint.
- Inter-area diversity (end-to-end inter-area paths are link,
node or SRLG disjoint).
Note that two paths may be disjoint in the backbone area but non-
disjoint in peripheral areas. Also two paths may be node disjoint
within areas but may share ABRs, in which case path segments within
an area are node disjoint but end-to-end paths are not node-disjoint.
Both Per-Domain [RFC5152] and BRPC [RFC5441] mechanisms support the
capability to compute diverse across multi-area topologies.
5.2. Control and Recording of Area Crossing
In some environments it be useful for the PCE to provide a PCC the
set of areas crossed by the end-to-end path. Additionally the PCE
can provide the path information and mark each segment so the PCC
has visibility of which piece of the path lies within which area.
Although by implementing Path-Key, the hop-by-hop (area topology)
information is kept confidential.
6. Applicability of the PCE to Inter-AS Traffic Engineering
As discussed in section 4 (Applicability of the PCE to Inter-area As discussed in section 4 (Applicability of the PCE to Inter-area
Traffic Engineering) it is necessary to divide the network into Traffic Engineering) it is necessary to divide the network into
smaller administrative domains, or ASs. If an LSR within an AS needs smaller administrative domains, or ASs. If an LSR within an AS needs
to compute a path across an AS boundary it must also use an inter-AS to compute a path across an AS boundary it must also use an inter-AS
computation technique. [RFC5152] defines mechanisms for the computation technique. [RFC5152] defines mechanisms for the
computation of inter-domain TE LSPs using network elements along the computation of inter-domain TE LSPs using network elements along the
signaling paths to compute per-domain constrained path segments. signaling paths to compute per-domain constrained path segments.
The PCE was designed to be capable of computing MPLS and GMPLS paths The PCE was designed to be capable of computing MPLS and GMPLS paths
across AS boundaries. This section outlines the features of a across AS boundaries. This section outlines the features of a
PCE-enabled solution for computing inter-AS paths. PCE-enabled solution for computing inter-AS paths.
5.1 Inter-AS Routing 6.1 Inter-AS Routing
5.1.1. AS Inclusion and Exclusion 6.1.1. AS Inclusion and Exclusion
5.1.2. Strict Explicit Path and Loose Path [RFC5441] a method to specify inclusion or exclusion of an ASBR.
Using this method, an operator might decide if an AS must be include
or exclude from the inter-AS path computation.
6.1.2. Strict Explicit Path and Loose Path
During path computation, the PCE architecture and BRPC algorithm During path computation, the PCE architecture and BRPC algorithm
allow operators to specify if the resultant LSP must follow a strict allow operators to specify if the resultant LSP must follow a strict
or a loose path. By explicitly specify the path, the operator or a loose path. By explicitly specify the path, the operator
request a strict explicit path which must pass through one or many request a strict explicit path which must pass through one or many
LSR. If this behaviour is well define and appropriate for inter-area, LSR. If this behaviour is well define and appropriate for inter-area,
it implies some topology discovery for inter-AS. So, this feature it implies some topology discovery for inter-AS. So, this feature
when the operator owns several ASs (and so, knows the topology of when the operator owns several ASs (and so, knows the topology of
its ASs) or restricts to the well-known ASBR to avoid topology its ASs) or restricts to the well-known ASBR to avoid topology
discovery between operators. The loose path, even if it does not discovery between operators. The loose path, even if it does not
allow granular specification of the path, protects topology allow granular specification of the path, protects topology
disclosure as it not obligatory for the operator to disclose disclosure as it not obligatory for the operator to disclose
information about its networks. information about its networks.
5.1.3. AS Inclusion and Exclusion 6.1.3. AS Inclusion and Exclusion
Like explicit and loose path, [RFC5441] allows to specify inclusion Like explicit and loose path, [RFC5441] allows to specify inclusion
or exclusion of respectively an AS or and ASBR. Using this method, or exclusion of respectively an AS or an ASBR. Using this method,
an operator might decide if an AS must be include or exclude from an operator might decide if an AS must be include or exclude from
the inter-AS path computation. Exclusion and/or inclusion could also the inter-AS path computation. Exclusion and/or inclusion could also
be specified at any step in the LSP path computation process by a PCE be specified at any step in the LSP path computation process by a PCE
(within the BRPC algorithm) but the best practice would be to specify (within the BRPC algorithm) but the best practice would be to specify
them at the edge. In opposition to the strict and loose path, AS them at the edge. In opposition to the strict and loose path, AS
inclusion or exclusion doesn't impose topology disclosure as ASs are inclusion or exclusion doesn't impose topology disclosure as ASs are
public entity as well as their interconnection. public entity as well as their interconnection.
5.2 Inter-AS Bandwidth Guarantees 6.2 Inter-AS Bandwidth Guarantees
Many operators with multi-AS domains will have deployed MPLS-TE Many operators with multi-AS domains will have deployed MPLS-TE
Diffserv either across their entire network or at the domain DiffServ either across their entire network or at the domain
edges on CE-PE links. In situations where strict QOS bounds are edges on CE-PE links. In situations where strict QOS bounds are
required, admission control inside the network may also be required. required, admission control inside the network may also be required.
When the propagation delay can be bounded, the performance targets, When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay may be guaranteed by providing such as maximum one-way transit delay may be guaranteed by providing
bandwidth guarantees along the Diffserv-enabled path. bandwidth guarantees along the DiffServ-enabled path.
One typical example of this requirement is to provide bandwidth One typical example of this requirement is to provide bandwidth
guarantees over an end-to-end path for VoIP traffic classified as EF guarantees over an end-to-end path for VoIP traffic classified as EF
(Expedited Forwarding) class in a Diffserv-enabled (Expedited Forwarding) class in a Diffserv-enabled
network. In the case where the EF path is extended across multiple network. In the case where the EF path is extended across multiple
ASs, inter-AS bandwidth guarantee would be required. ASs, inter-AS bandwidth guarantee would be required.
Another case for inter-AS bandwidth guarantee is the requirement for Another case for inter-AS bandwidth guarantee is the requirement for
guaranteeing a certain amount of transit bandwidth across one or guaranteeing a certain amount of transit bandwidth across one or
multiple ASs. multiple ASs.
5.3 Inter-AS Recovery 6.3 Inter-AS Recovery
During path computation, a PCCReq may contains backup LSP During path computation, a PCC request may contain backup LSP
requirements in order to setup in the same time the primary and requirements in order to setup in the same time the primary and
backup LSPs. It is also possible to request a backup LSP for a group backup LSPs. It is also possible to request a backup LSP for a group
of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So, of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So,
the PCE could be used to trigger computation of backup tunnels in the PCE could be used to trigger computation of backup tunnels in
order to protect Inter-AS connectivity. Inter-AS recovery order to protect Inter-AS connectivity. Inter-AS recovery
requirements needs not only PCE protection and redundancy but also requirements needs not only PCE protection and redundancy but also
LSP tunnels protection through FRR mechanisms. Inter-AS PCE LSP tunnels protection through FRR mechanisms. Inter-AS PCE
computation must support the FRR mechanisms and the patch computation computation must support the FRR mechanisms and the patch computation
for backup tunnels for protection and fast recovery. for backup tunnels for protection and fast recovery.
5.4 Inter-AS PCE Peering Policies 6.4 Inter-AS PCE Peering Policies
Like BGP peering policies, inter-AS PCE peering policies is a Like BGP peering policies, inter-AS PCE peering policies is a
requirement for operator. In inter-AS BRPC process, PCE must requirement for operator. In inter-AS BRPC process, PCE must
cooperate in order to compute the end-to-end LSP. So, the AS path cooperate in order to compute the end-to-end LSP. So, the AS path
must not only follow technical constraints e.g. bandwidth must not only follow technical constraints e.g. bandwidth
availability, but also policies define by the operator. availability, but also policies define by the operator.
Typically PCE interconnections at an AS level must follow contract Typically PCE interconnections at an AS level must follow contract
obligations, also known as peering agreements. The PCE peering obligations, also known as peering agreements. The PCE peering
policies are the result of the contract negotiation and govern policies are the result of the contract negotiation and govern
the relation between the different PCE. the relation between the different PCE.
6. Multi-domain PCE Deployment Options 7. Multi-domain PCE Deployment Options
The PCE provides the architecture and mechanisms to compute The PCE provides the architecture and mechanisms to compute
inter-area and inter-AS LSPs. The objective of this document is not inter-area and inter-AS LSPs. The objective of this document is not
to reprint the techniques and mechanisms available, but to highlight to reprint the techniques and mechanisms available, but to highlight
their existence and reference the relevant documents that introduce their existence and reference the relevant documents that introduce
and describe the techniques and mechanisms necessary for computing and describe the techniques and mechanisms necessary for computing
inter-area and inter-AS LSP based services. inter-area and inter-AS LSP based services.
An area or AS may contain multiple PCEs: An area or AS may contain multiple PCEs:
skipping to change at page 10, line 38 skipping to change at page 14, line 44
between multiple PCEs, each responsible for its own domain. between multiple PCEs, each responsible for its own domain.
Techniques for inter-domain path computation are described in Techniques for inter-domain path computation are described in
[RFC5152] and [RFC5441], both techniques assume that the sequence of [RFC5152] and [RFC5441], both techniques assume that the sequence of
domains to be crossed from source to destination is well known. In domains to be crossed from source to destination is well known. In
the event that the sequence of domains is not well known, [H-PCE] the event that the sequence of domains is not well known, [H-PCE]
might be used. The sequence could also be retrieve locally from might be used. The sequence could also be retrieve locally from
information previously stored in the PCE database (preferably in information previously stored in the PCE database (preferably in
the TED) by OSS management or other protocols. the TED) by OSS management or other protocols.
6.1 Overview of Techniques 7.1 Traffic Engineering Database
6.2 Traffic Engineering Database
TEDs are automatically populated by the IGP-TE like IS-IS-TE or TEDs are automatically populated by the IGP-TE like IS-IS-TE or
OSPF-TE. However, no information related to AS path are provided OSPF-TE. However, no information related to AS path are provided
by such IGP-TE. It could be helpful for BRPC algorithm as AS path by such IGP-TE. It could be helpful for BRPC algorithm as AS path
helper, to populate a TED with suitable information regarding helper, to populate a TED with suitable information regarding
inter-AS connectivity. Such information could be obtain from inter-AS connectivity. Such information could be obtain from
various sources, such as BGP protocol, peering policies, OSS of the various sources, such as BGP protocol, peering policies, OSS of the
operator or from neighbor PCE. In any case, no topology disclosure operator or from neighbor PCE. In any case, no topology disclosure
must be impose in order to provide such information. must be impose in order to provide such information.
In particular, for both inter-area and inter-AS, the TED must be In particular, for both inter-area and inter-AS, the TED must be
populated with all boundary node information suitable to populated with all boundary node information suitable to
establish PCEP protocol with the next PCE in the path. establish PCEP protocol with the next PCE in the path.
6.3 Provisioning Techniques 7.2 Provisioning Techniques
As PCE algorithms rely on information contained in the TED, it As PCE algorithms rely on information contained in the TED, it
is possible to populate TED information by means of provisioning. In is possible to populate TED information by means of provisioning. In
this case, the operator must regularly update and store all suitable this case, the operator must regularly update and store all suitable
information in the TED in order for the PCE to correctly compute LSP. information in the TED in order for the PCE to correctly compute LSP.
Such information range from policies (e.g. avoid this LSR, or use Such information range from policies (e.g. avoid this LSR, or use
this ASBR for a specific IP prefix) up to topology information (e.g. this ASBR for a specific IP prefix) up to topology information (e.g.
AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s
are reserved for EF traffic). Operators may choose the type and are reserved for EF traffic). Operators may choose the type and
amount of information they can use to manage their traffic engineered amount of information they can use to manage their traffic engineered
network. network.
However, some LSPs might be provisioned to link ASs or areas. In this However, some LSPs might be provisioned to link ASs or areas. In this
case, these LSP must be announced by the IGP-TE in order to case, these LSP must be announced by the IGP-TE in order to
automatically fulfill the TED. automatically populate the TED.
6.4 Pre-Planning and Management-Based Solutions 7.3 Pre-Planning and Management-Based Solutions
Offline path computation is performed ahead of time, before the LSP Offline path computation is performed ahead of time, before the LSP
setup is requested. That means that it is requested by, or performed setup is requested. That means that it is requested by, or performed
as part of, a management application. This model can be seen in as part of, a management application. This model can be seen in
Section 5.5 of [RFC4655]. Section 5.5 of [RFC4655].
The offline model is particularly appropriate to long-lived LSPs The offline model is particularly appropriate to long-lived LSPs
(such as those present in a transport network) or for planned (such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning. normally a feature of LSP provisioning.
skipping to change at page 11, line 44 skipping to change at page 15, line 48
This model may also be used where the network operator wishes to This model may also be used where the network operator wishes to
retain full manual control of the placement of LSPs, using the PCE retain full manual control of the placement of LSPs, using the PCE
only as a computation tool to assist the operator, not as part of an only as a computation tool to assist the operator, not as part of an
automated network. automated network.
The management based solutions could also be used in conjunction The management based solutions could also be used in conjunction
with the BRPC algorithm. Operator just computes the AS-Path as with the BRPC algorithm. Operator just computes the AS-Path as
parameter for the inter-AS path computation request and let each parameter for the inter-AS path computation request and let each
PCE along the AS path compute the LSP part on its own domain. PCE along the AS path compute the LSP part on its own domain.
6.5 Per-Domain Computation 7.4 Per-Domain Computation
[RFC5152] define the mechanism to compute per-domain path and must be
used in that condition. Otherwise, BRPC [RFC5441] will be used.
6.6 Cooperative PCEs [RFC5152] defines the mechanism to compute per-domain path and must
be used in that condition. Otherwise, BRPC [RFC5441] will be used.
7.5 Cooperative PCEs
When PCE cooperate to compute an inter-area or inter-AS LSP, both When PCE cooperate to compute an inter-area or inter-AS LSP, both
[RFC5152] and [RFC5441] could be used. [RFC5152] and [RFC5441] could be used.
6.7 Hierarchical PCEs 7.6 Hierarchical PCEs
The [H-PCE] draft defines how a hierarchy of PCEs may be used. An The [H-PCE] draft defines how a hierarchy of PCEs may be used. An
operator must define a parent PCE and each child PCE. A parent PCE operator must define a parent PCE and each child PCE. A parent PCE
can be announced in the other areas or ASs in order for the parent can be announced in the other areas or ASs in order for the parent
PCE to contact remote child PCEs. Reciprocally, childs PCEs are PCE to contact remote child PCEs. Reciprocally, child PCEs are
announced in remote areas or ASs in order to be contacted by a announced in remote areas or ASs in order to be contacted by a
remote parent PCE. Parent and each child PCE could also be remote parent PCE. Parent and each child PCE could also be
provisioned in the TED if they are not announced. provisioned in the TED if they are not announced.
7. Domain Topologies 8. Domain Confidentiality
7.1 Selecting Domain Paths
7.2 Multi-Homed Domains
7.3 Domain Meshes
Very frequently network domains are composed by dozens or hundreds of
network elements. These network elements are usually interconnected
between them in a partial-mesh fashion, to provide survivability
against dual failures, and to benefit from the traffic engineering
capabilities from MPLS and GMPLS protocols. A typical node degree
ranges from 3 to 10 (4-5 is quite common), being the node degree the
number of neighbors per node.
Networks are sometimes divided into domains. Some reasons for it
range from manageability to separation into vendor-specific domains.
The size of the domain will be usually limited by control plane, but
it can also be stated by arbitrary design constraints.
7.4 Route Diversity
Whenever an specific connectivity service is required to have 1+1
protection feature, two completely disjoint paths must be
established on an end to end fashion. In a multi-domain environment
without, this can be accomplished ither by selecting domain
diversity, or by ensuring divere connection within a domain. In order
to compute the route diversity, it could be helpful to have SRLG
information in the domains.
7.5 Synchronized Path Computations
In some scenarios, it would be beneficial for the operator to rely on
the capability of the PCE to perform synchronized path computation.
A non comprehensive list of such cases could be the following:
o Route diversity: computation of two disjoint paths from a source to Confidentiality typically applies to inter-provider (inter-AS) PCE
a destination (as drafted in the previous section). communication. Where the TE LSP crosses multiple domains (ASes or
areas), the path may be computed by multiple PCEs that cooperate
together. With each local PCE responsible for computing a segment
of the path. However, in some cases (e.g., when ASes are
administered by separate Service Providers), it would break
confidentiality rules for a PCE to supply a path segment to a
PCE in another domain, thus disclosing AS-internal or area
topology information.
o Synchronous restoration: joint computation of a set of alternative 8.1 Loose Hops
paths for a set of affected LSPs as a consequence of a failure
event. Note that in this case, the requests will potentially
involve different source-destination pairs. In this scenario, the
different path computation requests may arrive at different time
stamps.
o Batch provisioning: It is common that the operator sends a set of A method for preserving the confidentiality of the path segment is
LSPs requests together, e.g in a daily of weekly basis, mainly in for the PCE to return a path containing a loose hop in place of the
case of long lived LSPs. In order to optimize the resource usage, segment that must be kept confidential. The concept of loose and
a synchronized path computation is needed. strict hops for the route of a TE LSP is described in [RFC3209].
o Network optimization: After some time of operation, the [RFC5440] supports the use of paths with loose hops, and it is a
distribution of the established LSP paths results in a non optimal local policy decision at a PCE whether it returns a full explicit
use of resources. Also, inter-domain policies/agreements may have path with strict hops or uses loose hops. A path computation
been changed. In such cases, a full (or partial) network planning request may request an explicit path with strict hops, or
action regarding the interdomain connections will be triggered. may allow loose hops as detailed in [RFC5440].
This will involve the request of potentially a big amount of
connections.
8. Domain Confidentiality 8.2 Confidential Path Segments and Path Keys
8.1 Loose Hops [RFC5520] defines the concept and mechanism of Path-Key. A Path-Key
is a token that replaces the path segment information in an explicit
route. The Path-Key allows the explicit route enformation to be
encoded and in the PCEP ([RFC5440]) messages exchanged between the
PCE and PCC.
8.2 Confidential Path Segments and Path Keys This Path-Key technique allows explicit route information to used
for end-to-end path computation, without disclosing internal topology
information between domains.
9. Point-to-Multipoint 9. Point-to-Multipoint
For the Point-to-Multipoint application scenarios for MPLS-TE LSP, For the Point-to-Multipoint application scenarios for MPLS-TE LSP,
the complexity of domain sequences, domain policies, choice and the complexity of domain sequences, domain policies, choice and
number of domain interconnects is magnified comparing to number of domain interconnects is magnified comparing to
P2P path computations. Also as the size of the network grows, P2P path computations. Also as the size of the network grows,
the number of leaves and branches increase and it in turn puts the the number of leaves and branches increase and it in turn puts the
scalability of the path computation and optimization into a bigger scalability of the path computation and optimization into a bigger
issue. A solution for the point-to-multipoint path computations may issue. A solution for the point-to-multipoint path computations may
skipping to change at page 14, line 46 skipping to change at page 18, line 14
connection controller, sending a response back at the end of connection controller, sending a response back at the end of
computation. computation.
When computing an end-to-end connection, the route may be computed by When computing an end-to-end connection, the route may be computed by
a single RC or multiple RCs in a collaborative manner and the two a single RC or multiple RCs in a collaborative manner and the two
scenarios can be considered a centralized remote route query model scenarios can be considered a centralized remote route query model
and distributed remote route query model. RCs in an ASON environment and distributed remote route query model. RCs in an ASON environment
can also use the hierarchical PCE [H-PCE] model to fully match the can also use the hierarchical PCE [H-PCE] model to fully match the
ASON hierarchical routing model. ASON hierarchical routing model.
11. Security 11. Manageability Considerations
11.1. Policy Control
11.1.1 Inter-AS PCE Peering Policy Controls
Each PCE cooperating with another PCE in a neighboring AS will need
to request or enforce policies applicable to the sender of the
request.
Parameters that are subject to policy include bandwidth, This document does not describe any specific protocol,
setup/holding priority, Fast Reroute request, Differentiated Services protocol extensions, or protocol usage, therefore no manageability
Traffic Engineering (DS-TE) Class Type (CT), and others as specified considerations need to be discussed here.
in Section 5.2.2.1 of [RFC4216].
11.2. Confidentiality 12. Security Considerations
11.3. Denial of Service Attacks This document is informational and does not describe any new
specific protocol, protocol extensions, or protocol usage. As such,
it introduces no new security concerns.
12. IANA Considerations 13. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
13. References 13. References
13.1. Normative References 14.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol "Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009. (PCEP)", RFC 5440, March 2009.
13.2. Informative References 14.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005. 2005.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
skipping to change at page 16, line 19 skipping to change at page 19, line 31
[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.
[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", domain Traffic Engineering Label Switched Paths",
RFC5441, April 2009. RFC5441, April 2009.
[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.
[RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,
Zhao, Q., King, D., "Extensions to the Path Computation
Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC6006, September 2010.
[RFC6007] Nishioka, I., King, D., "Use of the Synchronization
VECtor (SVEC) List for Synchronized Dependent Path
Computations", RFC6007, September 2010.
[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 Requirements for the Automatically Switched and Requirements for the Automatically Switched
Optical Network (ASON). Optical Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing
architecture and requirements for remote route query. architecture and requirements for remote route query.
[PCEP-P2MP-INTER-DOMAIN] Ali Z., Zhao, Q., King, D., "PCE-based
Computation Procedure To Compute Shortest Constrained
P2MP Inter-domain Traffic Engineering Label Switched
Paths",
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt,
work in progress, Januaury, 2011.
[H-PCE] King, D. and A. Farrel, "The Application of the Path [H-PCE] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS & GMPLS", July of a Sequence of Domains in MPLS & GMPLS", July
2010. 2010.
[RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z., 15. Acknowledgements
Zhao, Q., King, D., "Extensions to the Path Computation
Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC6006, September 2010.
[PCEP-P2MP-INTER-DOMAIN] Ali Z., Zhao, Q., King, D., "PCE-based
Computation Procedure To Compute Shortest Constrained P2MP
Inter-domain Traffic Engineering Label Switched Paths",
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt,
work in progress, Januaury, 2011.
11. Acknowledgements
The author would like to thank Adrian Farrel for his review and The author would like to thank Adrian Farrel for his review and
Meral Shirazipour for his comments. Meral Shirazipour for his comments.
12. Author's Address 16. Author's Address
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
UK UK
Email: daniel@olddog.co.uk Email: daniel@olddog.co.uk
Julien Meuric Julien Meuric
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
 End of changes. 67 change blocks. 
194 lines changed or deleted 383 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/