draft-ietf-pce-architecture-00.txt   draft-ietf-pce-architecture-01.txt 
IETF Internet Draft PCE Working Group Adrian Farrel Network Working Group Adrian Farrel
Proposed Status: Informational Old Dog Consulting IETF Internet Draft Old Dog Consulting
Expires: September 2005 Jean-Philippe Vasseur Proposed Status: Informational Jean-Philippe Vasseur
Cisco Systems, Inc. Expires: January 2006 Cisco Systems, Inc.
Jerry Ash Jerry Ash
AT&T AT&T
March 2005
draft-ietf-pce-architecture-00.txt July 2005
draft-ietf-pce-architecture-01.txt
Path Computation Element (PCE) Architecture Path Computation Element (PCE) Architecture
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that other
may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
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
http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Abstract Abstract
Constraint-based path computation is a fundamental building block for Constraint-based path computation is a fundamental building block for
traffic engineering systems such as Multiprotocol Label Switching (MPLS) traffic engineering systems such as Multiprotocol Label Switching
and Generalized Multiprotocol Label Switching (GMPLS) networks. Path (MPLS) and Generalized Multiprotocol Label Switching (GMPLS)
computation in large, multi-domain, multi-region or multi-layer networks. Path computation in large, multi-domain, multi-region or
networks is highly complex and may require special computational multi-layer networks is highly complex and may require special
components and cooperation between the different network domains. computational components and cooperation between the different
network domains.
This document specifies the architecture for a Path Computation Element This document specifies the architecture for a Path Computation
(PCE)-based model to address this problem space. This document does not Element (PCE)-based model to address this problem space. This
attempt to provide a detailed description of all the architectural document does not attempt to provide a detailed description of all
components, but rather it describes a set of building blocks for the PCE the architectural components, but rather it describes a set of
architecture from which solutions may be constructed. building blocks for the PCE architecture from which solutions may be
constructed.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ................................................... 3
2. Conventions used in this document . . . . . . . . . . . . . . . . 3 2. Terminology .................................................... 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions .................................................... 4
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Motivation for a PCE-based Architecture ........................ 6
5. Motivation for a PCE-based Architecture . . . . . . . . . . . . . 4 4.1. CPU-intensive Path Computation/Global Optimization ....... 6
5.1. CPU-intensive Path Computation/Global Optimization . . . . . 5 4.2. Partial Visibility ....................................... 6
5.2. Partial Visibility . . . . . . . . . . . . . . . . . . . . . 5 4.3. Absence of the TED or Use of Non-TE-Enabled IGP .......... 7
5.3. Absence of the TED or Use of Non-TE-Enabled IGP . . . . . . 5 4.4. Node Outside the Routing Domain .......................... 7
5.4. Node Outside the Routing Domain . . . . . . . . . . . . . . 6 4.5. Network Element Lacks Control Plane or Routing Capability 8
5.5. Network Element Lacks Control Plan or Routing Capability . . 6 4.6. Backup Path Computation for Bandwidth Protection ......... 8
5.6. Backup Path Computation for Bandwidth Protection . . . . . . 6 4.7. Multi-Layer Networks ..................................... 8
5.7. Multi-Layer Networks . . . . . . . . . . . . . . . . . . . . 6 5. Overview of the PCE-Based Architecture ......................... 9
6. Overview of the PCE-Based Architecture . . . . . . . . . . . . . 7 5.1. Composite PCE Node ....................................... 9
6.1. Composite PCE . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. External PCE ............................................ 10
6.2. External PCE . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Multiple PCE Path Computation ........................... 11
6.3. Multiple PCE Path Computation . . . . . . . . . . . . . . . 9 5.4. Multiple PCE Path Computation with Inter-PCE Communication
6.4. Multiple PCE Path Computation with Inter-PCE Communication . 10 .............................................. 12
6.5. Areas for Standardization . . . . . . . . . . . . . . . . . 5.5. Areas for Standardization ............................... 13
7. PCE Architectural Considerations . . . . . . . . . . . . . . . . 10 6. PCE Architectural Considerations .............................. 13
7.1. Centralized Computation Model . . . . . . . . . . . . . . . 11 6.1. Centralized Computation Model ........................... 14
7.2. Distributed Computation Model . . . . . . . . . . . . . . . 11 6.2. Distributed Computation Model ........................... 14
7.3. Synchronization . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Synchronization ......................................... 14
7.4. PCE Discovery and Load Balancing . . . . . . . . . . . . . . 12 6.4. PCE Discovery and Load Balancing ........................ 15
7.5. Detecting PCE Liveness . . . . . . . . . . . . . . . . . . . 12 6.5. Detecting PCE Liveness .................................. 16
7.6. PCC-PCE & PCE-PCE Communication . . . . . . . . . . . . . . 12 6.6. PCC-PCE & PCE-PCE Communication ......................... 16
7.7. PCE TED Synchronization . . . . . . . . . . . . . . . . . . 13 6.7. PCE TED Synchronization ................................. 18
7.8. Stateful Versus Stateless PCEs . . . . . . . . . . . . . . . 14 6.8. Stateful Versus Stateless PCEs .......................... 19
7.9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.9. Monitoring .............................................. 21
7.10. Policy and Confidentiality . . . . . . . . . . . . . . . . 14 6.10. Policy and Confidentiality ............................ 21
8. PCE Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . 15 6.11. Unsolicited Interactions ............................... 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Evaluation Metrics ............................................ 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 8. Manageability Considerations .................................. 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Information and Data Models .............................. 23
12. Intellectual Property Considerations . . . . . . . . . . . . . . 16 8.2 Liveness Detection and Monitoring ........................ 24
13. Normative References . . . . . . . . . . . . . . . . . . . . . . 17 8.3 Verifying Correct Operation .............................. 24
14. Informational References . . . . . . . . . . . . . . . . . . . . 17 8.4 Requirements on Other Protocols and Functional Components 25
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 8.5 Impact on Network Operation .............................. 25
16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations ....................................... 26
10. IANA Considerations .......................................... 26
11. Acknowledgements ............................................. 27
12. Intellectual Property Considerations ......................... 27
13. Normative References ......................................... 27
14. Informational References ..................................... 27
15. Authors' Addresses ........................................... 28
16. Full Copyright Statement ..................................... 29
1. Introduction 1. Introduction
Constraint-based path computation is a fundamental building block for Constraint-based path computation is a fundamental building block for
traffic engineering in MPLS and GMPLS networks. Path computation in traffic engineering in MPLS and GMPLS networks. Path computation in
large, multi-domain networks is highly complex and may require special large, multi-domain networks is highly complex and may require
computational components and cooperation between the different domains. special computational components and cooperation between the elements
This document specifies the architecture for a Path Computation Element in different domains. This document specifies the architecture for a
(PCE)-based model to address this problem space. Path Computation Element (PCE)-based model to address this problem
space.
This document does not attempt to provide a detailed description of all This document describes a set of building blocks for the PCE
the architectural components. Rather, it describes a set of building architecture from which solutions may be constructed. For example, it
blocks for the PCE architecture from which solutions may be constructed. discusses PCE-based implementations including composite, external,
For example, it discusses PCE-based implementations including composite, and multiple PCE path computation. Furthermore, it discusses
external, and multiple PCE path computation. Furthermore, it discusses
architectural considerations including centralized computation, architectural considerations including centralized computation,
distributed computation, synchronization, PCE discovery and load distributed computation, synchronization, PCE discovery and load
balancing, detecting PCE liveness, PCC-PCE and PCE-PCE communication, balancing, detection of PCE liveness, PCC-PCE and PCE-PCE
TED synchronization, stateful and stateless PCEs, monitoring, policy communication, TED synchronization, stateful and stateless PCEs,
and confidentiality, and evaluation metrics. monitoring, policy and confidentiality, and evaluation metrics.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 2. Terminology
CSPF: Constraint-based Shortest Path First. CSPF: Constraint-based Shortest Path First.
LER: Label Edge Router. LER: Label Edge Router.
LSDB: Link State Database. LSDB: Link State Database.
LSP: Label Switched Path. LSP: Label Switched Path.
LSR: Label Switching Router. LSR: Label Switching Router.
PCC: Path Computation Client : any client application requesting a path PCC: Path Computation Client : any client application requesting a
computation to be performed by the Path Computation Element. path computation to be performed by the Path Computation Element.
PCE: Path Computation Element: an entity (component, application or PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route based network node) that is capable of computing a network path or route
on a network graph and applying computational constraints (see further based on a network graph and applying computational constraints (see
description in section 3). further description in Section 3).
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 IGP extensions resource information of the domain. The TED may be fed by IGP
or potentially by other means. extensions or potentially by other means.
TE LSP: Traffic Engineering MPLS Label Switched Path. TE LSP: Traffic Engineering MPLS Label Switched Path.
4. Definitions 3. Definitions
A Path Computation Element (PCE) is an entity that is capable of A Path Computation Element (PCE) is an entity that is capable of
computing a network path or route based on a network graph, and applying computing a network path or route based on a network graph, and of
computational constraints. The PCE entity is an application that can be applying computational constraints during the computation. The PCE
located within a network node or component, on an out-of-network server, entity is an application that can be located within a network node or
etc. For example, a PCE would be able to compute the path of a TE LSP by component, on an out-of-network server, etc. For example, a PCE would
operating on the TED and considering the bandwidth and other constraints be able to compute the path of a TE LSP by operating on the TED and
applicable to the TE LSP service request. 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 A domain is any collection of network elements within a common sphere
address management or path computational responsibility. Examples of of address management or path computation responsibility. Examples
domains include IGP areas, Autonomous Systems (ASs), multiple ASs within of domains include IGP areas, Autonomous Systems (ASs), multiple ASs
a service provider network, or multiple ASs across multiple service within a service provider network, or multiple ASs across multiple
provider networks. However, domains of computational responsibility may service provider networks. However, domains of path computation
also exist as sub-domains of areas or ASs. responsibility may also exist as sub-domains of areas or ASs.
In order to fully characterize a PCE and clarify these definitions, the In order to fully characterize a PCE and clarify these definitions,
following important considerations must also be examined: the following important considerations must also be examined:
1) Path computation is applicable in both intra-domain, inter-domain, 1) Path computation is applicable in intra-domain, inter-domain, and
and inter-layer contexts. Inter-domain path computation may involve the inter-layer contexts.
correlation of topology and routing information between domains.
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 multiple Service Providers.
2) In "single PCE path computation," a single PCE is used to compute a a. Inter-domain path computation may involve the correlation of
given path in a domain. In "multiple PCE path computation," multiple topology and routing information between domains.
PCEs are used to compute a given path in a domain.
3) "Centralized computation model" refers to a model whereby all paths b. Inter-layer path computation refers to the use of PCE where
in a domain are computed by a single, centralized PCE. Conversely, multiple layers are involved and when the objective is to
"Distributed computation model" refers to the computation of paths in a perform path computation at one or multiple layers while taking
domain being shared among multiple PCEs. Paths that span multiple into account topology and resource information at these layers.
domains may be computed using the distributed model with a PCE
responsible for each domain, or the centralized model by defining a Overlapping domains are not within the scope of this document. In
domain that encompasses all of the other domains. From these the inter-domain case, the domains may belong to a single or
definitions, a centralized computation model inherently uses single PCE multiple Service Providers.
path computation. However, a distributed computation model could use
either single PCE path computation or multiple PCE path computations. 2) a. In "single PCE path computation," a single PCE is used to
There would be no such thing as a centralized model which uses multiple compute a given path in a domain. There may be multiple PCEs in
PCE path computations. 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 of 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 which uses multiple PCEs.
4) The PCE may or may not be located at the head-end of the path. For 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 example, a conventional intra-domain solution is to have path
computation performed by the head-end LSR of an MPLS TE LSP; in this 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
case, the head-end LSR contains a PCE. But solutions also exist where exist where other nodes on the path must contribute to the path
other nodes on the path must contribute to the path computation (for computation (for example, loose hops) making them PCEs in their
example, loose hops) making them PCEs in their own right. At the same own right. At the same time, the path computation may be made by
time, the path computation may be made by some other PCE physically some other PCE physically distinct from the computed path.
distinct from the computed path.
5) The path computed by the PCE may be an 'explicit PCE path' (that is, 5) The path computed by the PCE may be an "explicit PCE path" (that
the full explicit path from start to destination, made of a list of is, the full explicit path from start to destination, made of a
strict hops) or a 'strict/loose PCE path' (that is, a mix of strict and list of strict hops) or a "strict/loose PCE path" (that is, a mix
loose hops comprising of at least one loose hop representing the of strict and loose hops comprising at least one loose hop
destination), where a hop may be an abstract node such as an AS. 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 6) A PCE-based path computation model does not mean to be exclusive
can be used in conjunction with other path computation models. For and can be used in conjunction with other path computation models.
instance, the path of an inter-AS TE LSP may be computed using a For instance, the path of an inter-AS TE LSP may be computed using
PCE-based path computation model in some IGP areas, whereas the set of a PCE-based path computation model in some IGP areas, whereas the
traversed ASes may be specified by other means (not determined by any set of traversed ASs may be specified by other means (not
PCE). 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 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, implementation of a PCE. A PCE could be implemented on a router,
a dedicated network server, etc. Moreover, the PCE function is an LSR, a dedicated network server, etc. Moreover, the PCE
orthogonal to the forwarding capability of the node on which it is function is orthogonal to the forwarding capability of the node on
implemented. which it is implemented.
5. Motivation for a PCE-based Architecture 4. Motivation for a PCE-based Architecture
Several motivations for a PCE-based architecture (described in section Several motivations for a PCE-based architecture (described in
5) are listed below. This list is not meant to be exhaustive and is Section 5) are listed below. This list is not meant to be exhaustive
provided for the sake of illustration. and is provided for the sake of illustration.
It should be highlighted that the aim of this section is to provide some It should be highlighted that the aim of this section is to provide
application examples for which a PCE-based path may be suitable: this some application examples for which a PCE-based path may be suitable:
also clearly states that such a model does not aim to replace existing this also clearly states that such a model does not aim to replace
path computation model but would apply to specific existing situations. existing path computation models but would apply to specific existing
or future situations.
5.1. CPU-intensive Path Computation/Global Optimization 4.1. CPU-intensive Path Computation/Global Optimization
There are many situations where the computation of a path may be highly There are many situations where the computation of a path may be
CPU-intensive: examples of CPU-intensive path computations include the highly CPU-intensive: examples of CPU-intensive path computations
resolutions of NP-complete problems such as: include the resolution of problems such as:
- Global optimization in placing a set of TE LSPs within a domain so as - Global optimization in placing a set of TE LSPs within a domain so
to optimize an objective function (for example, minimization of the as to optimize an objective function (for example, minimization of
maximum link utilization) the maximum link utilization)
- Multi-criteria path computation (for example, delay and link - Multi-criteria path computation (for example, delay and link
utilization, inclusion of switching capabilities, adaptation features, utilization, inclusion of switching capabilities, adaptation
encoding types and optical constraints within a GMPLS optical network) features, encoding types and optical constraints within a GMPLS
optical network)
- Computation of minimal cost Point to Multipoint trees (Steiner - Computation of minimal cost Point to Multipoint trees (Steiner
trees). trees).
In these situations, it may not be possible or desirable for a router to In these situations, it may not be possible or desirable for a router
perform path computation because of the constraints on its CPU, in which to perform path computation because of the constraints on its CPU, in
case the path computation may be off-loaded to some other PCE(s). which case the path computation may be off-loaded to some other
PCE(s).
5.2. Partial Visibility 4.2. Partial Visibility
There are several scenarios where the node responsible for path There are several scenarios where the node responsible for path
computation has limited visibility of the network topology to the computation has limited visibility of the network topology to the
destination. This limitation may occur, for instance, when an ingress destination. This limitation may occur, for instance, when an ingress
router attempts to establish an LSP to a destination that lies in a router attempts to establish an LSP to a destination that lies in a
separate domain, since TE information is not exchanged across the domain separate domain, since TE information is not exchanged across the
boundaries. In such cases, it is possible to use loose routes to domain boundaries. In such cases, it is possible to use loose routes
establish the LSP, relying on routers at the domain borders to establish to establish the LSP, relying on routers at the domain borders to
the next piece of the path, however, it is not possible to guarantee establish the next piece of the path, however, it is not possible to
that the optimal (shortest) path will be used, nor even that a viable guarantee that the optimal (shortest) path will be used, nor even
path will be discovered except, possibly, through repeated trial and that a viable path will be discovered except, possibly, through
error using crankback or other signaling extensions. repeated trial and error using crankback or other signaling
extensions.
This problem of inter-domain path computation may most probably be This problem of inter-domain path computation may most probably be
addressed through distributed computation with cooperation among PCEs addressed through distributed computation with cooperation among PCEs
within each of the domains, or perhaps by using a central "all-seeing" within each of the domains, or perhaps by using a central
PCE. In this latter case there are challenges of scalability (both the "all-seeing" PCE that has access to the complete set of topology
size of the TED and the responsiveness of a single PCE handling requests information. In this latter case there are challenges of scalability
for many domains) and of preservation of confidentiality when the (both the size of the TED and the responsiveness of a single PCE
domains belong to different Service Providers. 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 Note that the issues described here can be further highlighted in the
context of LSP re-optimization, or the establishment of multiple diverse context of LSP reoptimization, or the establishment of multiple
LSPs for protection or load sharing. diverse LSPs for protection or load sharing.
5.3. Absence of the TED or use of Non-TE-Enabled IGP 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 The traffic engineering database (TED) may be a large drain on the
resources of a network node (such as an edge router or LER) both from a resources of a network node (such as an edge router or LER) both from
memory perspective and because it may require non-negligible CPU a memory perspective and because it may require non-negligible CPU
activity to maintain. The use of a distinct PCE may be appropriate in activity to maintain. The use of a distinct PCE may be appropriate in
such circumstances, and a separate node can be used to establish and such circumstances, and a separate node can be used to establish and
maintain the TED, and to make it available for path computation. maintain the TED, and to make it available for path computation.
The IGPs run within some networks are not sufficient to build a full 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 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 OSPF-TE/ISIS-TE extensions, or some routers in the network may not
support the TE extensions. In these cases, in order to successfully support the TE extensions. In these cases, in order to successfully
compute paths through the network, the TED must be constructed or compute paths through the network, the TED must be constructed or
supplemented through configuration action, and updated as network supplemented through configuration action, and updated as network
resources are reserved or released. Such a TED could be distributed to resources are reserved or released. Such a TED could be distributed
each router so that each router can perform path computation, or held to each router so that each router can perform path computation, or
centrally (on a distinct node that supports PCE) for centralized path held centrally (on a distinct node that supports PCE) for centralized
path computation.
computation.
5.4. Node Outside the Routing Domain 4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative An LER might not be part of the routing domain for administrative
reasons (for example, a customer-edge (CE) router connected to the reasons (for example, a customer-edge (CE) router connected to the
provider-edge (PE) router in the context of MPLS VPN [RFC2547] and for provider-edge (PE) router in the context of MPLS VPN [RFC2547] and
which it is desired to provide a CE to CE TE LSP path). for which it is desired to provide a CE to CE TE LSP path).
This scenario suggests a solution that does not involve doing This scenario suggests a solution that does not involve doing
computation on the ingress router, and that does not rely on static computation on the ingress router, and that does not rely on static
loose hops configuration in which case optimal shortest paths could not loose hops configuration in which case optimal shortest paths could
be achieved. A distinct PCE-based solution can help here. Note that the not be achieved. A distinct PCE-based solution can help here. Note
PCE in this case may, itself, provide a path that includes loose hops. that the PCE in this case may, itself, provide a path that includes
loose hops.
5.5. Network Element Lacks Control Plan or Routing Capability 4.5. Network Element Lacks Control Plane or Routing Capability
It is common in legacy optical networks for the network elements not to It is common in legacy optical networks for the network elements not
have a control plane or routing capability. On such network elements to have a control plane or routing capability. Such network elements
there only exists the data plane and management plane, and all only have a data plane and a management plane, and all
cross-connections are made from the management plane. It is desirable in cross-connections are made from the management plane. It is
this case to run the path computation on the PCE, and send the desirable in this case to run the path computation on the PCE, and
cross-connection commands to each node on the computed path. This send the cross-connection commands to each node on the computed path.
scenario is important for ASON-capable networks, and may also be used That is, the PCC would be an element of the management plane, perhaps
for interworking between GMPLS-capable and GMPLS-incapable networks. residing in the NMS or OSS.
5.6. Backup Path Computation for Bandwidth Protection This scenario is important for ASON-capable networks, and may also be
used for interworking between GMPLS-capable and GMPLS-incapable
networks.
A PCE can be used to compute backup paths in the context of fast reroute 4.6. Backup Path Computation for Bandwidth Protection
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 A PCE can be used to compute backup paths in the context of fast
allows ensuring complete bandwidth sharing between bypass tunnels 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
protection independent elements, while avoiding any extensions to LSP protection independent elements, while avoiding any extensions to LSP
signaling. Both centralized and distributed computation models are signaling. Both centralized and distributed computation models are
applicable. In the distributed case each LSR can be a PCE to compute its applicable. In the distributed case each LSR can be a PCE to compute
own protection. the paths of backup tunnels to protect against the failure of
adjacent network links or nodes.
5.7. Multi-Layer Networks 4.7. Multi-Layer Networks
A server-layer network of one switching capability may support multiple A server-layer network of one switching capability may support
networks of another (more granular) switching capability. For example, a multiple networks of another (more granular) switching capability.
TDM network may provide connectivity for client-layer networks such as For example, a TDM network may provide connectivity for client-layer
IP, MPLS or Layer 2 [MRN]. networks such as IP, MPLS or Layer 2 [MRN].
The server-layer network is unlikely to provide the same connectivity The server-layer network is unlikely to provide the same connectivity
paradigm as the client networks so that bandwidth granularity in the paradigm as the client networks so that bandwidth granularity in the
server-layer network may be much coarser than in the client-layer server-layer network may be much coarser than in the client-layer
network. Similarly, there is likely to be a management separation network. Similarly, there is likely to be a management separation
between the two networks providing independent address spaces. between the two networks providing independent address spaces.
Further, where multiple client-layer networks make use of the same Further, where multiple client-layer networks make use of the same
server-layer network, those client-layer networks may have server-layer network, those client-layer networks may have
independent policies, control parameters, address spaces and routing independent policies, control parameters, address spaces and routing
preferences. preferences.
The different client and server layer networks may be considered as The different client and server layer networks may be considered as
distinct path computation regions within a PCE domain, and so the PCE distinct path computation regions within a PCE domain, and so the PCE
architecture is architecture is useful to allow path computation from one
useful to allow path computation from one client-layer network region, client-layer network region, across the server-layer network to
across the server-layer network to another client-layer network region. another client-layer network region.
In this case, the PCE is responsible for resolving address space issues, In this case, the PCEs are responsible for resolving address space
handling differences in policy and control parameters, and coordinating issues, handling differences in policy and control parameters, and
resources between the networks. Note that, because of the differences coordinating resources between the networks. Note that, because of
in bandwidth granularity, connectivity across the server-layer network the differences in bandwidth granularity, connectivity across the
may be provided through virtual TE links or Forwarding Adjacencies: server-layer network may be provided through virtual TE links or
the PCE may offer a point of control responsible for the decision to Forwarding Adjacencies: the PCE may offer a point of control
provision new TE links or Forwarding Adjacencies across the responsible for the decision to provision new TE links or Forwarding
server-layer network. Adjacencies across the server-layer network.
6. Overview of the PCE-Based Architecture 5. Overview of the PCE-Based Architecture
This section is intended to give an overview of the network architecture This section is gives an overview of the architecture of the PCE
of the PCE model. It needs to be read in conjunction with the details model. It needs to be read in conjunction with the details provided
provided in the next section to provide a full view of the flexibility in the next section to provide a full view of the flexibility of the
of the model. model.
6.1. Composite PCE 5.1. Composite PCE Node
Figure 1 below shows the components of a typical composite PCE node Figure 1 below shows the components of a typical composite PCE node
(that is, a router that also implements the PCE functionality) that (that is, a router that also implements the PCE functionality) that
utilizes path computation. The routing protocol is used to exchange TE utilizes path computation. The routing protocol is used to exchange
information from which the TED is constructed. Service requests to TE information from which the TED is constructed. Service requests to
provision TE LSPs are received by the node and converted into signaling provision TE LSPs are received by the node and converted into
requests, but these may first require path computation which is signaling requests, but this conversion may require path computation
requested from a Path Computation Element, the PCE. The PCE operates on which is requested from a PCE. The PCE operates on the TED in order
the TED in order to respond with the requested path. to respond with the requested path.
--------------- ---------------
| --------- | Routing ---------- | --------- | Routing ----------
| | | | Protocol | | | | | | Protocol | |
| | TED |<-+----------+-> | | | TED |<-+----------+-> |
| | | | | | | | | | | |
| --------- | | | | --------- | | |
| | | | | | | | | |
| | Input | | | | | Input | | |
| v | | | | v | | |
skipping to change at page 9, line 33 skipping to change at page 10, line 33
| --------- | | | | --------- | | |
Service | | | | Signaling| | Service | | | | Signaling| |
Request | |Signaling| | Protocol | | Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> | ------+->| Engine |<-+----------+-> |
| | | | | | | | | | | |
| --------- | ---------- | --------- | ----------
--------------- ---------------
Figure 1. Composite PCE Node Figure 1. Composite PCE Node
Note that the routing adjacency between the composite PCE node and any Note that the routing adjacency between the composite PCE node and
other router may be performed by means of direct connectivity or any any other router may be performed by means of direct connectivity or
tunneling mechanism. any tunneling mechanism.
6.2. External PCE 5.2. External PCE
Figure 2 shows PCE support that is external from the requesting network Figure 2 shows a PCE that is external to the requesting network
element. A service request is received by the head-end node and before element. A service request is received by the head-end node and
it can signal to establish the service it makes a request to the before it can initiate signaling to establish the service, it makes
external PCE for a path to be computed. The PCE makes the computation a path computation request to the external PCE. The PCE uses the TED
using the TED and returns a response. as input to the computation and returns a response.
---------- ----------
| ----- | | ----- |
| | TED |<-+------------> | | TED |<-+------------>
| ----- | TED synchronization | ----- | TED synchronization
| | | mechanism (for example, routing protocol) | | | mechanism (for example, routing protocol)
| | | | | |
| v | | v |
| ----- | | ----- |
| | PCE | | | | PCE | |
skipping to change at page 10, line 27 skipping to change at page 11, line 27
| Request/ | Request/
| Response | Response
v v
Service ---------- Signaling ---------- Service ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Request| Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node | ---->| Node |<---------->| Node |
---------- ---------- ---------- ----------
Figure 2. External PCE Node Figure 2. External PCE Node
Note that in this case, the node that supports the PCE function may also Note that in this case, the node that supports the PCE function may
perform forwarding, but those functions are purely orthogonal. also be an LSR or router performing forwarding in its own right (i.e.
it may be a composit PCE node), but those functions are purely
orthogonal to the operation of the function in the instance being
considered here.
6.3. Multiple PCE Path Computation 5.3. Multiple PCE Path Computation
Figure 3 illustrates how multiple PCE path computations may be performed Figure 3 illustrates how multiple PCE path computations may be
along the path of a signaled service. As in the previous example, the performed along the path of a signaled service. As in the previous
head-end PCC makes a request to an external PCE, but the path that is example, the head-end PCC makes a request to an external PCE, but the
returned is such that the next network element finds it necessary to path that is returned is such that the next network element finds it
perform further computation. It consults another PCE to establish the necessary to perform further computation. This may be the case when
next hop in the path. the path returned is a partial path that does not reach the intended
destination or when the computed path is loose. The downstream
network element consults another PCE to establish the next hop(s) in
the path.
Note that either or both PCEs in this case could be co-resident with the Note that either or both PCEs in this case could be composite PCE
network node as in Section 5.1. nodes as in Section 5.1.
---------- ---------- ---------- ----------
| | | | | | | |
| PCE | | PCE | | PCE | | PCE |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | TED | | | | TED | | | | TED | | | | TED | |
| ----- | | ----- | | ----- | | ----- |
---------- ---------- ---------- ----------
^ ^ ^ ^
| Request/ | Request/ | Request/ | Request/
| Response | Response | Response | Response
v v v v
Service ---------- Signaling ------------- Signaling ------------ Service -------- Signaling ------------ Signaling ------------
Request| Head-End | Protocol |Intermediate | Protocol |Intermediate| Request| Head-End | Protocol |Intermediate | Protocol |Intermediate|
---->| Node |<---------->| Node |<--------->| Node | ---->| Node |<--------->| Node |<--------->| Node |
---------- ------------- ------------ -------- ------------ ------------
Figure 3. Multiple PCE Path Computation Figure 3. Multiple PCE Path Computation
6.4. Multiple PCE Path Computation with Inter-PCE Communication 5.4. Multiple PCE Path Computation with Inter-PCE Communication
The PCE in Section 5.3 was not able to supply a full path for the The PCE in Section 5.3 was not able to supply a full path for the
requested service and this resulted in the adjacent node needing to make requested service and this resulted in the adjacent node needing to
its own computation request. As illustrated in Figure 4, the same make its own computation request. As illustrated in Figure 4, the
problem is solved by introducing inter-PCE communication and cooperation same problem may be solved by introducing inter-PCE communication,
between PCEs so that the PCE consulted by the head-end network node and cooperation between PCEs so that the PCE consulted by the
makes a request of another PCE to help with the computation. head-end network node makes a request of another PCE to help with the
computation.
---------- ---------- ---------- ----------
| | Inter-PCE Request/Response | | | | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE | | PCE |<--------------------------------->| PCE |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | TED | | | | TED | | | | TED | | | | TED | |
| ----- | | ----- | | ----- | | ----- |
---------- ---------- ---------- ----------
^ ^
skipping to change at page 11, line 51 skipping to change at page 13, line 4
^ ^
| Request/ | Request/
| Response | Response
v v
Service ---------- Signaling ---------- Signaling ---------- Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node | ---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ---------- ---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
Multiple PCE path computation with inter-PCE communication involves Multiple PCE path computation with inter-PCE communication involves
coordination between distributed PCEs such that the result of the coordination between distributed PCEs such that the result of the
computation performed by one PCE depends on information supplied by computation performed by one PCE depends on information supplied by
other PCEs. PCE-PCE communication is discussed further in section 6.6. other PCEs. This model does not provide a distributed computaiton
algorithm, but allows distinct PCEs to be responsible for computation
of parts (segments) of the path.
Note that a PCC cannot see the difference between centralized PCE-PCE communication is discussed further in Section 6.6.
Note that a PCC might not see the difference between centralized
computation, and multiple PCE path computation with inter-PCE computation, and multiple PCE path computation with inter-PCE
communication. That is, the PCC network node or component that requests communication. That is, the PCC network node or component that
the computation makes a single request and receives a full or partial requests the computation makes a single request and receives a full
path in response, but the response is actually achieved through the or partial path in response, but the response is actually achieved
coordinated, cooperative efforts of more than one PCE. through the coordinated, cooperative efforts of more than one PCE.
6.5 Areas for Standardization 5.5 Areas for Standardization
According to the PCE charter, the following are the standardization The following areas require standardization within the PCE
areas that the PCE working group will address: architecture.
- communication between PCCs and PCEs, and between cooperating PCEs - communication between PCCs and PCEs, and between cooperating PCEs
- requirements for extensions to existing routing and signaling
- requirements for extensions to existing routing and/or signaling
protocols in support of PCE discovery and signaling of inter-domain protocols in support of PCE discovery and signaling of inter-domain
paths paths
- definition of metrics to evaluate path quality, scalability, - definition of metrics to evaluate path quality, scalability,
responsiveness and robustness of path computation models. responsiveness and robustness of path computation models.
7. PCE Architectural Considerations 6. PCE Architectural Considerations
The aim of this section is to provide a list of the PCE architectural This section provides a list of the PCE architectural components.
components. Specific realizations and implementation details (state Specific realizations and implementation details (state machines or
machines or algorithms, etc.) of PCE-based solutions are out of the algorithms, etc.) of PCE-based solutions are out of the scope of this
scope of this document. document.
Note also that PCE-based path computation does not affect in any way the Note also that PCE-based path computation does not affect in any way
use of the computed paths. For example, the use of PCE does not change the use of the computed paths. For example, the use of PCE does not
the way in which Traffic Engineering LSPs are signaled, maintained and change the way in which Traffic Engineering LSPs are signaled,
torn down, but strictly relates to the path computation aspects of such maintained and torn down, but strictly relates to the path
TE LSPs. computation aspects of such TE LSPs.
7.1. Centralized Computation Model 6.1. Centralized Computation Model
A "centralized computation model" considers that all path computations A "centralized computation model" considers that all path
for a given domain will be performed by a single, centralized PCE. This computations for a given domain will be performed by a single,
may be a dedicated server (for example, an external PCE node), or a centralized PCE. This may be a dedicated server (for example, an
nominated router (for example, a composite PCE node) in the network. In external PCE node), or a designated router (for example, a composite
this model, all PCCs in the domain would send their path computation PCE node) in the network. In this model, all PCCs in the domain would
requests to the central PCE. While a domain in this context might be an send their path computation requests to the central PCE. While a
IGP area or AS, it might also be a sub-group of network nodes that is domain in this context might be an IGP area or AS, it might also be a
defined by its dependence on the PCE. sub-group of network nodes that is defined by its dependence on the
PCE.
7.2. Distributed Computation Model This model has a single point of failure: the PCE. In order to avoid
this issue, the centralized computation model may designate a backup
PCE that can take over the computation responsibility in a controlled
manner in the event of a failure of the primary PCE. Note that at any
moment in time there is only one active PCE in any domain.
A "distributed computation model" refers to a domain or network that may 6.2. Distributed Computation Model
include multiple PCEs, and where computation of paths is shared among
the PCEs. A given path may in turn be computed by a single PCE ("single
PCE path computation") or multiple PCEs ("multiple PCE path
computation"). A PCC may be linked to a particular PCE, or may be able
to choose freely among several PCEs - the method of choice between PCEs A "distributed computation model" refers to a domain or network that
is out of scope of this document, but see section 6.4. It will often be may include multiple PCEs, and where computation of paths is shared
the case that the computation of an individual path is performed among the PCEs. A given path may in turn be computed by a single PCE
entirely by a single PCE. For example, this is usually the case in MPLS ("single PCE path computation") or multiple PCEs ("multiple PCE path
TE within a single IGP where the ingress LSR/composite node is computation"). A PCC may be linked to a particular PCE, or may be
responsible for computing the path or for contacting an external PCE. able to choose freely among several PCEs - the method of choice
Conversely, multiple PCE path computation implies the involvement of between PCEs is out of scope of this document, but see Section 6.4
more than one PCE in the computation of a single path. An example of for a discussion of PCE discovery which impacts on this choice. It
this is where loose hop expansion is performed by transit LSRs/composite will often be the case that the computation of an individual path is
nodes on an MPLS TE LSP. Another example is the use of multiple performed entirely by a single PCE. For example, this is usually the
cooperative PCE involved in the computation of a single LSP path. case in MPLS TE within a single IGP area where the ingress LSR /
composite PCE node is responsible for computing the path or for
contacting an external PCE. Conversely, multiple PCE path computation
implies that more than one PCE is involved in the computation of a
single path. An example of this is where loose hop expansion is
performed by transit LSRs / composite PCE nodes on an MPLS TE LSP.
Another example is the use of multiple cooperating PCEs to compute
the path of a single LSP.
7.3. Synchronization 6.3. Synchronization
It is often the case that multiple paths need to be computed to support It is often the case that multiple paths need to be computed to
a single service (for example, for protection or load sharing). support a single service (for example, for protection or load
A PCC that determines that it requires more than one path to be computed sharing). A PCC that determines that it requires more than one path
may send a series of individual requests to the PCE. In this case, the to be computed may send a series of individual requests to the PCE.
PCE may make multiple individual path computations to generate the set In this case of non-synchronized path computation, the PCE will make
of paths - the resultant paths are non-synchronized and are exactly multiple individual path computations to generate the paths and the
those that would have been generated had the PCC made multiple requests. PCC may send its individual requests to different PCEs.
In this case of non-synchronized path computation, the path computation
of a set of TE LSPs can be shared among a set of PCEs (that is, one path
computed by each PCE). Furthermore, each PCE can be backed up by one or
more PCEs, should it fail.
Conversely, the PCC may issue a single request to the PCE asking for all Alternatively, the PCC may send a single request to a PCE asking for
of the paths. The PCE will then in turn perform the simultaneous a set of paths to be computed but specifying that non-synchronized
computation of the set of requested path. Such synchronized computation path computation is acceptable. The PCE may compute each path in turn
usually provides more optimal results. exactly as it would have done had the PCC made multiple requests, and
the PCE may devolve some computations to other PCEs if it chooses.
The involvement of more than one PCE in the computation of a series of Conversely, the PCC may issue a single request to the PCE asking for
paths is by its nature non-synchronized. However, a set of cooperating all of the paths to be computed in a synchronized manner. The PCE
PCEs may be synchronized under the control of a single PCE. For example, will then perform simultaneous computation of the set of requested
a PCC may send a request to a PCE which invokes domain specific path. Such synchronized computation can often provide more optimal
computations by other PCEs before supplying a result to the PCC. results.
It is desirable to add a parameter to the PCC-PCE protocol to request The involvement of more than one PCE in the computation of a series
alternate paths should the primary path fail to complete. While of paths is by its nature non-synchronized. However, a set of
alternate paths may not always be successful if the primary fails, cooperating PCEs may be synchronized under the control of a single
including alternate paths in a PCE response could perhaps have less PCE. For example, a PCC may send a request to a PCE which invokes
overhead than having the PCC make separate requests for a second path, domain specific computations by other PCEs before supplying a result
third path, etc. This technique is used in some existing CSPF to the PCC.
implementations.
7.4. PCE Discovery and Load Balancing It is desirable to add a parameter to the PCC-PCE protocol to request
that the PCE supplies a set of alternate paths for use by the PCC
should the establishment of the LSP using the principal path fail to
complete. While alternate paths may not always be successful if the
first path fails, including alternate paths in a PCE response could
have less overhead than having the PCC make separate requests for
subsequent path computations as the need arises. This technique is
used in some existing CSPF implementations.
The PCE architecture requires that the PCC knows the location of one or 6.4. PCE Discovery and Load Balancing
more PCEs that it can use for the computation of a path. Such knowledge
may come through a discovery mechanism that simply relies on local
configuration, or can imply dynamic PCE discovery along with various
static (for example, Boolean capability) or dynamically computed The PCE architecture requires that the PCC/PCE know the location of
variables (for example, computing resources). Proxy PCE advertisement one or more PCEs that it can use for the computation of a path. Such
whereby the existence of a PCE is advertised via a proxy PCE is a viable knowledge may come through a discovery mechanism that simply relies
alternative, should the PCE be incapable of such advertisement itself. on local configuration, or can imply dynamic PCE discovery along with
In this later case, it is a requirement for the proxy to adequately various static (for example, Boolean capability) or dynamically
advertise the PCE status and capability in a timely and synchronized computed variables (for example, computing resources). Proxy PCE
fashion. advertisement whereby the existence of a PCE is advertised via a
proxy PCE is a viable alternative, should the PCE be incapable of
such advertisement itself. In this later case, it is a requirement
for the proxy to adequately advertise the PCE status and capability
in a timely and synchronized fashion.
In the event that multiple PCEs are available to serve a particular path In the event that multiple PCEs are available to serve a particular
computation request, the PCC must select a PCE to satisfy the request. path computation request, the PCC must select a PCE to satisfy the
The details of such a selection, in order for instance to efficiently request. The details of such a selection, in order for instance to
share the computation load across multiple PCEs, is local to the PCC and efficiently share the computation load across multiple PCEs, is local
out of the scope of this document. to the PCC and out of the scope of this document.
A PCE SHOULD advertise its capabilities, such as: A PCE SHOULD advertise its capabilities, such as:
- set of constraints that it can account for (diversity, SRLGs, - set of constraints that it can account for (diversity, SRLGs,
Optical impairments, wavelength continuity, etc.) Optical impairments, wavelength continuity, etc.)
- number of switching capability layers (and which ones) - number of switching capability layers (and which ones)
- number of path selection criteria (and which ones) - number of path selection criteria (and which ones)
- whether it is a stateless PCE or it can send updates about - whether it is a stateless PCE or it can send updates about
better paths that might be available in the future better paths that might be available in the future
- whether it can compute P2MP trees (and which types) - whether it can compute P2MP trees (and which types)
- whether it can ensure resource sharing between backup tunnels - whether it can ensure resource sharing between backup tunnels.
This information would help a PCC that dynamically learns about This information would help a PCC that dynamically learns about
PCEs available on the network to decide which of them to use. PCEs available on the network to decide which of them to use.
Alternatively, a PCC might ask a PCE to perform a particular type Alternatively, a PCC might ask a PCE to perform a particular type
of service and receive a response that says it is unable to of service and receive a response that says that the PCE is unable to
perform the service, specify the things it can do. Note that the perform the service, but specifying the things that the PCE can do.
parameters mentioned above are not meant to be exhaustive and are Note that the parameters mentioned above are not meant to be
listed for the sake of illustration. exhaustive and are listed for the sake of illustration.
7.5. Detecting PCE Liveness 6.5. Detecting PCE Liveness
The ability to detect a PCE's liveness is a mandatory piece of the The ability to detect a PCE's liveness is a mandatory piece of the
overall architecture and could be achieved by several means. If some overall architecture and could be achieved by several means. If some
form of regular advertisement (such as through IGP extensions) is used form of regular advertisement (such as through IGP extensions) is
for PCE discovery, it is expected that the PCE liveness will be used for PCE discovery, it is expected that the PCE liveness will be
determined by means of status advertisement (for example, IGP LSA/LSPs). determined by means of status advertisement (for example, IGP
LSA/LSPs).
The failure of a PCE while processing a request, or the inability of a The inability of a PCE to service a request (perhaps due to excessive
PCE to service a request (perhaps due to excessive load) may be load) may be reported to the PCC through a failure message, but the
determined by the PCC through the use of timers. This is particularly failure of a PCE or the communications mechanism while processing a
true in the case of inter-domain path computation where the PCE liveness request cannot be reported in this way. Further, in the case of
may not be detected by means of the IGP. The detection of a PCE failure excessive load, the PCE may not have sufficient resources to send a
can be achieved by using the PCC-PCE protocol, much like the mechanisms failure message. Thus the PCC should employ other mechanisms such as
involving timers used in RSVP and LDP. protocol timers to determine the liveness of the PCE. This is
particularly important in the case of inter-domain path computation
where the PCE liveness may not be detected by means of the IGP that
runs in the PCC's domain.
7.6. PCC-PCE & PCE-PCE Communication 6.6. PCC-PCE & PCE-PCE Communication
Once the PCC has selected a PCE, and provided that the PCE is not local Once the PCC has selected a PCE, and provided that the PCE is not
to the PCC, a request/response protocol is required for the PCC to local to the PCC, a request/response protocol is required for the PCC
communicate the path computation requests to the PCE and for the PCE to to communicate the path computation requests to the PCE and for the
return the path computation response. PCE to return the path computation response.
The path computation request may include a significant set of The path computation request may include a significant set of
requirements including requirements including
- the source and destination of the path - the source and destination of the path
- the bandwidth and other QoS parameters desired - the bandwidth and other QoS parameters desired
- resources, resource affinities and shared risk link groups (SRLGs) to - resources, resource affinities and shared risk link groups (SRLGs)
use/avoid to use/avoid
- the number of disjoint paths required and if near-disjoint paths are - the number of disjoint paths required and if near-disjoint paths
acceptable are acceptable
- the level of robustness of the path resources - the level of robustness of the path resources
- and so on. - and so on.
The level of robustness of the path resources covers a qualitative The level of robustness of the path resources covers a qualitative
assessment of the vulnerability of the resources that may be used. For assessment of the vulnerability of the resources that may be used.
example, one might grade resources based on empirical evidence (mean For example, one might grade resources based on empirical evidence
time between failures), on known risks (there is major building work (mean time between failures), on known risks (there is major building
going on near this conduit), or on prejudice (vendor X's software is work going on near this conduit), or on prejudice (vendor X's
always crashing). A PCC could request that only robust resources be software is always crashing). A PCC could request that only robust
used, or allow any resource. Of course, this information does not resources be used, or allow any resource.
comprise part of the TE information advertise by IGPs. It must come from
somewhere else.
In case of a positive response from the PCE, one or more paths would be In case of a positive response from the PCE, one or more paths would
returned to the requesting node. In the event of a failure to compute be returned to the requesting node. In the event of a failure to
the desired path(s), an error is returned together with as much compute the desired path(s), an error is returned together with as
information as possible about the reasons for the failure, and much information as possible about the reasons for the failure(s),
potentially advice about which constraints might be relaxed to be more and potentially with advice about which constraints might be relaxed
likely to achieve a positive result. to be more likely to achieve a positive result in a future request.
Note that the resultant path(s) may be made up of a set of strict or Note that the resultant path(s) may be made up of a set of strict or
loose hops, or any combination of strict and loose hops. Moreover, a hop loose hops, or any combination of strict and loose hops. Moreover, a
may have the form of a non-explicit abstract node. hop may have the form of a non-explicit abstract node.
A request/response protocol is also required for a PCE to communicate A request/response protocol is also required for a PCE to communicate
path computation requests to another PCE and for the PCE to return the path computation requests to another PCE and for the PCE to return
path computation response. The path computation request may include a the path computation response. The path computation request may
significant set of requirements including those defined above. In case include a significant set of requirements including those defined
of a positive response from the PCE, one or more paths would be returned above. In case of a positive response from the PCE, one or more paths
to the requesting PCE. In the event of a failure to compute the desired would be returned to the requesting PCE. In the event of a failure to
path(s), an error is returned together with as much information as compute the desired path(s), an error is returned together with as
possible about the reasons for the failure, and potentially advice about much information as possible about the reasons for the failure, and
which constraints might be relaxed to be more likely to achieve a potentially advice about which constraints might be relaxed to be
positive result. Note that the resultant path(s) may be made up of a more likely to achieve a positive result. Note that the resultant
set of strict or loose hops, or any combination of strict and loose path(s) may be made up of a set of strict or loose hops, or any
combination of strict and loose hops. Moreover, a hop may have the
form of a non-explicit abstract node.
hops. Moreover, a hop may have the form of a non-explicit abstract node. An important feature of PCEs that are cooperating to compute a path
is that they apply compatible or identical computation algorithms.
This may require coordination through the communication between the
PCEs.
No assumption is made at this stage about whether the PCC-PCE and Note that when multiple PCEs cooperate to compute a path it is
PCE-PCE communication protocols are identical. important that they have a coordinated view of the meaning of
constraints such as resource affinities and class of service. This
is particularly significant where the PCEs are responsible for
different domains. It is assumed that this is a matter of policy
between domains and between PCEs, and is achieved through
configuration not through protocol communications.
7.7. PCE TED Synchronization No assumption is made in this architecture about whether the PCC-PCE
and PCE-PCE communication protocols are identical.
6.7. PCE TED Synchronization
As previously described, the PCE operates on a TED. Information on As previously described, the PCE operates on a TED. Information on
network status to build the TED may be provided in the domain by various network status to build the TED may be provided in the domain by
means: various means:
1) Participation in IGP distribution of TE information. The 1) Participation in IGP distribution of TE information. The standard
standard method of distribution of TE information within an IGP area is method of distribution of TE information within an IGP area is
using extensions to the IGP. This mechanism allows participating nodes through the use of extensions to the IGP [RFC3630, RFC3748]. This
to build a TED, and this is the standard technique, for example, within mechanism allows participating nodes to build a TED, and this is
a single area MPLS network. A node that hosts the PCE function may the standard technique, for example, within a single area MPLS
collect TE information in this way by maintaining at least one routing network. A node that hosts the PCE function may collect TE
adjacency with a router in the domain. The PCE node may be adjacent or information in this way by maintaining at least one routing
non-adjacent (via some tunneling techniques) to the router. Such a adjacency with a router in the domain. The PCE node may be
technique provides a mechanism for ensuring that the TED is efficiently adjacent or non-adjacent (via some tunneling techniques) to the
synchronized with the network state and is the normal case, for example, router. Such a technique provides a mechanism for ensuring that
when the PCE is co-resident with the LSRs in an MPLS network. the TED is efficiently synchronized with the network state and is
the normal case, for example, when the PCE is co-resident with the
LSRs in an MPLS network.
2) Out-of-band TED synchronization. It may not be convenient or 2) Out-of-band TED synchronization. It may not be convenient or
possible for a PCE node to participate in the IGPs of one or more possible for a PCE to participate in the IGPs of one or more
domains (for example, when there are very many domains, when IGP domains (for example, when there are very many domains, when IGP
participation is not desired, or when some domains are not running participation is not desired, or when some domains are not running
TE-aware IGPs). In this case some mechanism may need to be defined to TE-aware IGPs). In this case some mechanism may need to be defined
allow the PCE node to retrieve the TED from each domain. Such a to allow the PCE node to retrieve the TED from each domain. Such a
mechanism could be incremental (like the IGP in the previous case), or mechanism could be incremental (like the IGP in the previous
could involve a bulk transfer of the complete TED. The latter might case), or could involve a bulk transfer of the complete TED. The
significantly limit the capability to ensure TED synchronization which latter might significantly limit the capability to ensure TED
might result in an increase in the failure rate of computed paths. synchronization which might result in an increase in the failure
Consideration should also be given to the impact of the TED distribution rate of computed paths. Consideration should also be given to the
on the network and on the network node within the domain that is asked impact of the TED distribution on the network and on the network
to distribute the database. This is particularly relevant in the case of node within the domain that is asked to distribute the database.
frequent network state changes. This is particularly relevant in the case of frequent network
state changes.
3) Information in the TED can include LSP information obtained 3) Information in the TED can include information obtained from
from sources other than the IGP. For example, this information sources other than the IGP. For example, information about link
usage policies can be configured by the operator. Path computation
can also act on a far wider set of information that includes data
about the LSPs provisioned within the network. This information
can include LSP routes, reserved bandwidth, and measured traffic can include LSP routes, reserved bandwidth, and measured traffic
volume passing through the LSP. Such LSP information is required volume passing through the LSP.
to perform LSP re-optimization, as described in Sections 4.4 and
7, which can be take into account the traffic fluctuations. Also,
such LSP information is needed to reconfigure virtual network
topology (VNT), in which lower layer LSPs such as optical paths
form the VNT. The VNT is used for routing of higher-region
traffic such as IP traffic.
Note that synchronization techniques apply to both intra- and Such LSP information can enhance LSP reoptimization to provide
inter-domain TEDs. Further, the techniques can be mixed for use with "full network" reoptimization, and can allow traffic fluctuations
to be taken into account. Detailed LSP information may also
facilitate reconfiguration of the Virtual Network Topology (VNT)
[MRN], in which lower layer LSPs such as optical paths provide TE
links for use by the higher layer, since this reconfiguration is
also a "full network" problem.
different domains. The degree of synchronization between the PCE and the Note that synchronization techniques may apply to both intra- and
network is subject to implementation and/or policy. However, better inter-domain TEDs. Further, the techniques can be mixed for use in
synchronization leads to paths that are more likely to succeed. different domains. The degree of synchronization between the PCE and
the network is subject to implementation and/or policy. However,
better synchronization generally leads to paths that are more likely
to succeed.
It must also be highlighted that the PCE may have access to only a It must also be highlighted that the PCE may have access to only a
partial TED: for instance in the case of inter-domain path computation partial TED: for instance in the case of inter-domain path
where each such domain may be managed by different entities. In such computation where each such domain may be managed by different
cases, each PCE may have a access to a partial TED and cooperative entities. In such cases, each PCE may have access to a partial TED
techniques between PCEs may be used to achieve end-to-end path and cooperative techniques between PCEs may be used to achieve
computation without any requirement for any PCE to handle the complete end-to-end path computation without any requirement for any PCE to
TED related to the set of traversed domains by the LSP path in question. handle the complete TED related to the set of traversed domains by
the LSP path in question.
7.8. Stateful Versus Stateless PCEs 6.8. Stateful Versus Stateless PCEs
A PCE can be either stateful or stateless. In the former case, there is A PCE can be either stateful or stateless. In the former case, there
a strict synchronization between the PCE and not only the network states is a strict synchronization between the PCE and not only the network
(in term of topology and resource information), but also the set of states (in term of topology and resource information), but also the
computed paths and reserved resources in use in the network. In other set of computed paths and reserved resources in use in the network.
words, the PCE utilizes information from the TED as well as information In other words, the PCE utilizes information from the TED as well as
about existing paths (for example, TE LSPs) in the network when information about existing paths (for example, TE LSPs) in the
processing new requests. Note that although this allows for optimal path network when processing new requests. Note that although this allows
computation and increased path computation success, stateful PCEs for optimal path computation and increased path computation success,
require reliable state synchronization mechanisms, with potentially stateful PCEs require reliable state synchronization mechanisms, with
significant control plane overhead and the maintenance of a large amount potentially significant control plane overhead and the maintenance of
of data/states (for example, full mesh of TE LSPs). a large amount of data/states (for example, full mesh of TE LSPs).
For example, if there is only one PCE in the domain, all LSP computation For example, if there is only one PCE in the domain, all LSP
is done by this PCE, which can then track all the existing LSPs and stay computation is done by this PCE, which can then track all the
synchronized. However, this could require substantial control plane existing LSPs and stay synchronized. However, this model could
resources to accomplish. If there are multiple PCEs in the network, LSP require substantial control plane resources. If there are multiple
computation and information is distributed among PCEs and the resources PCEs in the network, LSP computation and information is distributed
required is also distributed. However, synchronization issues discussed among PCEs and so the resources required to perform the computations
in Section 6.7 also come into play. are also distributed. However, synchronization issues discussed in
Section 6.7 also come into play.
The maintenance of a stateful database can be non-trivial. However, in The maintenance of a stateful database can be non-trivial. However,
a single centralized PCE environment, a stateful PCE is almost a simple in a single centralized PCE environment, a stateful PCE is almost a
matter of remembering all of the LSPs the PCE has computed, if it can simple matter of remembering all of the LSPs the PCE has computed,
also be known that the LSPs were actually set up, and when they were if it can also be known that the LSPs were actually set up, and when
torn down. Out-of-band TED synchronization can also be complex with they were torn down. Out-of-band TED synchronization can also be
multiple PCE setup in a distributed PCE computation model, and could be complex with multiple PCE setup in a distributed PCE computation
prone to race conditions, scalability concerns, etc. Even if the PCE model, and could be prone to race conditions, scalability concerns,
has detailed information on all paths, priorities, and layers, taking etc. Even if the PCE has detailed information on all paths,
such information into account for path computation could be highly priorities, and layers, taking such information into account for path
complex. PCEs might synchronize state by communicating with each other, computation could be highly complex. PCEs might synchronize state by
but when LSPs are set up using distributed computation performed among communicating with each other, but when LSPs are set up using
several PCEs, the problem of synchronization becomes larger and more distributed computation performed among several PCEs, the problem of
complex. synchronization becomes larger and more complex.
There is benefit in knowing which LSPs exist, and their routing, to There is benefit in knowing which LSPs exist, and their routing, to
support such applications as placing a high priority LSP in a crowded support such applications as placing a high priority LSP in a crowded
network such that it preempts as few other LSPs as possible. Note that network such that it preempts as few other LSPs as possible. Note
that preempting based on the minimum number of links might not result
in the smallest number of LSPs being disrupted. Another application
concerns the construction and maintenance of a Virtual Network
Topology [MRN]. It is also helpful to understand which other LSPs
exist in the network in order to decide how to manage the forward
adjacencies that exist or need to be set up. The cost-benefit of
stateful PCE computation would be helpful to determine if the benefit
in path computation is sufficient to offset the additional drain on
the network and computational resources.
preempting based on the minimum number of links might not result in the Conversely, stateless PCEs do not have to remember any computed path
smallest number of LSPs being disrupted. Another application concerns and each set of request(s) is processed independently of each other.
the construction and maintenance of a Virtual Network Topology [MRN]. For example, stateless PCEs may compute paths based on current TED
It is also helpful to understand which other LSPs exist in the network information, which could be out of sync with actual network state
in order to decide how to manage the forward adjacencies that exist or given other recent PCE-computed paths changes. Note that a PCC may
need to be set up. The cost-benefit of stateful PCE computation would be include a set of previously computed paths in its request, in order
helpful to determine if the benefit in path computation is sufficient to to take them into account, for instance to avoid double bandwidth
offset the additional drain on the network computational resources. accounting, or to try to minimize changes (minimum perturbation
problem).
Conversely, stateless PCEs do not have to remember any computed path and It should be observed that the stateless PCE does operate on
each set of request(s) is processed independently of each other. For information about network state. The TED contains link state and
example, stateless PCEs may compute paths based on current TED bandwidth availability information as distributed by the IGPs or
information, which could be out of sync with actual network state given collected through some other means. This information could be
other recent PCE-computed paths changes. Note that a PCC may include a further enhanced to provide increased granularity and more detail to
set of previously computed paths in its request, in order to take them cover, for example, the current bandwidth usage on certain links
into account, for instance to avoid double bandwidth accounting, or to according to resource affinities or forwarding equivalence classes.
try to minimize changes (minimum perturbation problem). Such information is, however, not PCE state information and so a
model that uses it is still described as stateless in the PCE
context.
7.9. Monitoring A limited form of statefulness might be applied within an otherwise
stateful PCE. The PCE may retain some context from paths it has
recently computed so that it avoid suggesting the use of the same
resources for other LSPs.
6.9. Monitoring
PCE Monitoring is undoubtedly of the utmost importance in any PCE PCE Monitoring is undoubtedly of the utmost importance in any PCE
architecture. This must include the collection of variables related to architecture. This must include the collection of variables related
the PCE status and operation. For example, it will be necessary to to the PCE status and operation. For example, it will be necessary to
understand the way in which the TED is being kept synchronized, the rate understand the way in which the TED is being kept synchronized, the
of arrival of new requests and the computation times, the range of PCCs rate of arrival of new requests and the computation times, the range
that are using the PCE, and the operation of any PCC-PCE protocol. of PCCs that are using the PCE, and the operation of any PCC-PCE
protocol.
7.10. Policy and Confidentiality 6.10. Policy and Confidentiality
As stated in [INTER-AS], the case of inter-provider TE LSP path As stated in [INTER-AS], the case of inter-provider TE LSP path
computation requires the ability to compute a path while preserving computation requires the ability to compute a path while preserving
confidentiality across multiple Service Providers cores. Thus any PCE confidentiality across multiple Service Providers cores. Thus any PCE
architecture solution must support the ability to return partial paths architecture solution must support the ability to return partial
by means of loose hops (for example, where each loose hops would for paths by means of loose hops (for example, where each loose hops
instance identify a boundary LSR). Confidentiality and security of would for instance identify a boundary LSR). Confidentiality and
PCC-PCE and PCE-PCE messages must also be ensured. security of PCC-PCE and PCE-PCE messages must also be ensured.
As mentioned in section 6.9, the ability to compute a path at the The ability to compute a path at the request of the head end PCC, but
request of the head end PCC, but to supply the path in segments to the to supply the path in segments to the domain boundary PCCs may also
domain boundary PCCs may also be desirable. be desirable.
8. PCE Evaluation Metrics 6.11. Unsolicited Interactions
PCE evaluation metrics that may be used to evaluate the efficiency and It may be that the PCC-PCE communications (see section 6.6) can be
applicability of any PCE-based solution are listed below. usefully extended beyond a simple request/response interaction. For
example, the PCE and PCC could exchange capabilities using this
protocol. Additionally, the protocol could be used to collect and
report information in support of a stateful PCE.
- Optimality: The ability to maximize network utilization and minimize Further, it may be the case that a PCE is able to update a path that
cost, considering QoS objectives, multiple regions and network layers. it computed earlier (perhaps in reaction to a change in the network),
and in this case the PCE-PCC communication could support an
"unsolicited" path computation message to supply this new path to the
PCC. It should be noted, however, that this function would require
that the PCE retained a record of previous computations and had a
clear trigger for performing recomputations. The PCC would also need
to be able to identify the new path with the old path and determine
whether it should act on the new path. Note that the PCE-PCC
interaction is not a management interaction and the PCC is not
obliged to utilize any additional path supplied by the PCE.
- Scalability: The implications of routing and signaling overhead These functions fit easily within the architecture described here
(includes LSAs, crankbacks, queries, distribution mechanisms, etc.). but are left for further discussion within separate requirements
documents.
7. Evaluation Metrics
Evaluation metrics that may be used to evaluate the efficiency and
applicability of any PCE-based solution are listed below. Note that
these metrics are not being used to determine paths, but are used to
evaluate potential solutions to the PCE architecture.
- Optimality: The ability to maximize network utilization and
minimize cost, considering QoS objectives, multiple regions and
network layers. Note that models that require the sequential
involvement of multiple PCEs (for example, the multiple PCE model
described in section 5.3) have an inherent risk of lower quality
paths and might create path loops unless careful policy is applied.
- Scalability: The implications of routing, LSP signaling and PCE
communication overhead such as the number of messages and the size
of messages (includes LSAs, crankbacks, queries, distribution
mechanisms, etc.).
- Load sharing: The ability to allow multiple PCEs to spread the path - Load sharing: The ability to allow multiple PCEs to spread the path
computation load. computation load by allowing multiple PCEs to each take
responsibility for a subset of the total path computation requests.
- Multi-path computation: The ability to compute multiple and - Multi-path computation: The ability to compute multiple and
potentially diverse paths to satisfy load-sharing of traffic and potentially diverse paths to satisfy load-sharing of traffic and
protection/restoration needs including end-to-end diversity and protection/restoration needs including end-to-end diversity and
protection within individual domains. protection within individual domains.
- Reoptimization: The ability to perform TE LSP path reoptimization. - Reoptimization: The ability to perform TE LSP path reoptimization.
This also includes the ability to perform inter-layer correlation when This also includes the ability to perform inter-layer correlation
considering the reoptimization at any specific layer. when considering the reoptimization at any specific layer.
- Path computation time. The time to compute individual paths, multiple - Path computation time: The time to compute individual paths,
diverse paths, and to satisfy bulk path computation requests. multiple diverse paths, and to satisfy bulk path computation
requests. (Note that such a metric can only be applied to problems
that are not NP-complete.)
- Network stability: The ability to minimize any perturbation on - Network stability: The ability to minimize any perturbation on
existing TE state resulting from the computation and establishment of existing TE state resulting from the computation and establishment
new TE paths. of new TE paths.
- Ability to maintain accurate synchronization between TED and network - Ability to maintain accurate synchronization between TED and
topology and resource states. network topology and resource states.
- Speed with which TED synchronization is achieved. - Speed with which TED synchronization is achieved.
- Impact of the synchronization process on the data flows in the - Impact of the synchronization process on the data flows in the
network. network.
Note that other metrics may also be considered. Such metrics should be Note that other metrics may also be considered. Such metrics should
used when evaluating a particular PCE-based architecture. It must also be used when evaluating a particular PCE-based architecture. It must
be highlighted that the potential tradeoffs of the optimization of such also be highlighted that the potential tradeoffs of the optimization
metrics should be evaluated (for instance, increasing the path of such metrics should be evaluated (for instance, increasing the
optimality is likely to have consequences on the computation time). path optimality is likely to have consequences on the computation
time).
8. Manageability Considerations
The PCE architecture introduces several elements that are subject to
manageability. The PCE itself must be managed as must its
communications with PCCs and other PCEs. The mechanism by which PCEs
and PCCs discover each other are also subject to manageability.
Many of the issues of manageability are already covered in other
sections of this document.
8.1 Information and Data Models
It is expected that the operations of PCEs and PCCs will be modeled
and controlled through appropriate MIB modules. These will be
relatively simple constructs since the relationships between PCEs and
PCCs are quite simple. The tables in the new MIB modules will need to
reflect the relationships between entities and to control and report
on configurable options.
Statistics gathering will form an important part of the operation of
PCEs. The operator must be able to determine the historical
interactions of a PCC with its PCEs, the performance that it has
seen, and success rate of its requests. Similarly, it is important
for an operator to be able to inspect a PCE and determine its load
and whether an individual PCC is responsible for a disproportionate
amount of the load. It will also be important to be able to record
and inspect statistics about the communications between the PCC and
PCE, including issues such as malformed messages, unauthorized
messages and messages discarded owing to congestion. In this respect
there is clearly an overlap between manageability and security.
Statistics for the PCE architecture can be made available through
appropriate tables in the new MIB modules.
The new MIB modules should also be used to provide notifications
(formerly known as traps) when key thresholds are crossed or when
important events occur. Great care must be exercised to ensure that
the network is not flooded with SNMP notifications. Thus it might be
inappropriate to issue a notification every time that a PCE receives
a request to compute a path. In any case, full control must be
provided through the MIB modules to allow notifications to be
disabled.
8.2 Liveness Detection and Monitoring
Section 6.5 discusses the importance of a PCC being able to detect
the liveness of a PCE. PCE-PCC communications techniques must enable
a PCC to determine the liveness of a PCE both before it sends a
request and in the period between sending a request and receiving a
response.
It is less important for a PCE to know about the liveness of PCCs,
and within the simple request/response model, this is only helpful:
- to gain a predictive view of the likely loading of a PCE in the
future
- to allow a PCE to abandon processing of a received request.
8.3 Verifying Correct Operation
Correct operation for the PCE architecture can be classified as
determining the correct point-to-point connectivity between PCCs and
PCEs, and assessing the validity of the computed paths. The former is
a security issue that may be enhanced by authentication and monitored
through event logging and records as described in Section 8.1.
Verifying computed paths is more complex. The information to perform
this function can, however, be made available to the operator through
MIB tables provided full records are kept of the constraints passed
on the request, the path computed and provided on the response, and
any additional information supplied by the PCE such as the constraint
relaxation policies applied.
8.4 Requirements on Other Protocols and Functional Components
At the architectural stage it is impossible to make definitive
statements about the impact on other protocols and functional
components since the solutions work has not been completed. However,
it is possible to make some observations.
- Dependence on underlying transport protocols
PCE-PCC communications may choose to utilize underlying protocols
to provide transport mechanisms. In this case some of the
manageability considerations described in the previous sections may
be devolved to those protocols.
- Re-use of existing protocols for discovery
Without prejudicing the requirements and solutions work for PCE
discovery (see Section 6.4) it is possible that use will be made of
existing protocols to facilitate this function. In this case some
of the manageability considerations described in the previous
sections may be devolved to those protocols.
- Impact on LSRs and LSP signaling
The primary example of a PCC identified in this architecture is an
MPLS LSR. Consideration must therefore be given to the
manageability of the LSRs and the additional manageability
constraints applicable to the LSP signaling protocols.
As well as allowing the PCC management described in the previous
sections, an LSR must be configurable to determine whether it will
use a remote PCE at all - the options being to use hop-by-hop
routing or to supply the PCE function itself. It is likely to be
important to be able to distinguish within an LSR whether the path
used for an LSP was supplied in a signaling message, by an
operator, or by a PCE, and in the case where it was supplied in a
signaling message whether it was enhanced or expanded by a PCE.
8.5 Impact on Network Operation
This architecture may have two impacts on the operation of a network.
It increases LSP setup times while requests are sent to and processed
by a remote PCE, and it may cause congestion within the network if a
significant number of computation requests are issued in a small
period of time. These issues are most severe in busy networks and
after network failures although the effect may be mitigated if the
protection paths are precomputed.
Issues of potential congestion during recovery from failures may be
mitigated through the use of pre-established protection schemes such
as fast reroute.
It is important that network congestion be managed proactively
because it may be impossible to manage it reactively once the network
is congested. It should be possible for an operator to rate limit the
requests that a PCC sends to a PCE, and a PCE should be able to
report impending congestion (according to a configured threshold)
both to the operator and to its PCCs.
9. Security Considerations 9. Security Considerations
The impact of the use of a PCE-based architecture MUST be considered in The impact of the use of a PCE-based architecture must be considered
the light of the impact that it has on the security of the existing in the light of the impact that it has on the security of the
routing and signaling protocols and techniques in use within the existing routing and signaling protocols and techniques in use within
network. There is unlikely to be any impact on intra-domain security, the network. There is unlikely to be any impact on intra-domain
but an increase in inter-domain information flows and the facilitation security, but an increase in inter-domain information flows and the
of inter-domain path establishment may increase the vulnerability to facilitation of inter-domain path establishment may increase the
security attacks. vulnerability to security attacks.
Of particular relevance are the implications for confidentiality Of particular relevance are the implications for confidentiality
inherent in a PCE-based architecture for multi-domain networks. It is inherent in a PCE-based architecture for multi-domain networks. It is
not necessarily the case that a multi-domain PCE solution will not necessarily the case that a multi-domain PCE solution will
compromise security, but solutions MUST examine their effects in this compromise security, but solutions MUST examine their effects in this
area. area.
Applicability statements for particular combinations of signaling, Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain
routing and path computation techniques are expected to contain detailed detailed security sections.
security sections.
It should be observed that the use of a non-local PCE (that is, not It should be observed that the use of a non-local PCE (that is, not
co-resident with the PCC) does introduce additional security issues. co-resident with the PCC) does introduce additional security issues.
Most notable amongst these are: Most notable amongst these are:
- Interception of PCE requests or responses - Interception of PCE requests or responses
- Impersonation of PCE - Impersonation of PCE
- Falsification of TE information - Falsification of TE information
- Denial of service attacks on PCE or PCE communication mechanisms. - Denial of service attacks on PCE or PCE communication mechanisms.
It is expected that PCE solutions will address these issues in detail It is expected that PCE solutions will address these issues in detail
using authentication and security techniques. using authentication and security techniques.
10. IANA Considerations 10. IANA Considerations
This document makes no requests for IANA action. This informational document makes no requests for IANA action.
11. Acknowledgements 11. Acknowledgements
The authors would like to extend their warmest thanks to (in The authors would like to extend their warmest thanks to (in
alphabetical order) Zafar Ali, Dean Cheng, Kireeti Kompella, Jean-Louis alphabetical order) Arthi Ayyangar, Zafar Ali, Mohamed Boucadair,
Le Roux, Eiji Oki, Dimitri Papadimitriou, and Raymond Zhang for their Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella,
Review and suggestions. Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou,
Richard Rabbat, Takao Shimizu, and Raymond Zhang for their review and
suggestions.
12. Intellectual Property Considerations 12. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might or this document or the extent to which any license under such rights
might not be available; nor does it represent that it has made any might or might not be available; nor does it represent that it has
independent effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
procedures with respect to rights in RFC documents can be found in BCP on the procedures with respect to rights in RFC documents can be
78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt assurances of licenses to be made available, or the result of an
made to obtain a general license or permission for the use of such attempt made to obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification can be such proprietary rights by implementers or users of this
obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary
that may cover technology that may be required to implement this rights that may cover technology that may be required to implement
standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
13. Normative References 13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 3667, February 2004.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
14. Informational References 14. Informational References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and
"Requirements for Traffic Engineering over MPLS", RFC 2702, September J. McManus, "Requirements for Traffic Engineering over
1999. MPLS", RFC 2702, September 1999.
[RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547, March [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547,
1999. March 1999.
[RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP Tunnels", [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP
RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC3630, September 2003.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling - Resource ReserVation
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for [RFC3748] Smit, H. and Li, T., "Intermediate System to
Support of Inter-Area and Inter-AS MPLS Traffic Engineering", Intermediate System (IS-IS) - Extensions for Traffic
draft-ietf-tewg- interarea-mpls-te-req-03.txt, November 2004 (work in Engineering (TE)", RFC3784, June 2004.
progress).
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic
Engineering", RFC 4105, June 2005.
[INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, Engineering requirements",
September 2004 (work in progress). draft-ietf-tewg-interas-mpls-te-req, work in progress.
[MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for [MRN] Shiomoto, K., et. al., "Requirements for GMPLS-based
Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, multi-region and multi-layer networks",
February 2004 (work in progress). draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress.
15. Authors' Addresses 15. Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Phone: +44 (0) 1978 860944
Fax: +44 (0) 870-130-5411
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Jerry Ash Jerry Ash
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578 Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659 Fax: +1-(732)-368-8659
Email: gash@att.com Email: gash@att.com
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject to Copyright (C) The Internet Society (2005). This document is subject
the rights, licenses and restrictions contained in BCP 78, and except as to the rights, licenses and restrictions contained in BCP 78, and
set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/