Request for Comments: 4655 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
J. Ash
AT&T
August 2006
A Path Computation Element (PCE)-Based Architecture
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Constraint-based path computation is a fundamental building block for
traffic engineering systems such as Multiprotocol Label Switching
(MPLS) and Generalized Multiprotocol Label Switching (GMPLS)
networks. Path computation in large, multi-domain, multi-region, or
multi-layer networks is complex and may require special computational
components and cooperation between the different network domains.
This document specifies the architecture for a Path Computation
Element (PCE)-based model to address this problem space. This
document does not attempt to provide a detailed description of all
the architectural components, but rather it describes a set of
building blocks for the PCE architecture from which solutions may be
constructed.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility .........................................7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............7
4.4. Node Outside the Routing Domain ............................8
4.5. Network Element Lacks Control Plane or Routing Capability ..8
4.6. Backup Path Computation for Bandwidth Protection ...........8
4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ......................................9
4.9. Non-Motivations ...........................................10
4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................11
5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE
Communication .............................................14
5.5. Management-Based PCE Usage ................................15
5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model .............................16
6.2. Distributed Computation Model .............................17
6.3. Synchronization ...........................................17
6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ...................................22
6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................25
6.10. Confidentiality ..........................................25
6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................28
6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ......................31
8. Evaluation Metrics .............................................32
9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring .........................34
9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional
Components ................................................35
9.6. Impact on Network Operation ...............................36
9.7. Other Considerations ......................................36
10. Security Considerations .......................................37
11. Acknowledgements ..............................................37
12. Informative References ........................................38
1. Introduction
Constraint-based path computation is a fundamental building block for
traffic engineering in MPLS [RFC3209] and GMPLS [RFC3473] networks.
[RFC2702] describes requirements for traffic engineering in MPLS
networks, while [RFC4105] and [RFC4216] describe traffic engineering
requirements in inter-area and inter-AS environments, respectively.
Path computation in large, multi-domain networks is complex and may
require special computational components and cooperation between the
elements in different domains. This document specifies the
architecture for a Path Computation Element (PCE)-based model to
address this problem space.
This document describes a set of building blocks for the PCE
architecture from which solutions may be constructed. For example,
it discusses PCE-based implementations including composite, external,
and multiple PCE path computation. Furthermore, it discusses
architectural considerations including centralized computation,
distributed computation, synchronization, PCE discovery and load
balancing, detection of PCE liveness, communication between Path
Computation Clients (PCCs) and the PCE (PCC-PCE communication) and
PCE-PCE communication, Traffic Engineering Database (TED)
synchronization, stateful and stateless PCEs, monitoring, policy and
confidentiality, and evaluation metrics.
The model of the Internet is to distribute network functionality
(e.g., routing) within the network. PCE functionality is not
intended to contradict this model and can be used to match the model
exactly, for example, when the PCE functionality coexists with each
Label Switching Router (LSR) in the network. PCE is also able to
augment functionality in the network where the Internet model cannot
supply adequate solutions, for example, where traffic engineering
information is not exchanged between network domains.
2. Terminology
CSPF: Constraint-based Shortest Path First.
LER: Label Edge Router.
LSDB: Link State Database.
LSP: Label Switched Path.
LSR: Label Switching Router.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation Element.
PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints (see
further description in Section 3).
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.
TE LSP: Traffic Engineering MPLS Label Switched Path.
3. Definitions
A Path Computation Element (PCE) is an entity that is capable of
computing a network path or route based on a network graph, and of
applying computational constraints during the computation. The PCE
entity is an application that can be located within a network node or
component, on an out-of-network server, etc. For example, a PCE
would be able to compute the path of a TE LSP by operating on the TED
and considering bandwidth and other constraints applicable to the TE
LSP service request.
A domain is any collection of network elements within a common sphere
of address management or path computation responsibility. Examples
of domains include IGP areas, Autonomous Systems (ASes), and multiple
ASes within a Service Provider network. Domains of path computation
responsibility may also exist as sub-domains of areas or ASes.
In order to fully characterize a PCE and clarify these definitions,
the following important considerations must also be examined:
1) Path computation is applicable in intra-domain, inter-domain, and
inter-layer contexts.
a. Inter-domain path computation may involve the association of
topology, routing, and policy information from multiple domains
from which relationships may be deduced in order to help in
performing path computation.
b. Inter-layer path computation refers to the use of PCE where
multiple layers are involved and when the objective is to
perform path computation at one or multiple layers while taking
into account topology and resource information at these layers.
Overlapping domains are not within the scope of this document. In
the inter-domain case, the domains may belong to a single or to
multiple Service Providers.
2) a. In "single PCE path computation", a single PCE is used to
compute a given path in a domain. There may be multiple PCEs
in a domain, but only one PCE per domain is involved in any
single path computation.
b. In "multiple PCE path computation", multiple PCEs are used to
compute a given path in a domain.
3) a. "Centralized computation model" refers to a model whereby all
paths in a domain are computed by a single, centralized PCE.
b. Conversely, "distributed computation model" refers to the
computation of paths in a domain being shared among multiple
PCEs.
Paths that span multiple domains may be computed using the
distributed model with one or more PCEs responsible for each
domain, or the centralized model by defining a domain that
encompasses all the other domains.
From these definitions, a centralized computation model inherently
uses single PCE path computation. However, a distributed
computation model could use either single PCE path computation or
multiple PCE path computations. There would be no such thing as a
centralized model that uses multiple PCEs.
4) The PCE may or may not be located at the head-end of the path.
For example, a conventional intra-domain solution is to have path
computation performed by the head-end LSR of an MPLS TE LSP; in
this case, the head-end LSR contains a PCE. But solutions also
exist where other nodes on the path must contribute to the path
computation (for example, loose hops), making them PCEs in their
own right. At the same time, the path computation may be made by
some other PCE physically distinct from the computed path.
5) The path computed by the PCE may be an "explicit path" (that is,
the full explicit path from start to destination, made of a list
of strict hops) or a "strict/loose path" (that is, a mix of strict
and loose hops comprising at least one loose hop representing the
destination), where a hop may be an abstract node such as an AS.
6) A PCE-based path computation model does not mean to be exclusive
and can be used in conjunction with other path computation models.
For instance, the path of an inter-AS TE LSP may be computed using
a PCE-based path computation model in some ASes, whereas the set
of traversed ASes may be specified by other means (not determined
by a PCE). Furthermore, different path computation models may be
used for different TE LSPs.
7) This document does not make any assumptions about the nature or
implementation of a PCE. A PCE could be implemented on a router,
an LSR, a dedicated network server, etc. Moreover, the PCE
function is orthogonal to the forwarding capability of the node on
which it is implemented.
4. Motivation for a PCE-Based Architecture
Several motivations for a PCE-based architecture (described in
Section 5) are listed below. This list is not meant to be exhaustive
and is provided for the sake of illustration.
It should be highlighted that the aim of this section is to provide
some application examples for which a PCE-based path may be suitable:
this also clearly states that such a model does not aim to replace
existing path computation models but would apply to specific existing
or future situations.
As can be seen from these examples, PCE does not replace the existing
Internet model where intelligence is distributed within the network.
Instead, it builds on this model and makes use of distributed centers
of information or computational ability. PCE should not, therefore,
necessarily be seen as a centralized, "all-seeing oracle in the sky",
but as the cooperative operation of distributed functionality used to
address specific challenges such as the computation of a shortest
inter-domain constrained path.
4.1. CPU-Intensive Path Computation
There are many situations where the computation of a path may be
highly CPU-intensive; examples of CPU-intensive path computations
include the resolution of problems such as:
- Placing a set of TE LSPs within a domain so as to optimize an
objective function (for example, minimization of the maximum link
utilization)
- Multi-criteria path computation (for example, delay and link
utilization, inclusion of switching capabilities, adaptation
features, encoding types and optical constraints within a GMPLS
optical network)
- Computation of minimal cost Point to Multipoint trees (Steiner
trees)
In these situations, it may not be possible or desirable for some
routers to perform path computation because of the constraints on
their CPUs, in which case the path computations may be off-loaded to
some other PCE(s) that may, themselves, be routers or may be
dedicated PCE servers.
4.2. Partial Visibility
There are several scenarios where the node responsible for path
computation has limited visibility of the network topology to the
destination. This limitation may occur, for instance, when an
ingress router attempts to establish a TE LSP to a destination that
lies in a separate domain, since TE information is not exchanged
across the domain boundaries. In such cases, it is possible to use
loose routes to establish the TE LSP, relying on routers at the
domain borders to establish the next piece of the path. However, it
is not possible to guarantee that the optimal (shortest) path will be
used, or even that a viable path will be discovered except, possibly,
through repeated trial and error using crankback or other signaling
extensions.
This problem of inter-domain path computation may most probably be
addressed through distributed computation with cooperation among PCEs
within each of the domains, and potentially using crankback between
the domains to dynamically resolve provisioning issues.
Alternatively, a central "all-seeing" PCE that has access to the
complete set of topology information may be used, but in this case
there are challenges of scalability (both the size of the TED and the
responsiveness of a single PCE handling requests for many domains)
and of preservation of confidentiality when the domains belong to
different Service Providers.
Note that the issues described here can be further highlighted in the
context of TE LSP reoptimization, or the establishment of multiple
diverse TE LSPs for protection or load sharing.
4.3. Absence of the TED or Use of Non-TE-Enabled IGP
The traffic engineering database (TED) may be a large drain on the
resources of a network node (such as an edge router or LER).
Maintaining the TED may require a lot of memory and may require non-
negligible CPU activity. The use of a distinct PCE may be
appropriate in such circumstances, and a separate node can be used to
establish and maintain the TED, and to make it available for path
computation.
The IGPs run within some networks are not sufficient to build a full
TED. For example, a network may run OSPF/IS-IS without the
OSPF-TE/ISIS-TE extensions, or some routers in the network may not
support the TE extensions. In these cases, in order to successfully
compute paths through the network, the TED must be constructed or
supplemented through configuration action and updated as network
resources are reserved or released. Such a TED could be distributed
to the routers that need to perform path computation or held
centrally (on a distinct node that supports PCE) for centralized
computation.
4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative
reasons (for example, a customer-edge (CE) router connected to the
provider-edge (PE) router in the context of MPLS VPN [RFC4364] and
for which it is desired to provide a CE to CE TE LSP path).
This scenario suggests a solution that does not involve doing
computation on the ingress (TE LSP head-end, CE) router, and that
does not rely on the configuration of static loose hops. In this
case, optimal shortest paths cannot be guaranteed. A solution that a
distinct PCE can help here. Note that the PCE in this case may,
itself, provide a path that includes loose hops.
4.5. Network Element Lacks Control Plane or Routing Capability
It is common in legacy optical networks for the network elements not
to have a control plane or routing capability. Such network elements
only have a data plane and a management plane, and all cross-
connections are made from the management plane. It is desirable in
this case to run the path computation on the PCE, and to send the
cross-connection commands to each node on the computed path. That
is, the PCC would be an element of the management plane, perhaps
residing in the Network Management System (NMS) or Operations Support
System (OSS).
This scenario is important for Automatically Switched Optical Network
(ASON)-capable networks and may also be used for interworking between
GMPLS-capable and GMPLS-incapable networks.
4.6. Backup Path Computation for Bandwidth Protection
A PCE can be used to compute backup paths in the context of fast
reroute protection of TE LSPs. In this model, all backup TE LSPs
protecting a given facility are computed in a coordinated manner by a
PCE. This allows complete bandwidth sharing between backup tunnels
protecting independent elements, while avoiding any extensions to TE
LSP signaling. Both centralized and distributed computation models
are applicable. In the distributed case each LSR can be a PCE to
compute the paths of backup tunnels to protect against the failure of
adjacent network links or nodes.
4.7. Multi-layer Networks
A server-layer network of one switching capability may support
multiple networks of another (more granular) switching capability.
For example, a Time-Division Multiplexing (TDM) network may provide
connectivity for client-layer networks such as IP, MPLS, or Layer 2
[MLN].
The server-layer network is unlikely to provide the same connectivity
paradigm as the client networks, so bandwidth granularity in the
server-layer network may be much coarser than in the client-layer
network. Similarly, there is likely to be a management separation
between the two networks providing independent address spaces.
Furthermore, where multiple client-layer networks make use of the
same server-layer network, those client-layer networks may have
independent policies, control parameters, address spaces, and routing
preferences.
The different client- and server-layer networks may be considered
distinct path computation regions within a PCE domain, so the PCE
architecture is useful to allow path computation from one client-
layer network region, across the server-layer network, to another
client-layer network region.
In this case, the PCEs are responsible for resolving address space
issues, handling differences in policy and control parameters, and
coordinating resources between the networks. Note that, because of
the differences in bandwidth granularity, connectivity across the
server-layer network may be provided through virtual TE links or
Forwarding Adjacencies: the PCE may offer a point of control
responsible for the decision to provision new TE links or Forwarding
Adjacencies across the server-layer network.
4.8. Path Selection Policy
A PCE may have a local policy that impacts path computation and
selection in response to a path computation request. Such policy may
act on information provided by the requesting PCC. The result of
applying such policy includes, for example, rejection of the path
computation request, or provision of a path that does not meet all of
the requested constraints. Further, the policy may support
administratively configured paths, or selection among transit
providers. Inclusion of policy within PCE may simplify the
application of policy within the path computation/selection process.
Similarly, a PCC may apply local policy to the selection of a PCE to
compute a specific path, and to the constraints that are requested.
In a PCE context, the policy may be sensitive to the type of path
that is being computed. For example, a different set of policies may
be applied for an intra-area or single-layer path than would be
provided for an inter-area or multi-layer path.
Note that synchronization of policy between PCEs or between PCCs and
PCEs may be necessary. Such issues are outside the scope of the PCE
architecture, but within scope for the PCE policy framework and
application which is described in a separate document.
4.9. Non-Motivations
4.9.1. The Whole Internet
PCE is not considered to be a solution that is applicable to the
entire Internet. That is, the applicability of PCE is limited to a
set of domains with known relationships. The scale of this
limitation is similar to the peering relationships between Service
Providers.
4.9.2. Guaranteed TE LSP Establishment
When two or more paths for TE LSPs are computed on the same set of TE
link state information, it is possible that the resultant paths will
compete for limited resources within the network. This may result in
success for only the first TE LSP to be signaled, or it might even
mean that no TE LSP can be established.
Batch processing of computation requests, back-off times, computation
of alternate paths, and crankback can help to mitigate this sort of
problem, and PCE may also improve the chances of successful TE LSP
setup. However, a single, centralized PCE is not viewed as a
solution that can guarantee TE LSP establishment since the potential
for network failures or contention for resources still exists where
the centralized TED cannot fully reflect current (i.e., real-time)
network state.
5. Overview of the PCE-Based Architecture
This section gives an overview of the architecture of the PCE model.
It needs to be read in conjunction with the details provided in the
next section to provide a full view of the flexibility of the model.
5.1. Composite PCE Node
Figure 1 below shows the components of a typical composite PCE node