PCE Working Group D. King
Internet Draft Old Dog Consulting
Intended status: Informational
Created: March 1, 2010
Expires: September 1, 2010
Applicability of the Path Computation Element to Inter-Area and
Inter-AS MPLS and GMPLS Traffic Engineering
draft-king-pce-inter-area-as-applicability-00
Abstract
The Path Computation Element (PCE) may be used for computing services
that traverse multi-area and multi-AS Multiprotocol Label Switching
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.
This document examines the applicability of the PCE architecture,
protocols, and protocol extensions for computing multi-area and
multi-AS paths in MPLS and GMPLS networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 1, 2010.
King. Expires September 1, 2010 [Page 1]
Internet-Draft March 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This Internet-Draft will expire on September 1, 2010.
Table of Contents
1. Introduction..................................................
1.1. Domains.....................................................
1.3. Path Computation............................................
1.3. Traffic Engineering Aggregation and Abstraction.............
1.4. Traffic Engineered Label Switched Paths.....................
1.5. Inter-area and Inter AS Connectivity Discovery..............
2. Terminology...................................................
3. Issues and Considerations.....................................
3.1 Multi-homed domains.......................................
3.2 Domain meshes.............................................
3.4 Destination location......................................
4. Applicability of the PCE to Inter-area Traffic Engineering....
4.1. Inter-area Routing.......................................
4.1.1. Area Inclusion and Exclusion...........................
4.1.2. Strict Explicit Path and Loose Path....................
4.1.3. Inter-Area Diverse Path Computation....................
4.2. Control and Recording of Area Crossing...................
4.3. Inter-Area Policies .....................................
4.4. Loop Avoidance ..........................................
5. Applicability of the PCE to Inter-AS Traffic Engineering......
5.1. Inter-AS Routing.........................................
4.1.1. AS Inclusion and Exclusion.............................
4.1.2. Strict Explicit Path and Loose Path....................
5.1.3. AS Inclusion and Exclusion.............................
5.2. Inter-AS Bandwidth Guarantees............................
5.3. Inter-AS Recovery........................................
5.4. Inter-AS PCE Peering Policies............................
6. Multi-Domain PCE Deployment...................................
6.1 Overview of Techniques....................................
6.2 Traffic Engineering Database..............................
6.3 Provisioning Techniques...................................
King. Expires September 1, 2010 [Page 2]
Internet-Draft March 2010
6.4 Pre-Planning and Management-Based Solutions...............
6.5 Per-Domain Computation....................................
6.6 Cooperative PCEs..........................................
6.7 Hierarchical PCEs .......................................
7. Domain Topologies.............................................
7.1 Selecting Domain Paths....................................
7.2 Multi-Homed Domains.......................................
7.3 Domain Meshes.............................................
7.4 Route Diversity...........................................
7.5 Synchronized Path Computations............................
8. Domain Confidentiality........................................
8.1 Loose Hops................................................
8.2 Confidential Path Segments and Path Keys..................
9. Point-to-Multipoint...........................................
10. Optical Domains..............................................
10.1. Overview of Optical Domains................................
11.1. Policy Control.............................................
11.1.1 Inter-AS PCE Peering Policy Controls......................
12. IANA Considerations..........................................
13. References...................................................
13.1. Normative References.......................................
13.2. Informative References.....................................
14. Acknowledgements.............................................
15. Author's Address.............................................
1. Introduction
Computing paths across large multi-domain environments may
require special computational components and cooperation between
entities in different domains capable of complex path computation.
The Path Computation Element (PCE) [RFC4655] provides an architecture
and functional components to address this problem space.
Computing optimal routes for LSPs that cross domains in MPLS-TE and
GMPLS networks presents a problem because no single point of path
computation is aware of all of the links and resources in each
domain. A solution may be achieved using the PCE architecture
[RFC4655].
A domain can be defined as a separate administrative, geographic, or
switching environment within the network. A domain may be further
defined as a zone of routing or computational ability. Under these
definitions a domain might be categorized as an Antonymous System
(AS) or an Interior Gateway Protocol (IGP) area [RFC4726] and
[RFC4655].
King. Expires September 1, 2010 [Page 3]
Internet-Draft March 2010
A PCE may be used to compute end-to-end paths across multi-domain
environments using a per-domain path computation technique [RFC5152].
The backward recursive path computation (BRPC) mechanism [RFC5441].
Both per-domain and BRPC techniques assume that the sequence of
domains to be crossed from source to destination is well known.
In more advanced deployments (including multi-area and multi-AS
environments) the sequence of domains may not be known in advance
and the choice of domains in the end-to-end domain sequence might be
critical to the determination of an optimal end-to-end path. In
this case the use of the Hierarchical PCE [H-PCE] architecture and
mechanisms may be used to discovery and select the optimal
end-to-end domain sequence.
This document examines the applicability and describes the processes
and procedures available when using the PCE architecture, protocols
and protocol extensions for computing inter-area and inter-AS MPLS
Traffic Engineered paths.
1.1 Domains
For the purposes of this document, a domain is considered to be a
collection of network elements within an area or AS that has a common
sphere of address management or path computational responsibility.
Wholly or partially overlapping domains are not within the scope of
this document.
In the context of GMPLS, a particularly important example of a domain
is the Automatically Switched Optical Network (ASON) subnetwork
[G-8080]. In this case, computation of an end-to-end path requires
the selection of nodes and links within a parent domain where some
nodes may, in fact, be subnetworks. Furthermore, a domain might be an
ASON routing area [G-7715]. A PCE may perform the path computation
function of an ASON routing controller as described in [G-7715-2].
It is assumed that a PCE architecture should be applied to small
inter-domain topologies and not solving route computation issues
across large groups of domains, I.E. the entire Internet.
1.2 Path Computation
For the purpose of this document it is assumed that the
path computation is the sole responsibility of the PCE as per the
architecture defined in [RFC4655]. When a path is required the Path
Computation Client (PCC) will send a request to the PCE. The PCE will
apply the required constraints and compute a path and return a
response to the PCC. In the context of this document it maybe
necessary for the PCE to co-operate with other PCEs in adjacent
domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE
(as per [H-PCE]).
King. Expires September 1, 2010 [Page 4]
Internet-Draft March 2010
It is entirely feasible that an operator could compute a path across
multiple domains without the use of a PCE if the relevant domain
information is available to the network planner or network management
platform. The definition of what relevant information is required to
perform this network planning operation and how that information is
discovered and applied is outside the scope of this document.
1.3 Traffic Engineering Aggregation and Abstraction
Networks are often constructed from multiple areas or ASs that are
interconnected via multiple interconnect points. To maintain
network confidentiality and scalability TE properties of each area
and AS are not generally advertized outside each specific area or AS.
TE aggregation or abstraction provide mechanism to hide information
but may cause failed path setups or the selection of suboptimal
end-to-end paths [RFC4726]. The aggregation process may also have
significant scaling issues for networks with many possible routes
and multiple TE metrics. Flooding TE information breaks
confidentiality and does not scale in the routing protocol.
The PCE architecture and associated mechanisms provide a solution
to avoid the use of TE aggregation and abstraction.
1.4 Traffic Engineered Label Switched Paths
This document highlights the PCE techniques and mechanisms that exist
for establishing TE packet and optical LSPs across multiple areas
(inter-area TE LSP) and ASs (inter-AS TE LSP). In this context and
within the remainder of this document, we consider all LSPs to be
constraint-based and traffic engineered.
Three signaling options are defined for setting up an inter-area or
inter-AS LSP [RFC4726]:
- Contiguous LSP
- Stitched LSP
- Nested LSP
All three signaling methods are applicable to the architectures and
procedures discussed in this document.
1.5 Inter-area and Inter AS Connectivity Discovery
When using a PCE-based approach for inter-area and inter-AS path
computation, a PCC in one area or AS may need to learn information
related to inter-AS capable PCEs located in other ASs. The PCE
discovery mechanism defined in [RFC5088] and [RFC5089] allow
the discovery of PCEs and disclosure of information related to
inter-area and inter-AS capable PCEs across area and AS boundaries.
King. Expires September 1, 2010 [Page 5]
Internet-Draft March 2010
2. Terminology
Terminology used in this document.
ABR: IGP Area Border Router, a router that is attached to more than
one IGP area.
Inter-area TE LSP: A TE LSP whose path transits through two or more
IGP areas.
Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or
more ASs or sub-ASs (BGP confederations
LSP: Traffic Engineered Label Switched Path.
LSR: Label Switching Router.
TED: Traffic Engineering Database, which contains the topology and
resource information of the domain. The TED may be fed by Interior
Gateway Protocol (IGP) extensions or potentially by other means.
This document also uses the terminology defined in [RFC4655] and
[RFC5440].
3. Issues and Considerations
TBD.
3.1 Multi-homed domains
3.2 Domain meshes
3.4 Destination location
4. Applicability of the PCE to Inter-area Traffic Engineering
As networks increase in size and complexity it may be required to
introduce scaling methods to reduce the amount information flooded
within the network and make the network more manageable. An IGP
hierarchy is designed to improve IGP scalability by dividing the
IGP domain into areas and limiting the flooding scope of topology
information to within area boundaries. This restricts visibility of
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
compute a path across area boundaries.
King. Expires September 1, 2010 [Page 6]
Internet-Draft March 2010
Per-domain path computation [RFC5152] exists to provide a method of
inter-area path computation. The per-domain solution is based on
loose hop routing with an Explicit Route Object (ERO) expansion on
each Area Border Router (ABR). This allows an LSP to be established
using a constrained path, however at least two issues exist:
- This method does not guarantee an optimal constrained path
- The method may require several crankback signaling messages
increasing signaling traffic and delaying the LSP setup
The PCE-based architecture [RFC4655] is designed to solve inter-area
path computation problems. The issue of limited topology visibility
is resolved by introducing path computation entities that are able to
cooperate in order to establish LSPs with source and destinations
located in different areas.
4.1. Inter-area Routing
4.1.1. Area Inclusion and Exclusion
4.1.2. Strict Explicit Path and Loose Path
4.1.3. Inter-Area Diverse Path Computation
4.2. Control and Recording of Area Crossing
4.3. Inter-Area Policies
4.4. Loop Avoidance
5. Applicability of the PCE to Inter-AS Traffic Engineering
As discussed in section 4 (Applicability of the PCE to Inter-area
Traffic Engineering) it is necessary to divide the network into
smaller administrative domains, or ASes. If an LSR within an AS needs
to compute a path across an AS boundary it must also use an inter-AS
computation technique. RFC5152] defines mechanisms for the
computation of inter-domain TE LSPs using network elements along the
signaling paths to compute per-domain constrained path segments.
The PCE was designed to be capable of computing MPLS and GMPLS paths
across AS boundaries. This section outlines the features of a
PCE-enabled solution for computing inter-AS paths.
5.1 Inter-AS Routing
5.1.1. AS Inclusion and Exclusion
King. Expires September 1, 2010 [Page 7]
Internet-Draft March 2010
5.1.2. Strict Explicit Path and Loose Path
5.1.3. AS Inclusion and Exclusion
5.2 Inter-AS Bandwidth Guarantees
Many operators with multi-AS domains will have deployed MPLS-TE
Diffserv either across their entire network or at the domain
edges on CE-PE links. In situations where strict QOS bounds are
required, admission control inside the network may also be required.
When the propagation delay can be bounded, the performance targets,
such as maximum one-way transit delay may be guaranteed by providing
bandwidth guarantees along the Diffserv-enabled path.
One typical example of this requirement is to provide bandwidth
guarantees over an end-to-end path for VoIP traffic classified as EF
(Expedited Forwarding) class in a Diffserv-enabled
network. In the case where the EF path is extended across multiple
ASes, inter-AS bandwidth guarantee would be required.
Another case for inter-AS bandwidth guarantee is the requirement for
guaranteeing a certain amount of transit bandwidth across one or
multiple ASes.
5.3 Inter-AS Recovery
5.4 Inter-AS PCE Peering Policies
6. Mult-domain PCE Deployment Options
The PCE provides the architecture and mechanisms to compute
inter-area and inter-AS LSPs. The objective of this document is not
to reprint the techniques and mechanisms available, but to highlight
their existence and reference the relevant documents that introduce
and describe the techniques and mechanisms necessary for computing
inter-area and inter-AS LSP based services.
An area or AS may contain multiple PCEs:
- The path computation load may be balanced among a set of PCEs to
improve scalability.
- For the purpose of redundancy, primary and backup PCEs may be used.
- PCEs may have distinct path computation capabilities (P2P or P2MP).
Discovery of PCEs and capabilities per area or AS is defined in in
[RFC5088] and [RFC5089].
King. Expires September 1, 2010 [Page 8]
Internet-Draft March 2010
Each PCE per domain can be deployed in a centralized or distributed
architecture, the latter model having local visibility and
collaborating in a distributed fashion to compute a path across the
domain. Each PCE may collect topology and TE information from the
same sources as the LSR, such as the IGP TED.
When the PCC sends a path computation request to the PCE, the PCE
will compute the path across a domain based on the required
constraints. The PCE will generate the full set of strict hops from
source to destination. This information, encoded as an ERO, is then
sent back to the PCC that requested the path. In the event that a
path request from a PCC contains source and destination nodes that
are located in different domains the PCE is required to co-operate
between multiple PCEs, each responsible for its own domain.
Techniques for inter-domain path computation are described in
[RFC5152] and [RFC5441], both techniques assume that the sequence of
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]
might be used.
6.1 Overview of Techniques
6.2 Traffic Engineering Database
6.3 Provisioning Techniques
6.4 Pre-Planning and Management-Based Solutions
Offline path computation is performed ahead of time, before the LSP
setup is requested. That means that it is requested by, or performed
as part of, a management application. This model can be seen in
Section 5.5 of [RFC4655].
The offline model is particularly appropriate to long-lived LSPs
(such as those present in a transport network) or for planned
responses to network failures. In these scenarios, more planning is
normally a feature of LSP provisioning.
This model may also be used where the network operator wishes to
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
automated network.
6.5 Per-Domain Computation
6.6 Cooperative PCEs
6.7 Hierarchical PCEs
King. Expires September 1, 2010 [Page 9]
Internet-Draft March 2010
7. Domain Topologies
TBD.
7.1 Selecting Domain Paths
7.2 Multi-Homed Domains
7.3 Domain Meshes
7.4 Route Diversity
7.5 Synchronized Path Computations
8. Domain Confidentiality
TBD
8.1 Loose Hops
8.2 Confidential Path Segments and Path Keys
9. Point-to-Multipoint
TBD.
10. Optical Domains
TBD.
10.1. Overview of Optical Domains
11. Security
TBD
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.
King. Expires September 1, 2010 [Page 10]
Internet-Draft March 2010
Parameters that are subject to policy include bandwidth,
setup/holding priority, Fast Reroute request, Differentiated Services
Traffic Engineering (DS-TE) Class Type (CT), and others as specified
in Section 5.2.2.1 of [RFC4216].
11.2. Confidentiality
11.3. Denial of Service Attacks
12. IANA Considerations
This document makes no requests for IANA action.
13. References
13.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow,
A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux,
"Path Computation Element (PCE) Communication Protocol
(PCEP)", RFC 5440, March 2009.
13.2. Informative References
[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
for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
Path Computation Method for Establishing Inter-Domain
Traffic Engineering (TE) Label Switched Paths (LSPs)",
RFC 5152, February 2008.
King. Expires September 1, 2010 [Page 11]
Internet-Draft March 2010
[RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths",
RFC5441, 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.
[H-PCE] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS & GMPLS", December
2009.
11. Acknowledgements
The author would like to thank Adrian Farrel for his review and
comments.
12. Author's Address
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
King. Expires September 1, 2010 [Page 12]
Internet-Draft March 2010