draft-ietf-pce-architecture-05.txt   rfc4655.txt 
Network Working Group Adrian Farrel
IETF Internet Draft Old Dog Consulting
Proposed Status: Informational Jean-Philippe Vasseur
Expires: October 2006 Cisco Systems, Inc.
Jerry Ash
AT&T
A Path Computation Element (PCE) Based Architecture
Status of this Memo Network Working Group A. Farrel
Request for Comments: 4655 Old Dog Consulting
Category: Informational J.-P. Vasseur
Cisco Systems, Inc.
J. Ash
AT&T
August 2006
By submitting this Internet-Draft, each author represents that any A Path Computation Element (PCE)-Based Architecture
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be Copyright (C) The Internet Society (2006).
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 traffic engineering systems such as Multiprotocol Label Switching
(MPLS) and Generalized Multiprotocol Label Switching (GMPLS) (MPLS) and Generalized Multiprotocol Label Switching (GMPLS)
networks. Path computation in large, multi-domain, multi-region or networks. Path computation in large, multi-domain, multi-region, or
multi-layer networks is complex and may require special multi-layer networks is complex and may require special computational
computational components and cooperation between the different components and cooperation between the different network domains.
network domains.
This document specifies the architecture for a Path Computation This document specifies the architecture for a Path Computation
Element (PCE)-based model to address this problem space. This Element (PCE)-based model to address this problem space. This
document does not attempt to provide a detailed description of all document does not attempt to provide a detailed description of all
the architectural components, but rather it describes a set of the architectural components, but rather it describes a set of
building blocks for the PCE architecture from which solutions may be building blocks for the PCE architecture from which solutions may be
constructed. constructed.
1. Introduction ................................................... 3 Table of Contents
2. Terminology .................................................... 3
3. Definitions .................................................... 4 1. Introduction ....................................................3
4. Motivation for a PCE-based Architecture ........................ 6 2. Terminology .....................................................3
4.1. CPU-intensive Path Computation ............................. 6 3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility ......................................... 7 4.2. Partial Visibility ......................................... 7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............ 7 4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............ 7
4.4. Node Outside the Routing Domain ............................ 8 4.4. Node Outside the Routing Domain ............................ 8
4.5. Network Element Lacks Control Plane or Routing Capability .. 8 4.5. Network Element Lacks Control Plane or Routing Capability .. 8
4.6. Backup Path Computation for Bandwidth Protection ........... 8 4.6. Backup Path Computation for Bandwidth Protection ........... 8
4.7. Multi-Layer Networks ....................................... 8 4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ...................................... 9 4.8. Path Selection Policy ...................................... 9
4.9. Non-Motivations ........................................... 10 4.9. Non-Motivations ........................................... 10
4.9.1. The Whole Internet ................................... 10 4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ...................... 10 4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture ........................ 10 5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................ 10 5.1. Composite PCE Node ........................................11
5.2. External PCE .............................................. 11 5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation ............................. 12 5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE Communication 13 5.4. Multiple PCE Path Computation with Inter-PCE
5.5. Management-Based PCE Usage ................................ 14 Communication .............................................14
5.6. Areas for Standardization ................................. 15 5.5. Management-Based PCE Usage ................................15
6. PCE Architectural Considerations .............................. 15 5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model ............................. 16 6.1. Centralized Computation Model ............................. 16
6.2. Distributed Computation Model ............................. 16 6.2. Distributed Computation Model .............................17
6.3. Synchronization ........................................... 17 6.3. Synchronization ........................................... 17
6.4. PCE Discovery and Load Balancing .......................... 17 6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness .................................... 19 6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE & PCE-PCE Communication ........................... 19 6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ................................... 21 6.7. PCE TED Synchronization ...................................22
6.8. Stateful Versus Stateless PCEs ............................ 22 6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................ 24 6.9. Monitoring ................................................25
6.10. Confidentiality .......................................... 24 6.10. Confidentiality ..........................................25
6.11. Policy ................................................... 24 6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ............................ 25 6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................. 26 6.11.2. Policy Realization ................................28
6.11.3 Type of Policies .................................... 27 6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .......................... 27 6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions ................................. 28 6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback .............................. 28 6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ..................... 29 7. The View from the Path Computation Client ......................31
8. Evaluation Metrics ............................................ 30 8. Evaluation Metrics .............................................32
9. Manageability Considerations .................................. 31 9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................ 31 9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ............................... 32 9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring ......................... 32 9.3. Liveness Detection and Monitoring .........................34
9.5. Verifying Correct Operation ............................... 33 9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional Components . 33 9.5. Requirements on Other Protocols and Functional
9.6. Impact on Network Operation ............................... 34 Components ................................................35
10. Security Considerations ...................................... 34 9.6. Impact on Network Operation ...............................36
11. IANA Considerations .......................................... 34 9.7. Other Considerations ......................................36
12. Acknowledgements ............................................. 35 10. Security Considerations .......................................37
13. Intellectual Property Considerations ......................... 35 11. Acknowledgements ..............................................37
14. Normative References ......................................... 35 12. Informative References ........................................38
15. Informational References ..................................... 36
16. Contact Information .......................................... 37
17. Full Copyright Statement ..................................... 37
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 [RFC3209] and GMPLS [RFC3473] networks.
large, multi-domain networks is complex and may require [RFC2702] describes requirements for traffic engineering in MPLS
special computational components and cooperation between the elements networks, while [RFC4105] and [RFC4216] describe traffic engineering
in different domains. This document specifies the architecture for a requirements in inter-area and inter-AS environments, respectively.
Path Computation Element (PCE)-based model to address this problem
space. Path computation in large, multi-domain networks is complex and may
require special computational components and cooperation between the
elements in different domains. This document specifies the
architecture for a Path Computation Element (PCE)-based model to
address this problem space.
This document describes a set of building blocks for the PCE This document describes a set of building blocks for the PCE
architecture from which solutions may be constructed. For example, it architecture from which solutions may be constructed. For example,
discusses PCE-based implementations including composite, external, it discusses PCE-based implementations including composite, external,
and multiple PCE path computation. Furthermore, it discusses 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, detection of PCE liveness, communication between Path balancing, detection of PCE liveness, communication between Path
Computation Clients (PCCs) and the PCE (PCC-PCE communication) and Computation Clients (PCCs) and the PCE (PCC-PCE communication) and
PCE-PCE communication, Traffic Engineering Database (TED) PCE-PCE communication, Traffic Engineering Database (TED)
synchronization, stateful and stateless PCEs, monitoring, policy and synchronization, stateful and stateless PCEs, monitoring, policy and
confidentiality, and evaluation metrics. confidentiality, and evaluation metrics.
The model of the Internet is to distribute network functionality The model of the Internet is to distribute network functionality
(e.g., routing) within the network. PCE functionality is not intended (e.g., routing) within the network. PCE functionality is not
to contradict this model, and can be used to exactly match the model, intended to contradict this model and can be used to match the model
for example, when the PCE functionality co-exists with each Label exactly, for example, when the PCE functionality coexists with each
Switching Router (LSR) in the network. PCE is also able to augment Label Switching Router (LSR) in the network. PCE is also able to
functionality in the network where the Internet model cannot supply augment functionality in the network where the Internet model cannot
adequate solutions, for example, where traffic engineering supply adequate solutions, for example, where traffic engineering
information is not exchanged between network domains. information is not exchanged between network domains.
2. 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 PCC: Path Computation Client. Any client application requesting a
path 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 network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints (see based on a network graph and applying computational constraints (see
further 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 resource information of the domain. The TED may be fed by Interior
extensions or potentially by other means. Gateway Protocol (IGP) extensions or potentially by other means.
TE LSP: Traffic Engineering MPLS Label Switched Path. TE LSP: Traffic Engineering MPLS Label Switched Path.
3. 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 of computing a network path or route based on a network graph, and of
applying computational constraints during the computation. The PCE applying computational constraints during the computation. The PCE
entity is an application that can be located within a network node or entity is an application that can be located within a network node or
component, on an out-of-network server, etc. For example, a PCE would component, on an out-of-network server, etc. For example, a PCE
be able to compute the path of a TE LSP by operating on the TED and would be able to compute the path of a TE LSP by operating on the TED
considering bandwidth and other constraints applicable to the TE LSP and considering bandwidth and other constraints applicable to the TE
service request. LSP service request.
A domain is any collection of network elements within a common sphere A domain is any collection of network elements within a common sphere
of address management or path computation responsibility. Examples of of address management or path computation responsibility. Examples
domains include IGP areas, Autonomous Systems (ASs), and multiple ASs of domains include IGP areas, Autonomous Systems (ASes), and multiple
within a Service Provider network. Domains of path computation ASes within a Service Provider network. Domains of path computation
responsibility may also exist as sub-domains of areas or ASs. responsibility may also exist as sub-domains of areas or ASes.
In order to fully characterize a PCE and clarify these definitions, In order to fully characterize a PCE and clarify these definitions,
the following important considerations must also be examined: the following important considerations must also be examined:
1) Path computation is applicable in intra-domain, inter-domain, and 1) Path computation is applicable in intra-domain, inter-domain, and
inter-layer contexts. inter-layer contexts.
a. Inter-domain path computation may involve the association of a. Inter-domain path computation may involve the association of
topology, routing and policy information from multiple domains topology, routing, and policy information from multiple domains
from which relationships may be deduced in order to help in from which relationships may be deduced in order to help in
performing path computation. performing path computation.
b. Inter-layer path computation refers to the use of PCE where b. Inter-layer path computation refers to the use of PCE where
multiple layers are involved and when the objective is to multiple layers are involved and when the objective is to
perform path computation at one or multiple layers while taking perform path computation at one or multiple layers while taking
into account topology and resource information at these layers. into account topology and resource information at these layers.
Overlapping domains are not within the scope of this document. In Overlapping domains are not within the scope of this document. In
the inter-domain case, the domains may belong to a single or the inter-domain case, the domains may belong to a single or to
multiple Service Providers. multiple Service Providers.
2) a. In "single PCE path computation," a single PCE is used to 2) a. In "single PCE path computation", a single PCE is used to
compute a given path in a domain. There may be multiple PCEs in compute a given path in a domain. There may be multiple PCEs
a domain, but only one PCE per domain is involved in any single in a domain, but only one PCE per domain is involved in any
path computation. single path computation.
b. In "multiple PCE path computation," multiple PCEs are used to b. In "multiple PCE path computation", multiple PCEs are used to
compute a given path in a domain. compute a given path in a domain.
3) a. "Centralized computation model" refers to a model whereby all 3) a. "Centralized computation model" refers to a model whereby all
paths in a domain are computed by a single, centralized PCE. paths in a domain are computed by a single, centralized PCE.
b. Conversely, "Distributed computation model" refers to the b. Conversely, "distributed computation model" refers to the
computation of paths in a domain being shared among multiple computation of paths in a domain being shared among multiple
PCEs. PCEs.
Paths that span multiple domains may be computed using the Paths that span multiple domains may be computed using the
distributed model with one or more PCEs responsible for each distributed model with one or more PCEs responsible for each
domain, or the centralized model by defining a domain that domain, or the centralized model by defining a domain that
encompasses all of the other domains. encompasses all the other domains.
From these definitions, a centralized computation model inherently From these definitions, a centralized computation model inherently
uses single PCE path computation. However, a distributed uses single PCE path computation. However, a distributed
computation model could use either single PCE path computation or computation model could use either single PCE path computation or
multiple PCE path computations. There would be no such thing as a multiple PCE path computations. There would be no such thing as a
centralized model which uses multiple PCEs. centralized model that 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.
example, a conventional intra-domain solution is to have path For example, a conventional intra-domain solution is to have path
computation performed by the head-end LSR of an MPLS TE LSP; in 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 this case, the head-end LSR contains a PCE. But solutions also
exist where other nodes on the path must contribute to the path exist where other nodes on the path must contribute to the path
computation (for example, loose hops) making them PCEs in their computation (for example, loose hops), making them PCEs in their
own right. At the same time, the path computation may be made by own right. At the same time, the path computation may be made by
some other PCE physically distinct from the computed path. some other PCE physically distinct from the computed path.
5) The path computed by the PCE may be an "explicit path" (that 5) The path computed by the PCE may be an "explicit path" (that is,
is, the full explicit path from start to destination, made of a the full explicit path from start to destination, made of a list
list of strict hops) or a "strict/loose path" (that is, a mix of strict hops) or a "strict/loose path" (that is, a mix of strict
of strict and loose hops comprising at least one loose hop and loose hops comprising at least one loose hop representing the
representing the destination), where a hop may be an abstract node destination), where a hop may be an abstract node such as an AS.
such as an AS.
6) A PCE-based path computation model does not mean to be exclusive 6) A PCE-based path computation model does not mean to be exclusive
and can be used in conjunction with other path computation models. and can be used in conjunction with other path computation models.
For instance, the path of an inter-AS TE LSP may be computed using For instance, the path of an inter-AS TE LSP may be computed using
a PCE-based path computation model in some ASs, whereas the a PCE-based path computation model in some ASes, whereas the set
set of traversed ASs may be specified by other means (not of traversed ASes may be specified by other means (not determined
determined by a PCE). Furthermore, different path computation by a PCE). Furthermore, different path computation models may be
models may be used for different TE LSPs. 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, implementation of a PCE. A PCE could be implemented on a router,
an LSR, a dedicated network server, etc. Moreover, the PCE an LSR, a dedicated network server, etc. Moreover, the PCE
function is orthogonal to the forwarding capability of the node on function is orthogonal to the forwarding capability of the node on
which it is implemented. which it is implemented.
4. Motivation for a PCE-based Architecture 4. Motivation for a PCE-Based Architecture
Several motivations for a PCE-based architecture (described in Several motivations for a PCE-based architecture (described in
Section 5) are listed below. This list is not meant to be exhaustive Section 5) are listed below. This list is not meant to be exhaustive
and is 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 It should be highlighted that the aim of this section is to provide
some application examples for which a PCE-based path may be suitable: some application examples for which a PCE-based path may be suitable:
this also clearly states that such a model does not aim to replace this also clearly states that such a model does not aim to replace
existing path computation models but would apply to specific existing existing path computation models but would apply to specific existing
or future situations. or future situations.
As can be seen from these examples, PCE does not replace the existing As can be seen from these examples, PCE does not replace the existing
Internet model where intelligence is distributed within the network. Internet model where intelligence is distributed within the network.
Instead, it builds on this model and makes use of distributed centers Instead, it builds on this model and makes use of distributed centers
of information or computational ability. PCE should not, therefore, of information or computational ability. PCE should not, therefore,
necessarily be seen as a centralized, "all-seeing oracle in the sky", necessarily be seen as a centralized, "all-seeing oracle in the sky",
but as the cooperative operation of distributed functionality used to but as the cooperative operation of distributed functionality used to
address specific challenges such as the computation of a shortest address specific challenges such as the computation of a shortest
inter-domain constrained path. inter-domain constrained path.
4.1. CPU-intensive Path Computation 4.1. CPU-Intensive Path Computation
There are many situations where the computation of a path may be There are many situations where the computation of a path may be
highly CPU-intensive: examples of CPU-intensive path computations highly CPU-intensive; examples of CPU-intensive path computations
include the resolution of problems such as: include the resolution of problems such as:
- Placing a set of TE LSPs within a domain so - Placing a set of TE LSPs within a domain so as to optimize an
as to optimize an objective function (for example, minimization of objective function (for example, minimization of the maximum link
the maximum link utilization) 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 utilization, inclusion of switching capabilities, adaptation
features, encoding types and optical constraints within a GMPLS features, encoding types and optical constraints within a GMPLS
optical network) 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 some In these situations, it may not be possible or desirable for some
routers to perform path computation because of the constraints on routers to perform path computation because of the constraints on
their CPUs, in which case the path computations may be off-loaded to their CPUs, in which case the path computations may be off-loaded to
some other PCE(s) which may, themselves, be routers or may be some other PCE(s) that may, themselves, be routers or may be
dedicated PCE servers. dedicated PCE servers.
4.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
router attempts to establish a TE LSP to a destination that lies in a ingress router attempts to establish a TE LSP to a destination that
separate domain, since TE information is not exchanged across the lies in a separate domain, since TE information is not exchanged
domain boundaries. In such cases, it is possible to use loose routes across the domain boundaries. In such cases, it is possible to use
to establish the TE LSP, relying on routers at the domain borders to loose routes to establish the TE LSP, relying on routers at the
establish the next piece of the path, however, it is not possible to domain borders to establish the next piece of the path. However, it
guarantee that the optimal (shortest) path will be used, nor even is not possible to guarantee that the optimal (shortest) path will be
that a viable path will be discovered except, possibly, through used, or even that a viable path will be discovered except, possibly,
repeated trial and error using crankback or other signaling through repeated trial and error using crankback or other signaling
extensions. 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, and potentially using crankback between within each of the domains, and potentially using crankback between
the domains to dynamically resolve provisioning issues. the domains to dynamically resolve provisioning issues.
Alternatively, a central "all-seeing" PCE that has access to the Alternatively, a central "all-seeing" PCE that has access to the
complete set of topology information may be used, but in this case complete set of topology information may be used, but in this case
there are challenges of scalability(both the size of the TED and the there are challenges of scalability(both the size of the TED and the
responsiveness of a single PCE handling requests for many domains) responsiveness of a single PCE handling requests for many domains)
and of preservation of confidentiality when the domains belong to and of preservation of confidentiality when the domains belong to
different Service Providers. 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 TE LSP reoptimization, or the establishment of multiple context of TE LSP reoptimization, or the establishment of multiple
diverse TE LSPs for protection or load sharing. diverse TE LSPs for protection or load sharing.
4.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 resources of a network node (such as an edge router or LER).
a memory perspective and because it may require non-negligible CPU Maintaining the TED may require a lot of memory and may require non-
activity to maintain. The use of a distinct PCE may be appropriate in negligible CPU activity. The use of a distinct PCE may be
such circumstances, and a separate node can be used to establish and appropriate in such circumstances, and a separate node can be used to
maintain the TED, and to make it available for path computation. establish and maintain the TED, and to make it available for path
computation.
The IGPs run within some networks are not sufficient to build a full 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 resources are reserved or released. Such a TED could be distributed
to the routers that need to perform path computation, or held to the routers that need to perform path computation or held
centrally (on a distinct node that supports PCE) for centralized centrally (on a distinct node that supports PCE) for centralized
computation. computation.
4.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 provider-edge (PE) router in the context of MPLS VPN [RFC4364] and
for which it is desired to provide a CE to CE TE LSP path). 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 (TE LSP head-end, CE) router, and that computation on the ingress (TE LSP head-end, CE) router, and that
does not rely on the configuration of static loose hops. In this does not rely on the configuration of static loose hops. In this
case, optimal shortest paths can not be guaranteed. A solution that case, optimal shortest paths cannot be guaranteed. A solution that a
a distinct PCE can help here. Note that the PCE in this case may, distinct PCE can help here. Note that the PCE in this case may,
itself, provide a path that includes loose hops. itself, provide a path that includes loose hops.
4.5. Network Element Lacks Control Plane 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 It is common in legacy optical networks for the network elements not
to have a control plane or routing capability. Such network elements to have a control plane or routing capability. Such network elements
only have a data plane and a management plane, and all only have a data plane and a management plane, and all cross-
cross-connections are made from the management plane. It is connections are made from the management plane. It is desirable in
desirable in this case to run the path computation on the PCE, and this case to run the path computation on the PCE, and to send the
send the cross-connection commands to each node on the computed path. cross-connection commands to each node on the computed path. That
That is, the PCC would be an element of the management plane, perhaps is, the PCC would be an element of the management plane, perhaps
residing in the Network Management System (NMS) or Operations Support residing in the Network Management System (NMS) or Operations Support
System (OSS). System (OSS).
This scenario is important for Automatically Switched Optical Network This scenario is important for Automatically Switched Optical Network
(ASON)-capable networks, and may also be used for interworking (ASON)-capable networks and may also be used for interworking between
between GMPLS-capable and GMPLS-incapable networks. GMPLS-capable and GMPLS-incapable networks.
4.6. Backup Path Computation for Bandwidth Protection 4.6. Backup Path Computation for Bandwidth Protection
A PCE can be used to compute backup paths in the context of fast A PCE can be used to compute backup paths in the context of fast
reroute protection of TE LSPs. In this model all backup TE LSPs reroute protection of TE LSPs. In this model, all backup TE LSPs
protecting a given facility are computed in a coordinated manner by a protecting a given facility are computed in a coordinated manner by a
PCE. This allows complete bandwidth sharing between backup tunnels PCE. This allows complete bandwidth sharing between backup tunnels
protecting independent elements, while avoiding any extensions to TE protecting independent elements, while avoiding any extensions to TE
LSP signaling. Both centralized and distributed computation models LSP signaling. Both centralized and distributed computation models
are applicable. In the distributed case each LSR can be a PCE to are applicable. In the distributed case each LSR can be a PCE to
compute the paths of backup tunnels to protect against the failure of compute the paths of backup tunnels to protect against the failure of
adjacent network links or nodes. adjacent network links or nodes.
4.7. Multi-Layer Networks 4.7. Multi-layer Networks
A server-layer network of one switching capability may support A server-layer network of one switching capability may support
multiple networks of another (more granular) switching capability. multiple networks of another (more granular) switching capability.
For example, a TDM network may provide connectivity for client-layer For example, a Time-Division Multiplexing (TDM) network may provide
networks such as IP, MPLS or Layer 2 [MLN]. connectivity for client-layer networks such as IP, MPLS, or Layer 2
[MLN].
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 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 Furthermore, where multiple client-layer networks make use of the
server-layer network, those client-layer networks may have same 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
distinct path computation regions within a PCE domain, and so the PCE distinct path computation regions within a PCE domain, so the PCE
architecture is useful to allow path computation from one architecture is useful to allow path computation from one client-
client-layer network region, across the server-layer network to layer network region, across the server-layer network, to another
another client-layer network region. client-layer network region.
In this case, the PCEs are responsible for resolving address space In this case, the PCEs are responsible for resolving address space
issues, handling differences in policy and control parameters, and issues, handling differences in policy and control parameters, and
coordinating resources between the networks. Note that, because of coordinating resources between the networks. Note that, because of
the differences in bandwidth granularity, connectivity across the the differences in bandwidth granularity, connectivity across the
server-layer network may be provided through virtual TE links or server-layer network may be provided through virtual TE links or
Forwarding Adjacencies: the PCE may offer a point of control Forwarding Adjacencies: the PCE may offer a point of control
responsible for the decision to provision new TE links or Forwarding responsible for the decision to provision new TE links or Forwarding
Adjacencies across the server-layer network. Adjacencies across the server-layer network.
4.8 Path Selection Policy 4.8. Path Selection Policy
A PCE may have a local policy that impacts path computation and A PCE may have a local policy that impacts path computation and
selection in response to a path computation request. Such policy may selection in response to a path computation request. Such policy may
act on information provided by the requesting PCC. The result of act on information provided by the requesting PCC. The result of
applying such policy includes, for example, rejection of the path applying such policy includes, for example, rejection of the path
computation request, or provision of a path that does not meet all computation request, or provision of a path that does not meet all of
of the requested constraints. Further, the policy may support the requested constraints. Further, the policy may support
administratively configured paths, or selection among transit administratively configured paths, or selection among transit
providers. Inclusion of policy within PCE may simplify the providers. Inclusion of policy within PCE may simplify the
application of policy within the path computation/selection process. application of policy within the path computation/selection process.
Similarly, a PCC may apply local policy to the selection of a PCE to Similarly, a PCC may apply local policy to the selection of a PCE to
compute a specific path, and to the constraints that are requested. compute a specific path, and to the constraints that are requested.
In a PCE context, the policy may be sensitive to the type of path In a PCE context, the policy may be sensitive to the type of path
that is being computed. For example, a different set of policies may that is being computed. For example, a different set of policies may
be applied for an intra-area or single-layer path, than would be be applied for an intra-area or single-layer path than would be
provided for an inter-area or multi-layer path. provided for an inter-area or multi-layer path.
Note that synchronization of policy between PCEs or between PCCs and Note that synchronization of policy between PCEs or between PCCs and
PCEs may be necessary. Such issues are outside the scope of the PCE PCEs may be necessary. Such issues are outside the scope of the PCE
architecture, but within scope for the PCE policy framework and architecture, but within scope for the PCE policy framework and
application which is described in a separate document. application which is described in a separate document.
4.9. Non-Motivations 4.9. Non-Motivations
4.9.1. The Whole Internet 4.9.1. The Whole Internet
PCE is not considered to be a solution that is applicable to the PCE is not considered to be a solution that is applicable to the
entire Internet. That is, the applicability of PCE is limited to a entire Internet. That is, the applicability of PCE is limited to a
set of domains with known relationships. The scale of this limitation set of domains with known relationships. The scale of this
is similar to the peering relationships between Service Providers. limitation is similar to the peering relationships between Service
Providers.
4.9.2. Guaranteed TE LSP Establishment 4.9.2. Guaranteed TE LSP Establishment
When two or more paths for TE LSPs are computed on the same set of TE When two or more paths for TE LSPs are computed on the same set of TE
link state information, it is possible that the resultant paths will link state information, it is possible that the resultant paths will
compete for limited resources within the network. This may result in compete for limited resources within the network. This may result in
success for only the first TE LSP to be signaled, or might even mean success for only the first TE LSP to be signaled, or it might even
that no TE LSP can be established. mean that no TE LSP can be established.
Batch processing of computation requests, back-off times, computation Batch processing of computation requests, back-off times, computation
of alternate paths, and crankback can help to mitigate this sort of of alternate paths, and crankback can help to mitigate this sort of
problem, and PCE may also improve the chances of successful TE LSP problem, and PCE may also improve the chances of successful TE LSP
setup. However, a single, centralized PCE is not viewed as a solution setup. However, a single, centralized PCE is not viewed as a
that can guarantee TE LSP establishment since the potential for solution that can guarantee TE LSP establishment since the potential
network failures or contention for resources still exists where the for network failures or contention for resources still exists where
centralized TED cannot fully reflect current (i.e., real-time) the centralized TED cannot fully reflect current (i.e., real-time)
network state. network state.
5. Overview of the PCE-Based Architecture 5. Overview of the PCE-Based Architecture
This section gives an overview of the architecture of the PCE This section gives an overview of the architecture of the PCE model.
model. It needs to be read in conjunction with the details provided It needs to be read in conjunction with the details provided in the
in the next section to provide a full view of the flexibility of the next section to provide a full view of the flexibility of the model.
model.
5.1. Composite PCE Node 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 utilizes path computation. The routing protocol is used to exchange
TE information from which the TED is constructed. Service requests to TE information from which the TED is constructed. Service requests
provision TE LSPs are received by the node and converted into to provision TE LSPs are received by the node and converted into
signaling requests, but this conversion may require path computation signaling requests, but this conversion may require path computation
which is requested from a PCE. The PCE operates on the TED subject to that is requested from a PCE. The PCE operates on the TED subject to
local policy in order to respond with the requested path. local policy in order to respond with the requested path.
--------------- ---------------
| --------- | Routing ---------- | --------- | Routing ----------
| | | | Protocol | | | | | | Protocol | |
| | TED |<-+----------+-> | | | TED |<-+----------+-> |
| | | | | | | | | | | |
| --------- | | | | --------- | | |
| | | | | | | | | |
| | Input | | | | | Input | | |
skipping to change at page 11, line 40 skipping to change at page 12, line 8
Figure 1. Composite PCE Node Figure 1. Composite PCE Node
Note that the routing adjacency between the composite PCE node and Note that the routing adjacency between the composite PCE node and
any other router may be performed by means of direct connectivity or any other router may be performed by means of direct connectivity or
any tunneling mechanism. any tunneling mechanism.
5.2. External PCE 5.2. External PCE
Figure 2 shows a PCE that is external to 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 element. A service request is received by the head-end node, and
before it can initiate signaling to establish the service, it makes before it can initiate signaling to establish the service, it makes a
a path computation request to the external PCE. The PCE uses the TED path computation request to the external PCE. The PCE uses the TED
subject to local policy as input to the computation and returns a subject to local policy as input to the computation and returns a
response. response.
---------- ----------
| ----- | | ----- |
| | TED |<-+-----------> | | TED |<-+----------->
| ----- | TED synchronization | ----- | TED synchronization
| | | mechanism (for example, routing protocol) | | | mechanism (for example, routing protocol)
| | | | | |
| v | | v |
skipping to change at page 12, line 28 skipping to change at page 12, line 37
| 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 Note that in this case, the node that supports the PCE function may
also be an LSR or router performing forwarding in its own right (i.e. also be an LSR or router performing forwarding in its own right
it may be a composite PCE node), but those functions are purely (i.e., it may be a composite PCE node), but those functions are
orthogonal to the operation of the function in the instance being purely orthogonal to the operation of the function in the instance
considered here. being considered here.
5.3. Multiple PCE Path Computation 5.3. Multiple PCE Path Computation
Figure 3 illustrates how multiple PCE path computations may be Figure 3 illustrates how multiple PCE path computations may be
performed along the path of a signaled service. As in the previous performed along the path of a signaled service. As in the previous
example, the head-end PCC makes a request to an external PCE, but the example, the head-end PCC makes a request to an external PCE, but the
path that is returned is such that the next network element finds it path that is returned is such that the next network element finds it
necessary to perform further computation. This may be the case when necessary to perform further computation. This may be the case when
the path returned is a partial path that does not reach the intended the path returned is a partial path that does not reach the intended
destination or when the computed path is loose. The downstream destination or when the computed path is loose. The downstream
network element consults another PCE to establish the next hop(s) in network element consults another PCE to establish the next hop(s) in
the path. In this case, all policy decisions are made independently the path. In this case, all policy decisions are made independently
at each PCE based on information passed from the PCC. at each PCE based on information passed from the PCC.
Note that either or both PCEs in this case could be composite PCE Note that either or both PCEs in this case could be composite PCE
nodes as in Section 5.1. nodes, as in Section 5.1.
---------- ---------- ---------- ----------
| | | | | | | |
| PCE | | PCE | | PCE | | PCE |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | TED | | | | TED | | | | TED | | | | TED | |
| ----- | | ----- | | ----- | | ----- |
---------- ---------- ---------- ----------
^ ^ ^ ^
skipping to change at page 13, line 27 skipping to change at page 14, line 8
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
5.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 requested service, and as a result the adjacent node needs to make
make its own computation request. As illustrated in Figure 4, the its own computation request. As illustrated in Figure 4, the same
same problem may be solved by introducing inter-PCE communication, problem may be solved by introducing inter-PCE communication, and
and cooperation between PCEs so that the PCE consulted by the cooperation between PCEs so that the PCE consulted by the head-end
head-end network node makes a request of another PCE to help with the network node makes a request of another PCE to help with the
computation. computation.
---------- ---------- ---------- ----------
| | Inter-PCE Request/Response | | | | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE | | PCE |<--------------------------------->| PCE |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | TED | | | | TED | | | | TED | | | | TED | |
| ----- | | ----- | | ----- | | ----- |
---------- ---------- ---------- ----------
skipping to change at page 14, line 4 skipping to change at page 14, line 33
^ ^
| 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 distinct PCEs such that the result of the coordination between distinct PCEs such that the result of the
computation performed by one PCE depends on path fragment information computation performed by one PCE depends on path fragment information
supplied by other PCEs. This model does not provide a distributed supplied by other PCEs. This model does not provide a distributed
computation algorithm, but allows distinct PCEs to be responsible for computation algorithm, but it allows distinct PCEs to be responsible
computation of parts (segments) of the path. for computation of parts (segments) of the path.
PCE-PCE communication is discussed further in Section 6.6. PCE-PCE communication is discussed further in Section 6.6.
Note that a PCC might not see the difference between centralized 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 communication. That is, the PCC network node or component that
requests the computation makes a single request and receives a full requests the computation makes a single request and receives a full
or partial path in response, but the response is actually achieved or partial path in response, but the response is actually achieved
through the coordinated, cooperative efforts of more than one PCE. through the coordinated, cooperative efforts of more than one PCE.
In this model, all policy decisions may be made independently at each In this model, all policy decisions may be made independently at each
PCE based on computation information passed from the previous PCE. PCE based on computation information passed from the previous PCE.
Alternatively, there may be explicit communication of policy Alternatively, there may be explicit communication of policy
information between PCEs. information between PCEs.
5.5 Management-Based PCE Usage 5.5. Management-Based PCE Usage
It must be observed that the PCC is not necessarily an LSR. For It must be observed that the PCC is not necessarily an LSR. For
example, in Figure 5 the NMS supplies the head-end LSR with a fully example, in Figure 5 the NMS supplies the head-end LSR with a fully
computed explicit path for the TE LSP that it is to establish through computed explicit path for the TE LSP that it is to establish through
signaling. The NMS uses a management plane mechanism to send this signaling. The NMS uses a management plane mechanism to send this
request, and encodes the data using a representation such as the TE request and encodes the data using a representation such as the TE
MIB module [RFC3812]. MIB module [RFC3812].
The NMS constructs the explicit path that it supplies to the head-end The NMS constructs the explicit path that it supplies to the head-end
LSR using information provided by the operator. It consults the PCE LSR using information provided by the operator. It consults the PCE,
which returns a path for the NMS to use. which returns a path for the NMS to use.
Although Figure 5 shows the PCE as remote from the NMS it could, of Although Figure 5 shows the PCE as remote from the NMS, it could, of
course, be collocated with the NMS. course, be collocated with the NMS.
----------- -----------
| ----- | | ----- |
Service | | TED |<-+-----------> Service | | TED |<-+----------->
Request | ----- | TED synchronization Request | ----- | TED synchronization
| | | | mechanism (for example, | | | | mechanism (for example,
v | | | routing protocol) v | | | routing protocol)
------------- Request/ | v | ------------- Request/ | v |
| | Response| ----- | | | Response| ----- |
skipping to change at page 15, line 24 skipping to change at page 15, line 45
| | | ----- | | | | ----- |
------------- ----------- ------------- -----------
Service | Service |
Request | Request |
v v
---------- Signaling ---------- ---------- Signaling ----------
| Head-End | Protocol | Adjacent | | Head-End | Protocol | Adjacent |
| Node |<---------->| Node | | Node |<---------->| Node |
---------- ---------- ---------- ----------
Figure 5. Management-based PCE Usage Figure 5. Management-Based PCE Usage
5.6 Areas for Standardization 5.6. Areas for Standardization
The following areas require standardization within the PCE The following areas require standardization within the PCE
architecture. architecture.
- communication between PCCs and PCEs, and between cooperating PCEs, - communication between PCCs and PCEs, and between cooperating PCEs,
including the communication of policy related information including the communication of policy-related information
- requirements for extending existing routing and signaling protocols - requirements for extending existing routing and signaling protocols
in support of PCE discovery and signaling of inter-domain paths in support of PCE discovery and signaling of inter-domain paths
- definition of metrics to evaluate path quality, scalability, - definition of metrics to evaluate path quality, scalability,
responsiveness, robustness and policy support of path computation responsiveness, robustness, and policy support of path computation
models models.
- MIB modules related to communication protocols, routing and - MIB modules related to communication protocols, routing and
signaling extensions, metrics, and PCE monitoring information. signaling extensions, metrics, and PCE monitoring information
6. PCE Architectural Considerations 6. PCE Architectural Considerations
This section provides a list of the PCE architectural components. This section provides a list of the PCE architectural components.
Specific realizations and implementation details (state machines or Specific realizations and implementation details (state machines or
algorithms, etc.) of PCE-based solutions are out of the scope of this algorithms, etc.) of PCE-based solutions are out of the scope of this
document. document.
Note also that PCE-based path computation does not affect in any way Note also that PCE-based path computation does not affect in any way
the use of the computed paths. For example, the use of PCE does not the use of the computed paths. For example, the use of PCE does not
change the way in which Traffic Engineering LSPs are signaled, change the way in which Traffic Engineering LSPs are signaled,
maintained and torn down, but strictly relates to the path maintained, and torn down, but it strictly relates to the path
computation aspects of such TE LSPs. computation aspects of such TE LSPs.
This section presents an architectural view of PCE. That is, it This section presents an architectural view of PCE. That is, it
describes the components that exist and how they interact. Note that describes the components that exist and how they interact. Note that
the architectural model, and in particular the functional model, may the architectural model, and in particular the functional model, may
be perceived differently by different components of the PCE system. be perceived differently by different components of the PCE system.
For example, the PCC will not be aware of whether a PCE consults For example, the PCC will not be aware of whether a PCE consults
other PCEs. The PCC view of the PCE architecture is discussed in other PCEs. The PCC view of the PCE architecture is discussed in
Section 7. Section 7.
6.1. Centralized Computation Model 6.1. Centralized Computation Model
A "centralized computation model" considers that all path A "centralized computation model" considers that all path
computations for a given domain will be performed by a single, computations for a given domain will be performed by a single,
centralized PCE. This may be a dedicated server (for example, an centralized PCE. This may be a dedicated server (for example, an
external PCE node), or a designated router (for example, a composite external PCE node), or a designated router (for example, a composite
PCE node) in the network. In this model, all PCCs in the domain would PCE node) in the network. In this model, all PCCs in the domain
send their path computation requests to the central PCE. While a would send their path computation requests to the central PCE. While
domain in this context might be an IGP area or AS, it might also be a a domain in this context might be an IGP area or AS, it might also be
sub-group of network nodes that is defined by its dependence on the a sub-group of network nodes that is defined by its dependence on the
PCE. PCE.
This model has a single point of failure: the PCE. In order to avoid This model has a single point of failure: the PCE. In order to avoid
this issue, the centralized computation model may designate a backup this issue, the centralized computation model may designate a backup
PCE that can take over the computation responsibility in a controlled PCE that can take over the computation responsibility in a controlled
manner in the event of a failure of the primary PCE. Any policies manner in the event of a failure of the primary PCE. Any policies
present on the primary PCE should also be present on the backup, present on the primary PCE should also be present on the backup,
although the primary policies may themselves be subject to policy although the primary policies may themselves be subject to policy
governing how they are implemented on the backup. Note that at any governing how they are implemented on the backup. Note that at any
moment in time there is only one active PCE in any domain. moment in time there is only one active PCE in any domain.
6.2. Distributed Computation Model 6.2. Distributed Computation Model
A "distributed computation model" refers to a domain or network that A "distributed computation model" refers to a domain or network that
may include multiple PCEs, and where computation of paths is shared may 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 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 ("single PCE path computation") or multiple PCEs ("multiple PCE path
computation"). A PCC may be linked to a particular PCE, or may be computation"). A PCC may be linked to a particular PCE or may be
able to choose freely among several PCEs - the method of choice able to choose freely among several PCEs; the method of choice
between PCEs is out of scope of this document, but see Section 6.4 between PCEs is out of scope of this document, but see Section 6.4
for a discussion of PCE discovery which impacts on this choice. for a discussion of PCE discovery that affects this choice.
Implementation of policy should be consistent across the set of Implementation of policy should be consistent across the set of
available PCEs. available PCEs.
It will often be the case that the computation of an individual path Often, the computation of an individual path is performed entirely by
is performed entirely by a single PCE. For example, this is usually a single PCE. For example, this is usually the case in MPLS TE
the case in MPLS TE within a single IGP area where the ingress LSR / within a single IGP area where the ingress LSR/composite PCE node is
composite PCE node is responsible for computing the path or for responsible for computing the path or for contacting an external PCE.
contacting an external PCE. Conversely, multiple PCE path computation Conversely, multiple PCE path computation implies that more than one
implies that more than one PCE is involved in the computation of a PCE is involved in the computation of a single path. An example of
single path. An example of this is where loose hop expansion is this is where loose hop expansion is performed by transit
performed by transit LSRs / composite PCE nodes on an MPLS TE LSP. LSRs/composite PCE nodes on an MPLS TE LSP. Another example is the
Another example is the use of multiple cooperating PCEs to compute use of multiple cooperating PCEs to compute the path of a single TE
the path of a single TE LSP across multiple domains. LSP across multiple domains.
6.3. Synchronization 6.3. Synchronization
It is often the case that multiple paths need to be computed to Often, multiple paths need to be computed to support a single service
support a single service (for example, for protection or load (for example, for protection or load sharing). A PCC that determines
sharing). A PCC that determines that it requires more than one path that it requires more than one path to be computed may send a series
to be computed may send a series of individual requests to the PCE. of individual requests to the PCE. In this case of non-synchronized
In this case of non-synchronized path computation requests, the PCE path computation requests, the PCE may make multiple individual path
may make multiple individual path computations to generate the paths computations to generate the paths, and the PCC may send its
and the PCC may send its individual requests to different PCEs. individual requests to different PCEs.
Alternatively, the PCC may send a single request to a PCE asking for Alternatively, the PCC may send a single request to a PCE asking for
a set of paths to be computed, but specifying that non-synchronized a set of paths to be computed, but specifying that non-synchronized
path computation is acceptable. The PCE may compute each path in turn path computation is acceptable. The PCE may compute each path in
exactly as it would have done had the PCC made multiple requests, and turn exactly as it would have done had the PCC made multiple
the PCE may devolve some computations to other PCEs if it chooses. On requests, and the PCE may devolve some computations to other PCEs if
the other hand, the PCE is not prohibited from performing all it chooses. On the other hand, the PCE is not prohibited from
computations together in a synchronized manner as described below. performing all computations together in a synchronized manner as
described below.
The PCC may also issue a single request to the PCE asking for all of The PCC may also issue a single request to the PCE asking for all the
the paths to be computed in a synchronized manner. The PCE will then paths to be computed in a synchronized manner. The PCE will then
perform simultaneous computation of the set of requested paths. Such perform simultaneous computation of the set of requested paths. Such
synchronized computation can often provide better results. synchronized computation can often provide better results.
The involvement of more than one PCE in the computation of a series The involvement of more than one PCE in the computation of a series
of paths is by its nature non-synchronized. However, a set of of paths is by its nature non-synchronized. However, a set of
cooperating PCEs may be synchronized under the control of a single cooperating PCEs may be synchronized under the control of a single
PCE. For example, a PCC may send a request to a PCE which invokes PCE. For example, a PCC may send a request to a PCE that invokes
domain-specific computations by other PCEs before supplying a result domain-specific computations by other PCEs before supplying a result
to the PCC. to the PCC.
It is desirable to add a parameter to the PCC-PCE protocol to request 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 that the PCE supply a set of alternate paths for use by the PCC,
should the establishment of the TE LSP using the principal path fail should the establishment of the TE LSP using the principal path fail
to complete. While alternate paths may not always be successful if to complete. While alternate paths may not always be successful if
the first path fails, including alternate paths in a PCE response the first path fails, including alternate paths in a PCE response
could have less overhead than having the PCC make separate requests could have less overhead than having the PCC make separate requests
for subsequent path computations as the need arises. This technique for subsequent path computations as the need arises. This technique
is used in some existing CSPF implementations. is used in some existing CSPF implementations.
6.4. PCE Discovery and Load Balancing 6.4. PCE Discovery and Load Balancing
In order that a PCC can communicate efficiently with a PCE, it must In order that a PCC can communicate efficiently with a PCE, it must
know the location of the PCE. That is, it is an architectural know the location of the PCE. That is, it is an architectural
decision made here that PCC requests are targeted to a specific PCE, decision made here that PCC requests be targeted to a specific PCE,
and not broadcast to the network for any PCE to respond. This and not broadcast to the network for any PCE to respond. This
decision means that only the selected PCE will operate on any single decision means that only the selected PCE will operate on any single
request, and saves network resources during request propagation and request, and it saves network resources during request propagation
processing resources at the PCEs that are not required to respond. and processing resources at the PCEs that are not required to
respond.
The knowledge of the location of a PCE may be achieved through local The knowledge of the location of a PCE may be achieved through local
configuration at the PCC, or may rely on a protocol-based discovery configuration at the PCC or may rely on a protocol-based discovery
mechanism that may be governed by policy. mechanism that may be governed by policy.
Where there is more than one PCE known to a PCC, the PCC must have Where more than one PCE is known to a PCC, the PCC must have
sufficient information to select an appropriate PCE for its purposes, sufficient information to select an appropriate PCE for its purposes,
under the control of policy. Such a selection procedure allows for under the control of policy. Such a selection procedure allows for
load sharing between PCEs, and supports PCEs with different load sharing between PCEs and supports PCEs with different
computation capabilities including different visibility scopes. Thus, computation capabilities including different visibility scopes.
the information available to the PCC must include details of the PCE Thus, the information available to the PCC must include details of
capabilities, which may be fixed or may vary dynamically in time. the PCE capabilities, which may be fixed or may vary dynamically in
time.
The PCC may learn PCE capabilities through static configuration or it The PCC may learn PCE capabilities through static configuration, or
may discover the information dynamically. Note that even when the it may discover the information dynamically. Note that even when the
location of the PCE is configured at the PCC, the PCC may still location of the PCE is configured at the PCC, the PCC may still
discover the PCE capabilities dynamically. Dynamic PCE capabilities discover the PCE capabilities dynamically. Dynamic PCE capabilities
cannot be configured and can only be discovered. cannot be configured and can only be discovered.
Proxy PCE advertisement whereby the existence of a PCE is advertised Proxy PCE advertisement whereby the existence of a PCE is advertised
via a proxy PCE is a viable alternative, should the PCE be incapable via a proxy PCE is a viable alternative, should the PCE be incapable
of such advertisement itself. In this case, it is a requirement for of such advertisement itself. In this case, it is a requirement that
the proxy to adequately advertise the PCE status and capability in a the proxy adequately advertise the PCE status and capability in a
timely and synchronized fashion. timely and synchronized fashion.
In the event that multiple PCEs are available to serve a particular In the event that multiple PCEs are available to serve a particular
path computation request, the PCC must select a PCE to satisfy the path computation request, the PCC must select a PCE to satisfy the
request. The details of such a selection, in order for instance to request. The details of such a selection (for instance, to
efficiently share the computation load across multiple PCEs, or to efficiently share the computation load across multiple PCEs or to
request secondary computations after partial or failed computations, request secondary computations after partial or failed computations)
is local to the PCC, may be based on policy and out of the scope of are local to the PCC, may be based on policy, and are out of the
this document. scope of this document.
PCE capabilities that may be advertised or configured could include PCE capabilities that may be advertised or configured could include
(and not be limited to): (and are not be limited to):
- a set of constraints that it can account for (diversity, shared
risk link groups (SRLGs), optical impairments, wavelength
continuity, etc.)
- set of constraints that it can account for (diversity, SRLGs,
Optical impairments, wavelength continuity, etc.)
- computational capacity (for example, the number of computations it - computational capacity (for example, the number of computations it
can perform per second) can perform per second)
- number of switching capability layers (and which ones)
- number of path selection criteria (and which ones) - the number of switching capability layers (and which ones)
- whether it is a stateless PCE or it can send updates about
better paths that might be available in the future - the number of path selection criteria (and which ones)
- whether it is a stateless PCE or it can send updates about 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 to decide which PCE to use. This information would help a PCC to decide which PCE to use.
Requirements for PCE advertisement will be documented separately. Requirements for PCE advertisement will be documented separately.
Note that there is no restriction within the architecture about how Note that there is no restriction within the architecture about how
location and capabilities are advertised, and the two elements should location and capabilities are advertised, and the two elements should
be considered to be functionally distinct. be considered functionally distinct.
A PCC might also ask a PCE to perform a particular type of service A PCC might also ask a PCE to perform a particular type of service
without knowledge of the PCE's capabilities, and receive a response without knowledge of the PCE's capabilities and receive a response
that says that the PCE is unable to perform the service. The that says that the PCE is unable to perform the service. The
response could specify the capabilities of the PCE and might also response could specify the capabilities of the PCE and might also
suggest another PCE that has the requested capabilities. suggest another PCE that has the requested capabilities.
6.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 form of regular advertisement (such as through IGP extensions) is
used 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 determined by means of status advertisement (for example, IGP
LSA/LSPs). LSA/LSPs).
The inability of a PCE to service a request (perhaps due to excessive The inability of a PCE to service a request (perhaps due to excessive
load) may be reported to the PCC through a failure message, but the load) may be reported to the PCC through a failure message, but the
failure of a PCE or the communications mechanism while processing a failure of a PCE or the communications mechanism while processing a
request cannot be reported in this way. Further, in the case of request cannot be reported in this way. Furthermore, in the case of
excessive load, the PCE may not have sufficient resources to send a excessive load, the PCE may not have sufficient resources to send a
failure message. Thus the PCC should employ other mechanisms such as failure message. Thus, the PCC should employ other mechanisms, such
protocol timers to determine the liveness of the PCE. This is as protocol timers, to determine the liveness of the PCE. This is
particularly important in the case of inter-domain path computation particularly important in the case of inter-domain path computation
where the PCE liveness may not be detected by means of the IGP that where the PCE liveness may not be detected by means of the IGP that
runs in the PCC's domain. runs in the PCC's domain.
6.6. PCC-PCE & PCE-PCE Communication 6.6. PCC-PCE and PCE-PCE Communication
Once the PCC has selected a PCE, and provided that the PCE is not Once the PCC has selected a PCE, and provided that the PCE is not
local to the PCC, a request/response protocol is required for the PCC local to the PCC, a request/response protocol is required for the PCC
to communicate the path computation requests to the PCE and for the to communicate the path computation requests to the PCE and for the
PCE to return the path computation response. Discussion of the PCE to return the path computation response. Discussion of the
security requirements and implications for this protocol is provided security requirements and implications for this protocol is provided
in Section 10 of this document. in Section 10 of this document.
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 following:
- the source and destination of the path - the source and destination of the path
- the bandwidth and other QoS parameters desired
- resources, resource affinities and shared risk link groups (SRLGs) - the bandwidth and other Quality of Service (QoS) parameters desired
- resources, resource affinities, and shared risk link groups (SRLGs)
to use/avoid to use/avoid
- the number of disjoint paths required and if near-disjoint paths
are acceptable - the number of disjoint paths required and whether near-disjoint
- the levels of resiliency, reliability and robustness of the path paths are acceptable
- the levels of resiliency, reliability, and robustness of the path
resources resources
- policy related information.
- policy-related information
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. assessment of the vulnerability of the resources that may be used.
For example, one might grade resources based on empirical evidence For example, one might grade resources based on empirical evidence
(mean time between failures), on known risks (there is major building (mean time between failures), on known risks (there is major building
work going on near this conduit), or on prejudice (vendor X's work going on near this conduit), or on prejudice (vendor X's
software is always crashing). A PCC could request that only robust software is always crashing). A PCC could request that only robust
resources be used, or allow any resource. resources be used, or it could allow any resource.
In case of a positive response from the PCE, one or more paths would In case of a positive response from the PCE, one or more paths would
be returned to the requesting node. In the event of a failure to be returned to the requesting node. In the event of a failure to
compute the desired path(s), an error is returned together with as compute the desired path(s), an error is returned together with as
much information as possible about the reasons for the failure(s), much information as possible about the reasons for the failure(s),
and potentially with advice about which constraints might be relaxed and potentially with advice about which constraints might be relaxed
to be more likely to achieve a positive result in a future request. so that a positive result is more likely 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 loose hops, or any combination of strict and loose hops. Moreover, a
hop 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 path computation requests to another PCE and for the PCE to return
the path computation response. The path computation request may the path computation response. The path computation request may
include a significant set of requirements including those defined include a significant set of requirements including those defined
above. In case of a positive response from the PCE, one or more paths above. In case of a positive response from the PCE, one or more
would be returned to the requesting PCE. In the event of a failure to paths would be returned to the requesting PCE. In the event of a
compute the desired path(s), an error is returned together with as failure to compute the desired path(s), an error is returned together
much information as possible about the reasons for the failure, and with as much information as possible about the reasons for the
potentially advice about which constraints might be relaxed to be failure, and potentially advice about which constraints might be
more likely to achieve a positive result. Note that the resultant relaxed so that a positive result is more likely. Note that the
path(s) may be made up of a set of strict or loose hops, or any resultant path(s) may be made up of a set of strict or loose hops, or
combination of strict and loose hops. Moreover, a hop may have the any combination of strict and loose hops. Moreover, a hop may have
form of a non-explicit abstract node. the form of a non-explicit abstract node.
An important feature of PCEs that are cooperating to compute a path An important feature of PCEs that are cooperating to compute a path
is that they apply compatible or identical computation algorithms and is that they apply compatible or identical computation algorithms and
coordinated policies. This may require coordination through the coordinated policies. This may require coordination through the
communication between the PCEs. communication between the PCEs.
Note that when multiple PCEs cooperate to compute a path it is Note that when multiple PCEs cooperate to compute a path, it is
important that they have a coordinated view of the meaning of important that they have a coordinated view of the meaning of
constraints such as costs, resource affinities and class of service. constraints such as costs, resource affinities, and class of service.
This is particularly significant where the PCEs are responsible for This is particularly significant where the PCEs are responsible for
different domains. It is assumed that this is a matter of policy different domains. It is assumed that this is a matter of policy
between domains and between PCEs. between domains and between PCEs.
No assumption is made in this architecture about whether the PCC-PCE No assumption is made in this architecture about whether the PCC-PCE
and PCE-PCE communication protocols are identical. and PCE-PCE communication protocols are identical.
6.7. PCE TED Synchronization 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 network status to build the TED may be provided in the domain by
various means: various means:
1) Participation in IGP distribution of TE information. The standard 1) Participation in IGP distribution of TE information. The standard
method of distribution of TE information within an IGP area is method of distribution of TE information within an IGP area is
through the use of extensions to the IGP [RFC3630, RFC3748]. This through the use of extensions to the IGP [RFC3630, RFC3748]. This
mechanism allows participating nodes to build a TED, and this is mechanism allows participating nodes to build a TED, and this is
the standard technique, for example, within a single area MPLS the standard technique, for example, within a single area MPLS or
or GMPLS network. A node that hosts the PCE function may collect GMPLS network. A node that hosts the PCE function may collect TE
TE information in this way by maintaining at least one routing information in this way by maintaining at least one routing
adjacency with a router in the domain. The PCE node may be adjacency with a router in the domain. The PCE node may be
adjacent or non-adjacent (via some tunneling techniques) to the adjacent or non-adjacent (via some tunneling techniques) to the
router. Such a technique provides a mechanism for ensuring that router. Such a technique provides a mechanism for ensuring that
the TED is efficiently synchronized with the network state and is the TED is efficiently synchronized with the network state and is
the normal case, for example, when the PCE is co-resident with the the normal case, for example, when the PCE is co-resident with the
LSRs in an MPLS or GMPLS network. LSRs in an MPLS or GMPLS 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 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 TE-aware IGPs). In this case, some mechanism may need to be
to allow the PCE node to retrieve the TED from each domain. Such a defined to allow the PCE node to retrieve the TED from each
mechanism could be incremental (like the IGP in the previous domain. Such a mechanism could be incremental (like the IGP in
case), or could involve a bulk transfer of the complete TED. The the previous case), or it could involve a bulk transfer of the
latter might significantly limit the capability to ensure TED complete TED. The latter might significantly limit the capability
synchronization which might result in an increase in the failure to ensure TED synchronization, which might result in an increase
rate of computed paths, or the computation of sub-optimal paths. in the failure rate of computed paths, or the computation of sub-
Consideration should also be given to the impact of the TED optimal paths. Consideration should also be given to the impact
distribution on the network and on the network node within the of the TED distribution on the network and on the network node
domain that is asked to distribute the database. This is within the domain that is asked to distribute the database. This
particularly relevant in the case of frequent network state is particularly relevant in the case of frequent network state
changes. changes.
3) Information in the TED can include information obtained from 3) Information in the TED can include information obtained from
sources other than the IGP. For example, information about link sources other than the IGP. For example, information about link
usage policies can be configured by the operator. Path computation usage policies can be configured by the operator. Path
can also act on a far wider set of information that includes data computation can also act on a far wider set of information that
about the TE LSPs provisioned within the network. This information includes data about the TE LSPs provisioned within the network.
can include TE LSP routes, reserved bandwidth, and measured This information can include TE LSP routes, reserved bandwidth,
traffic volume passing through the TE LSP. and measured traffic volume passing through the TE LSP.
Such TE LSP information can enhance TE LSP (re)optimization to Such TE LSP information can enhance TE LSP (re)optimization to
provide "full network" (re)optimization, and can allow traffic provide "full network" (re)optimization and can allow traffic
fluctuations to be taken into account. Detailed TE LSP information fluctuations to be taken into account. Detailed TE LSP
may also facilitate reconfiguration of the Virtual Network information may also facilitate reconfiguration of the Virtual
Topology (VNT) [MLN], in which lower layer TE LSPs such as optical Network Topology (VNT) [MLN], in which lower-layer TE LSPs, such
paths provide TE links for use by the higher layer, since this as optical paths, provide TE links for use by the higher layer,
reconfiguration is also a "full network" problem. since this reconfiguration is also a "full network" problem.
Note that synchronization techniques may apply to both intra- and Note that synchronization techniques may apply to both intra- and
inter-domain TEDs. Further, the techniques can be mixed for use in inter-domain TEDs. Furthermore, the techniques can be mixed for use
different domains. The degree of synchronization between the PCE and in different domains. The degree of synchronization between the PCE
the network is subject to implementation and/or policy. However, and the network is subject to implementation and/or policy. However,
better synchronization generally leads to paths that are more likely better synchronization generally leads to paths that are more likely
to succeed. to succeed.
It must also be highlighted that the PCE may have access to only a Note also that the PCE may have access to only a partial TED: for
partial TED: for instance in the case of inter-domain path instance, in the case of inter-domain path computation where each
computation where each such domain may be managed by different such domain may be managed by different entities. In such cases,
entities. In such cases, each PCE may have access to a partial TED each PCE may have access to a partial TED, and cooperative techniques
and cooperative techniques between PCEs may be used to achieve between PCEs may be used to achieve end-to-end path computation
end-to-end path computation without any requirement for any PCE to without any requirement that any PCE handle the complete TED related
handle the complete TED related to the set of traversed domains by to the set of traversed domains by the TE LSP in question.
the TE LSP in question.
6.8. Stateful Versus Stateless PCEs 6.8. Stateful versus Stateless PCEs
A PCE can be either stateful or stateless. In the former case, there A PCE can be either stateful or stateless. In the former case, there
is a strict synchronization between the PCE and not only the network is a strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network. set of computed paths and reserved resources in use in the network.
In other words, the PCE utilizes information from the TED as well as In other words, the PCE utilizes information from the TED as well as
information about existing paths (for example, TE LSPs) in the information about existing paths (for example, TE LSPs) in the
network when processing new requests. Note that although this allows network when processing new requests. Note that although this allows
for optimal path computation and increased path computation success, for optimal path computation and increased path computation success,
stateful PCEs require reliable state synchronization mechanisms, with stateful PCEs require reliable state synchronization mechanisms, with
potentially significant control plane overhead and the maintenance of potentially significant control plane overhead and the maintenance of
a large amount 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 TE LSP For example, if there is only one PCE in the domain, all TE LSP
computation is done by this PCE, which can then track all the computation is done by this PCE, which can then track all the
existing TE LSPs and stay synchronized (each TE LSP state change must existing TE LSPs and stay synchronized (each TE LSP state change must
be tracked by the PCE). However, this model could require substantial be tracked by the PCE). However, this model could require
control plane resources. If there are multiple PCEs in the network, substantial control plane resources. If there are multiple PCEs in
TE LSP computation and information is distributed among PCEs and so the network, TE LSP computation and information are distributed among
the resources required to perform the computations are also PCEs and so the resources required to perform the computations are
distributed. However, synchronization issues discussed in Section 6.7 also distributed. However, synchronization issues discussed in
also come into play. Section 6.7 also come into play.
The maintenance of a stateful database can be non-trivial. However, The maintenance of a stateful database can be non-trivial. However,
in a single centralized PCE environment, a stateful PCE is almost a in a single centralized PCE environment, a stateful PCE is almost a
simple matter of remembering all of the TE LSPs the PCE has computed, simple matter of remembering all the TE LSPs the PCE has computed,
if it can also be known that the TE LSPs were actually set up, and that the TE LSPs were actually set up (if this can be known), and
when they were torn down. Out-of-band TED synchronization can also be when they were torn down. Out-of-band TED synchronization can also
complex with multiple PCE setup in a distributed PCE computation be complex, with multiple PCE setup in a distributed PCE computation
model, and could be prone to race conditions, scalability concerns, model, and could be prone to race conditions, scalability concerns,
etc. Even if the PCE has detailed information on all paths, etc. Even if the PCE has detailed information on all paths,
priorities, and layers, taking such information into account for path priorities, and layers, taking such information into account for path
computation could be highly complex. PCEs might synchronize state by computation could be highly complex. PCEs might synchronize state by
communicating with each other, but when TE LSPs are set up using communicating with each other, but when TE LSPs are set up using
distributed computation performed among several PCEs, the problems of distributed computation performed among several PCEs, the problems of
synchronization and race condition avoidance become larger and more synchronization and race condition avoidance become larger and more
complex. complex.
There is benefit in knowing which TE LSPs exist, and their routing, There is benefit in knowing which TE LSPs exist, and their routing,
to support such applications as placing a high priority TE LSP in a to support such applications as placing a high-priority TE LSP in a
crowded network such that it preempts as few other TE LSPs as crowded network such that it preempts as few other TE LSPs as
possible (also known as the "minimal perturbation" problem). Note possible (also known as the "minimal perturbation" problem). Note
that preempting based on the minimum number of links might not result that preempting based on the minimum number of links might not result
in the smallest number of TE LSPs being disrupted. Another in the smallest number of TE LSPs being disrupted. Another
application concerns the construction and maintenance of a Virtual application concerns the construction and maintenance of a Virtual
Network Topology [MLN]. It is also helpful to understand which other Network Topology [MLN]. It is also helpful to understand which other
TE LSPs exist in the network in order to decide how to manage the TE 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 forward adjacencies that exist or need to be set up. The cost-
of stateful PCE computation would be helpful to determine if the benefit of stateful PCE computation would be helpful to determine if
benefit in path computation is sufficient to offset the additional the benefit in path computation is sufficient to offset the
drain on the network and computational resources. additional drain on the network and computational resources.
Conversely, stateless PCEs do not have to remember any computed path Conversely, stateless PCEs do not have to remember any computed path
and each set of request(s) is processed independently of each other. and each set of request(s) is processed independently of each other.
For example, stateless PCEs may compute paths based on current TED For example, stateless PCEs may compute paths based on current TED
information, which could be out of sync with actual network state information, which could be out of sync with actual network state
given other recent PCE-computed paths changes. Note that a PCC may given other recent PCE-computed paths changes. Note that a PCC may
include a set of previously computed paths in its request, in order include a set of previously computed paths in its request, in order
to take them into account, for instance to avoid double bandwidth to take them into account, for instance, to avoid double bandwidth
accounting, or to try to minimize changes (minimum perturbation accounting or to try to minimize changes (minimum perturbation
problem). problem).
It should be observed that the stateless PCE does operate on Note that the stateless PCE does operate on information about network
information about network state. The TED contains link state and state. The TED contains link state and bandwidth availability
bandwidth availability information as distributed by the IGPs or information as distributed by the IGPs or collected through some
collected through some other means. This information could be other means. This information could be further enhanced to provide
further enhanced to provide increased granularity and more detail to increased granularity and more detail to cover, for example, the
cover, for example, the current bandwidth usage on certain links current bandwidth usage on certain links according to resource
according to resource affinities or forwarding equivalence classes. affinities or forwarding equivalence classes. Such information is,
Such information is, however, not PCE state information and so a however, not PCE state information and so a model that uses it is
model that uses it is still described as stateless in the PCE still described as stateless in the PCE context.
context.
A limited form of statefulness might be applied within an otherwise A limited form of statefulness might be applied within an otherwise
stateful PCE. The PCE may retain some context from paths it has stateless PCE. The PCE may retain some context from paths it has
recently computed so that it avoid suggesting the use of the same recently computed so that it avoids suggesting the use of the same
resources for other TE LSPs. resources for other TE LSPs.
6.9. Monitoring 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 architecture. This must include the collection of variables related
to the PCE status and operation. For example, it will be necessary to to the PCE status and operation. For example, it will be necessary
understand the way in which the TED is being kept synchronized, the to understand the way in which the TED is being kept synchronized,
rate of arrival of new requests and the computation times, the range the rate of arrival of new requests and the computation times, the
of PCCs that are using the PCE, and the operation of any PCC-PCE range of PCCs that are using the PCE, and the operation of any PCC-
protocol. PCE protocol.
6.10. Confidentiality 6.10. Confidentiality
As stated in [RFC4216], the case of inter-provider TE LSP As stated in [RFC4216], the case of inter-provider TE LSP computation
computation requires the ability to compute a path while preserving requires the ability to compute a path while preserving
confidentiality across multiple Service Providers cores. That is, one confidentiality across multiple Service Providers cores. That is,
Service Provider must not be required to divulge any information one Service Provider must not be required to divulge any information
about its resources or topology in order to support inter-provider about its resources or topology in order to support inter-provider TE
TE LSP path computation. Thus any PCE architecture solution LSP path computation. Thus, any PCE architecture solution must
must support the ability to return partial paths by means of loose support the ability to return partial paths by means of loose hops
hops (for example, where each loose hops would for instance (for example, where each loose hop would, for instance, identify a
identify a boundary LSR). boundary LSR).
This requirement is not a security issue, but relates to Service This requirement is not a security issue, but relates to Service
Provider policy. Confidentiality, integrity, and authentication of Provider policy. Confidentiality, integrity, and authentication of
PCC-PCE and PCE-PCE messages must also be ensured and is described in PCC-PCE and PCE-PCE messages must also be ensured and are described
Section 10. in Section 10.
The ability to compute a path at the request of the head end PCC, but The ability to compute a path at the request of the head-end PCC, but
to supply the path in segments to the domain boundary PCCs may also to supply the path in segments to the domain boundary PCCs, may also
be desirable. be desirable.
6.11. Policy 6.11. Policy
Policy impacts multiple aspects of the PCE architecture. There are Policy impacts multiple aspects of the PCE architecture. There are
two applications of policy for consideration: two applications of policy for consideration:
- application of policy within an architectural entity (PCC or PCE) - application of policy within an architectural entity (PCC or PCE)
- application of policy to PCE related communications.
Policy as directly applicable to TE LSPs forms part of the signaling - application of policy to PCE-related communications
As directly applicable to TE LSPs, policy forms part of the signaling
mechanism for the establishment of the TE LSPs and is not described mechanism for the establishment of the TE LSPs and is not described
here. here.
It is envisioned that policy will be largely applied as a local It is envisioned that policy will be largely applied as a local
matter within each PCC and PCE. However, this document needs to matter within each PCC and PCE. However, this document needs to
define policy models that can be supported within the PCE define policy models that can be supported within the PCE
architecture and by PCE-related communication. architecture and by PCE-related communication.
Some example policies include: Some example policies include:
- selection of a PCE by a PCC - selection of a PCE by a PCC
- rejection of a request by the PCE based on the identity of the - rejection of a request by the PCE based on the identity of the
requesting PCC requesting PCC
- selection by the PCE of a path or application of additional - selection by the PCE of a path or application of additional
constraints to a computation based on the PCC, the computation constraints to a computation based on the PCC, the computation
target, the time of day, etc. target, the time of day, etc.
6.11.1. PCE Policy Architecture 6.11.1. PCE Policy Architecture
Two examples of the use of policy components within the PCE Two examples of the use of policy components within the PCE
architecture are illustrated in Figures 6 and 7. Policy components architecture are illustrated in Figures 6 and 7. Policy components
could equally be applied to the other PCE configurations shown in could equally be applied to the other PCE configurations shown in
Section 5. In each configuration, policy may be consulted before a Section 5. In each configuration, policy may be consulted before a
skipping to change at page 25, line 22 skipping to change at page 26, line 47
architecture are illustrated in Figures 6 and 7. Policy components architecture are illustrated in Figures 6 and 7. Policy components
could equally be applied to the other PCE configurations shown in could equally be applied to the other PCE configurations shown in
Section 5. In each configuration, policy may be consulted before a Section 5. In each configuration, policy may be consulted before a
response is provided by a PCE and may also be consulted by the response is provided by a PCE and may also be consulted by the
PCC/PCE that receives the response. PCC/PCE that receives the response.
A PCE may have a local policy that impacts the paths selected to A PCE may have a local policy that impacts the paths selected to
satisfy a particular PCE request. A policy may be applied based on satisfy a particular PCE request. A policy may be applied based on
any information provided from a PCC. any information provided from a PCC.
In Figure 6 the policy component is shown providing input to the PCE In Figure 6, the policy component is shown providing input to the PCE
component. This policy component may consult an external policy component. This policy component may consult an external policy
database, but this is outside the scope of this document. database, but this is outside the scope of this document.
------------------------------ ------------------------------
| --------- | Routing ---------- | --------- | Routing ----------
| | | | Protocol | | | | | | Protocol | |
| | TED |<-+----------+-> | | | TED |<-+----------+-> |
| | | | | | | | | | | |
| --------- | | | | --------- | | |
| | | | | | | | | |
skipping to change at page 26, line 4 skipping to change at page 27, line 32
| v | | | | v | | |
| --------- | | | | --------- | | |
Service | | | | Signaling| | Service | | | | Signaling| |
Request | |Signaling| | Protocol | | Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> | ------+---------------->| Engine |<-+----------+-> |
| | | | | | | | | | | |
| --------- | ---------- | --------- | ----------
------------------------------ ------------------------------
Figure 6. Policy Component in the Composite PCE Node Figure 6. Policy Component in the Composite PCE Node
Note that policy information may be conveyed on the internal Note that policy information may be conveyed on the internal
interfaces, and on the external protocol interfaces. interfaces, and on the external protocol interfaces.
Figure 7 displays the case of a distinct PCE function through the Figure 7 displays the case of a distinct PCE function through the
example of the multiple PCE with inter-PCE communication example example of the multiple PCE with inter-PCE communication example
(compare with figure 4). Each PCE takes input from local policy as (compare with Figure 4). Each PCE takes input from local policy as
part of the router computation/determination process. The local part of the router computation/determination process. The local
policy components may consult external policy components or policy components may consult external policy components or
databases, but that is out of scope of this document. databases, but that is out of the scope of this document.
Note that policy information may be conveyed on the external Note that policy information may be conveyed on the external protocol
protocol interfaces, including the inter-PCE interface. interfaces, including the inter-PCE interface.
------------------ ------------------ ------------------ ------------------
| | Inter-PCE Request/Response| | | | Inter-PCE Request/Response| |
| PCE |<------------------------->| PCE | | PCE |<------------------------->| PCE |
| | | | | | | |
| ------ ----- | | ------ ----- | | ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | | | |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- | | ------ ----- | | ------ ----- |
------------------ ------------------ ------------------ ------------------
^ ^
skipping to change at page 27, line 7 skipping to change at page 28, line 45
- There may also be explicit communication of policy information - There may also be explicit communication of policy information
between PCC and PCE, or between PCEs to achieve some level of between PCC and PCE, or between PCEs to achieve some level of
coordination of policy between entities. The type of information coordination of policy between entities. The type of information
conveyed to support policy has important implications on what conveyed to support policy has important implications on what
policies may be applied at each PCE, and the requirements for the policies may be applied at each PCE, and the requirements for the
exchange of policy information inform the choice or implementation exchange of policy information inform the choice or implementation
of communication protocols including PCC-PCE, PCE-PCE, and of communication protocols including PCC-PCE, PCE-PCE, and
discovery protocols. discovery protocols.
6.11.3 Type of Policies 6.11.3. Type of Policies
Within the context of PCE, we identify several types of policies: Within the context of PCE, we identify several types of policies:
o User-specific policies operate on information that is specific to o User-specific policies operate on information that is specific to
the user of a service or the service itself. That is, the service the user of a service or the service itself, that is, the service
for which the path is being computed, not the computation service. for which the path is being computed, not the computation service.
Examples of such information includes the contents of objects of a Examples of such information includes the contents of objects of a
signaling or provisioning message, the port ID over which the signaling or provisioning message, the port ID over which the
message was received, a VPN ID, a reference point type, or the message was received, a VPN ID, a reference point type, or the
identity of the user initiating the request. User-specific policies identity of the user initiating the request. User-specific
could be applied by a PCC while building a path computation policies could be applied by a PCC while building a path
request, or by a PCE while processing the request provided that computation request, or by a PCE while processing the request
sufficient information is supplied by the PCC to the PCE. provided that sufficient information is supplied by the PCC to the
PCE.
o Request-specific policies operate on information that is specific o Request-specific policies operate on information that is specific
to a path computation request and is carried in to a path computation request and is carried in the request.
the request. Examples of such information include constraints, Examples of such information include constraints, diversities,
diversities, constraint and diversity relaxation strategies, and constraint and diversity relaxation strategies, and optimization
optimization functions. Request-specific policies directly affect functions. Request-specific policies directly affect the path
the path selection process because they specify which links, nodes, selection process because they specify which links, nodes, path
path segments and/or paths are not acceptable or, on the contrary, segments, and/or paths are not acceptable or, on the contrary, may
may be desirable to appear in the resulting paths. be desirable in the resulting paths.
o Domain-specific policies operate on the identify of the domain in o Domain-specific policies operate on the identify of the domain in
which the requesting PCC exists, and upon the identities of the which the requesting PCC exists, and upon the identities of the
domains through which the resulting paths are routed. These domains through which the resulting paths are routed. These
policies have the same effect as user-specific policies with the policies have the same effect as user-specific policies, with the
difference that they can be applied to a group of users rather than difference that they can be applied to a group of users rather than
an individual user. One example of domain-specific policy is a an individual user. One example of domain-specific policy is a
restriction on what information a PCE publishes within a given restriction on what information a PCE publishes within a given
domain. In such a case, PCEs in some domains may advertise just domain. In such a case, PCEs in some domains may advertise just
their presence while others may advertise details regarding their their presence, while others may advertise details regarding their
capabilities, client authentication process, and computation capabilities, client authentication process, and computation
resource availability. resource availability.
6.11.4. Relationship to Signaling 6.11.4. Relationship to Signaling
When a path for an inter-domain TE LSP is being computed it is not When a path for an inter-domain TE LSP is being computed, it is not
required to consider signaling plane policy. However, failure to do required to consider signaling plane policy. However, failure to do
so may result in the TE LSP failing to be established, or being so may result in the TE LSP failing to be established, or being
assigned fewer resources than intended resulting in a substandard assigned fewer resources than intended resulting in a substandard
service. Thus, where a PCE invoked by a head-end LSR has visibility service. Thus, where a PCE invoked by a head-end LSR has visibility
into other domains, it should be capable of applying policy into other domains, it should be capable of applying policy
considerations to the computation and should be aware of the considerations to the computation and should be aware of the inter-
inter-domain policy agreements. Where path computation is the result domain policy agreements. Where path computation is the result of
of cooperation between PCEs, each of which is responsible for a cooperation between PCEs, each of which is responsible for a
particular domain, the policy issues should, where possible be particular domain, the policy issues should, where possible, be
resolved at the time of computation so that the TE LSP is more likely resolved at the time of computation so that the TE LSP is more likely
to be signaled successfully. In such context policy violation during to be signaled successfully. In this context, policy violation
inter-domain TE LSP computation may lead to path computation during inter-domain TE LSP computation may lead to path computation
interruption which should be notified to the requester along with the interruption, about which the requester should be notified along with
cause. the cause.
6.12. Unsolicited Interactions 6.12. Unsolicited Interactions
It may be that the PCC-PCE communications (see Section 6.6) can be It may be that the PCC-PCE communications (see Section 6.6) can be
usefully extended beyond a simple request/response interaction. For usefully extended beyond a simple request/response interaction. For
example, the PCE and PCC could exchange capabilities using this example, the PCE and PCC could exchange capabilities using this
protocol. Additionally, the protocol could be used to collect and protocol. Additionally, the protocol could be used to collect and
report information in support of a stateful PCE. report information in support of a stateful PCE.
Further, it may be the case that a PCE is able to update a path that Furthermore, it may be the case that a PCE is able to update a path
it computed earlier (perhaps in reaction to a change in the network that it computed earlier (perhaps in reaction to a change in the
or a change in policy), and in this case the PCE-PCC communication network or a change in policy), and in this case the PCE-PCC
could support an "unsolicited" path computation message to supply communication could support an "unsolicited" path computation message
this new path to the PCC. It should be noted, however, that this to supply this new path to the PCC. Note, however, that this
function would require that the PCE retained a record of previous function would require that the PCE retained a record of previous
computations and had a clear trigger for performing recomputations. computations and had a clear trigger for performing recomputations.
The PCC would also need to be able to identify the new path with the 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. old path and determine whether it should act on the new path.
Furthermore, the PCC should be able to report the outcome of such Further, the PCC should be able to report the outcome of such path
path changes to the requesting PCE. Note that the PCE-PCC interaction changes to the requesting PCE. Note that the PCE-PCC interaction is
is not a management interaction and the PCC is not obliged to utilize not a management interaction and the PCC is not obliged to utilize
any additional path supplied by the PCE. any additional path supplied by the PCE.
These functions fit easily within the architecture described here These functions fit easily within the architecture described here but
but are left for further discussion within separate requirements are left for further discussion within separate requirements
documents. documents.
6.13. Relationship with Crankback 6.13. Relationship with Crankback
Crankback routing is a mechanism whereby a failure to establish a Crankback routing is a mechanism whereby a failure to establish a
path, or a failure of an existing path may be corrected by a new path or a failure of an existing path may be corrected by a new path
path computation and fresh signaling. Crankback routing relies on the computation and fresh signaling. Crankback routing relies on the
distribution of crankback information along with the failure distribution of crankback information along with the failure
notification so that the new computation can be performed avoiding notification so that the new computation can be performed avoiding
the failure or blockage point. the failure or blockage point.
In the context of PCE, crankback information may be passed back to In the context of PCE, crankback information may be passed back to
the head-end where the process of computation and signaling can be the head-end where the process of computation and signaling can be
repeated using the failed resource as an exclusion in the computation repeated using the failed resource as an exclusion in the computation
process. But crankback may be used to attempt to correct the process. But crankback may be used to attempt to correct the problem
problem at intermediate points along the path. Such crankback at intermediate points along the path. Such crankback recomputation
recomputation nodes are most likely to be domain boundaries where the nodes are most likely to be domain boundaries where the PCC had
PCC had already invoked a PCE. Thus, a failure within a domain is already invoked a PCE. Thus, a failure within a domain is reported
reported to the ingress domain boundary which will attempt to compute to the ingress domain boundary, which will attempt to compute an
an alternate path across the domain. Failing this, the problem may be alternate path across the domain. Failing this, the problem may be
reported to the previous domain, and communicated to the ingress reported to the previous domain and communicated to the ingress
boundary for that domain which may attempt to select a more boundary for that domain, which may attempt to select a more
successful path either by choosing a different entry point into the successful path either by choosing a different entry point into the
next domain, or by selecting a route through a different set of next domain, or by selecting a route through a different set of
domains. domains.
7. The View from the Path Computation Client 7. The View from the Path Computation Client
The view of the PCE architecture, and particularly the functional The view of the PCE architecture, and particularly the functional
model, is subtly different from the PCC's perspective. This is partly model, is subtly different from the PCC's perspective. This is
because the PCC has limited knowledge of the way in which the PCEs partly because the PCC has limited knowledge of the way in which the
cooperate to answer its requests, but depends more on the fact that PCEs cooperate to answer its requests, but depends more on the fact
the PCC is concerned with different questions. that the PCC is concerned with different questions.
The PCC is interested in the following: The PCC is interested in the following:
- Selecting a PCE that is able to promptly provide a computed path - Selecting a PCE that is able to promptly provide a computed path
meeting the supplied constraints. that meets the supplied constraints.
- How many computation requests will the PCC have to send? Will the - How many computation requests will the PCC have to send? Will the
desired path be computed by the first PCE contacted (possibly in desired path be computed by the first PCE contacted (possibly in
cooperation with other PCEs), or will the PCC have to consult other cooperation with other PCEs), or will the PCC have to consult other
PCEs to fill in gaps in the path? PCEs to fill in gaps in the path?
- How many other path computations will need to be issued from within - How many other path computations will need to be issued from within
the network in order to establish the TE LSP? the network in order to establish the TE LSP?
This last question might be considered to be out of scope for the This last question might be considered out of scope for the head-end
head-end LSR, but an important constraint that the PCC may wish to LSR, but an important constraint that the PCC may wish to apply is
apply is that the path should be computed in its entirety and that the path should be computed in its entirety and supplied without
supplied without loose hops or non-simple abstract nodes. loose hops or non-simple abstract nodes.
Thus, with its limited perspective, the PCC will see Multiple PCE Thus, with its limited perspective, the PCC will see Multiple PCE
Path Computation (Section 5.3) as important, and will distinguish Path Computation (Section 5.3) as important and will distinguish two
two subcases: the first is as shown in Figure 3 with subsequent subcases. The first is as shown in Figure 3 with subsequent
computation requests made by other PCCs along the path of the TE LSP; computation requests made by other PCCs along the path of the TE LSP.
the second having multiple computation requests issued by the In the second, multiple computation requests are issued by the head-
head-end LSR. On the other hand, the PCC will not be aware of end LSR. On the other hand, the PCC will not be aware of Multiple
Multiple PCE Path Computation with Inter-PCE Communication (Section PCE Path Computation with Inter-PCE Communication (Section 5.4),
5.4) which it will perceive as no different from the simple External which it will perceive as no different from the simple External PCE
PCE Node case (Section 5.2). Node case (Section 5.2).
The PCC, therefore, will be acutely aware that a Centralized PCE The PCC, therefore, will be acutely aware that a Centralized PCE
Model (Section 6.1) might still require Multiple PCE Path Model (Section 6.1) might still require Multiple PCE Path
Computations with the head-end or subsequent PCCs required to issue Computations with the head-end or subsequent PCCs required to issue
further requests to the central PCE. Conversely, the PCC may be further requests to the central PCE. Conversely, the PCC may be
protected from the Distributed PCE Model (Section 6.2) by the fact protected from the Distributed PCE Model (Section 6.2) because the
that the first PCE it consults uses inter-PCE communication to first PCE it consults uses inter-PCE communication to achieve a
achieve a complete computation result so that no further computation complete computation result so that no further computation requests
requests are required. are required.
These distinctions can be completely classified by determining These distinctions can be completely classified by determining
whether the computation response includes all necessary paths, and whether the computation response includes all necessary paths, and
whether those paths are fully explicit (that is, containing only whether those paths are fully explicit (that is, containing only
strict hops between simple abstract nodes). strict hops between simple abstract nodes).
8. Evaluation Metrics 8. Evaluation Metrics
Evaluation metrics that may be used to evaluate the efficiency and Evaluation metrics that may be used to evaluate the efficiency and
applicability of any PCE-based solution are listed below. Note that applicability of any PCE-based solution are listed below. Note that
these metrics are not being used to determine paths, but are used to these metrics are not being used to determine paths, but are used to
evaluate potential solutions to the PCE architecture. evaluate potential solutions to the PCE architecture.
- Optimality: The ability to maximize network utilization and - Optimality: The ability to maximize network utilization and
minimize cost, considering QoS objectives, multiple regions and minimize cost, considering QoS objectives, multiple regions, and
network layers. Note that models that require the sequential network layers. Note that models that require the sequential
involvement of multiple PCEs (for example, the multiple PCE model involvement of multiple PCEs (for example, the multiple PCE model
described in Section 5.3) might create path loops unless careful described in Section 5.3) might create path loops unless careful
policy is applied. policy is applied.
- Scalability: The implications of routing, TE LSP signaling and PCE - Scalability: The implications of routing, TE LSP signaling, and PCE
communication overhead such as the number of messages and the size communication overhead, such as the number of messages and the size
of messages (including LSAs, crankback information, queries, of messages (including LSAs, crankback information, queries,
distribution mechanisms, etc.). 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 by allowing multiple PCEs to each take computation load by allowing multiple PCEs each to take
responsibility for a subset of the total path computation requests. 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 This also includes the ability to perform inter-layer correlation
when considering the reoptimization at any specific layer. when considering the reoptimization at any specific layer.
- Path computation time: The time to compute individual paths, - Path computation time: The time to compute individual paths and
multiple diverse paths, and to satisfy bulk path computation multiple diverse paths and to satisfy bulk path computation
requests. (Note that such a metric can only be applied to problems requests. (Note that such a metric can only be applied to problems
that are not NP-complete.) 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 existing TE state resulting from the computation and establishment
of new TE paths. of new TE paths.
- Ability to maintain accurate synchronization between TED and - Ability to maintain accurate synchronization between TED and
network topology and resource states. network topology and resource states.
skipping to change at page 31, line 18 skipping to change at page 33, line 18
network. network.
- Ability to deal with situations where paths satisfying a required - Ability to deal with situations where paths satisfying a required
set of constraints cannot be found by the PCE. set of constraints cannot be found by the PCE.
- Policy: Application of policy to the PCC-PCE and PCE-PCE - Policy: Application of policy to the PCC-PCE and PCE-PCE
communications as well as to the computation of paths that respect communications as well as to the computation of paths that respect
inter-domain TE LSP establishment policies. inter-domain TE LSP establishment policies.
Note that other metrics may also be considered. Such metrics should Note that other metrics may also be considered. Such metrics should
be used when evaluating a particular PCE-based architecture. It must be used when evaluating a particular PCE-based architecture. The
also be highlighted that the potential tradeoffs of the optimization potential tradeoffs of the optimization of such metrics should be
of such metrics should be evaluated (for instance, increasing the evaluated (for instance, increasing the path optimality is likely to
path optimality is likely to have consequences on the computation have consequences on the computation time).
time).
9. Manageability Considerations 9. Manageability Considerations
The PCE architecture introduces several elements that are subject to The PCE architecture introduces several elements that are subject to
manageability. The PCE itself must be managed as must its manageability. The PCE itself must be managed, as must its
communications with PCCs and other PCEs. The mechanism by which PCEs communications with PCCs and other PCEs. The mechanism by which PCEs
and PCCs discover each other are also subject to manageability. and PCCs discover each other are also subject to manageability.
Many of the issues of manageability are already covered in other Many of the issues of manageability are already covered in other
sections of this document. sections of this document.
9.1. Control of Function and Policy 9.1. Control of Function and Policy
It must be possible to enable and disable the PCE function at a PCE, It must be possible to enable and disable the PCE function at a PCE,
and this will lead to the PCE accepting, rejecting, or simply not and this will lead to the PCE accepting, rejecting, or simply not
skipping to change at page 31, line 52 skipping to change at page 33, line 51
by completing them, forwarding them to another PCE, or rejecting by completing them, forwarding them to another PCE, or rejecting
them). them).
Similarly it must be possible to control the application of policy at Similarly it must be possible to control the application of policy at
the PCE through configuration. This control may include the the PCE through configuration. This control may include the
restriction of certain functions or algorithms, the configuration of restriction of certain functions or algorithms, the configuration of
access rights and priorities for PCCs, and the relationships with access rights and priorities for PCCs, and the relationships with
other PCEs both inside and outside the domain. other PCEs both inside and outside the domain.
The policy configuration interface is yet to be determined. The The policy configuration interface is yet to be determined. The
interface may be purely a local matter, or may be supported via a interface may be purely a local matter, or it may be supported via a
standardized interface (such as, a MIB module). standardized interface (such as a MIB module).
9.2. Information and Data Models 9.2. Information and Data Models
It is expected that the operations of PCEs and PCCs will be modeled It is expected that the operations of PCEs and PCCs will be modeled
and controlled through appropriate MIB modules. The tables in the new and controlled through appropriate MIB modules. The tables in the
MIB modules will need to reflect the relationships between entities new MIB modules will need to reflect the relationships between
and to control and report on configurable options. entities and to control and report on configurable options.
Statistics gathering will form an important part of the operation of Statistics gathering will form an important part of the operation of
PCEs. The operator must be able to determine the historical PCEs. The operator must be able to determine the historical
interactions of a PCC with its PCEs, the performance that it has interactions of a PCC with its PCEs, the performance that it has
seen, and success rate of its requests. Similarly, it is important seen, and the success rate of its requests. Similarly, it is
for an operator to be able to inspect a PCE and determine its load important for an operator to be able to inspect a PCE and determine
and whether an individual PCC is responsible for a disproportionate its load and whether an individual PCC is responsible for a
amount of the load. It will also be important to be able to record disproportionate amount of the load. It will also be important to be
and inspect statistics about the communications between the PCC and able to record and inspect statistics about the communications
between the PCC and PCE, including issues such as malformed messages,
PCE, including issues such as malformed messages, unauthorized unauthorized messages, and messages discarded because of congestion.
messages and messages discarded owing to congestion. In this respect In this respect, there is clearly an overlap between manageability
there is clearly an overlap between manageability and security. and security.
Statistics for the PCE architecture can be made available through Statistics for the PCE architecture can be made available through
appropriate tables in the new MIB modules. appropriate tables in the new MIB modules.
The new MIB modules should also be used to provide notifications when The new MIB modules should also be used to provide notifications when
key thresholds are crossed or when important events occur. Great care key thresholds are crossed or when important events occur. Great
must be exercised to ensure that the network is not flooded with SNMP care must be exercised to ensure that the network is not flooded with
notifications. Thus it might be inappropriate to issue a notification Simple Network Management Protocol (SNMP) notifications. Thus, it
every time that a PCE receives a request to compute a path. In any might be inappropriate to issue a notification every time a PCE
case, full control must be provided to allow notifications to be receives a request to compute a path. In any case, full control must
disabled using, for example, the mechanisms defined in the be provided to allow notifications to be disabled using, for example,
SNMP-NOTIFICATION-MIB module in [RFC3413]. the mechanisms defined in the SNMP-NOTIFICATION-MIB module in
[RFC3413].
9.3. Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
Section 6.5 discusses the importance of a PCC being able to detect Section 6.5 discusses the importance of a PCC being able to detect
the liveness of a PCE. PCE-PCC communications techniques must enable 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 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 request and in the period between sending a request and receiving a
response. response.
It is less important for a PCE to know about the liveness of PCCs, 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: 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 - to gain a predictive view of the likely loading of a PCE in the
future future, or
- to allow a PCE to abandon processing of a received request. - to allow a PCE to abandon processing of a received request.
9.4. Verifying Correct Operation 9.4. Verifying Correct Operation
Correct operation for the PCE architecture can be classified as Correct operation for the PCE architecture can be classified as
determining the correct point-to-point connectivity between PCCs and determining the correct point-to-point connectivity between PCCs and
PCEs, and assessing the validity of the computed paths. The former is PCEs, and as assessing the validity of the computed paths. The
a security issue that may be enhanced by authentication and monitored former is a security issue that may be enhanced by authentication and
through event logging and records as described in Section 9.1. It may monitored through event logging and records as described in Section
also be a routing issue to ensure that PCC-PCE connectivity is 9.1. It may also be a routing issue to ensure that PCC-PCE
possible. connectivity is possible.
Verifying computed paths is more complex. The information to perform Verifying computed paths is more complex. The information to perform
this function can, however, be made available to the operator through this function can, however, be made available to the operator through
MIB tables provided full records are kept of the constraints passed MIB tables, provided that full records are kept of the constraints
on the request, the path computed and provided on the response, and passed on the request, the path computed and provided on the
any additional information supplied by the PCE such as the constraint response, and any additional information supplied by the PCE such as
relaxation policies applied. the constraint relaxation policies applied.
9.5. Requirements on Other Protocols and Functional Components 9.5. Requirements on Other Protocols and Functional Components
At the architectural stage it is impossible to make definitive At the architectural stage, it is impossible to make definitive
statements about the impact on other protocols and functional statements about the impact on other protocols and functional
components since the solutions work has not been completed. However, components since the solution's work has not been completed.
it is possible to make some observations. However, it is possible to make some observations.
- Dependence on underlying transport protocols - Dependence on underlying transport protocols
PCE-PCC communications may choose to utilize underlying protocols PCE-PCC communications may choose to utilize underlying protocols
to provide transport mechanisms. In this case some of the to provide transport mechanisms. In this case, some of the
manageability considerations described in the previous sections may manageability considerations described in the previous sections may
be devolved to those protocols. be devolved to those protocols.
- Re-use of existing protocols for discovery - Re-use of existing protocols for discovery
Without prejudicing the requirements and solutions work for PCE Without prejudicing the requirements and solutions work for PCE
discovery (see Section 6.4) it is possible that use will be made of discovery (see Section 6.4), it is possible that use will be made
existing protocols to facilitate this function. In this case some of existing protocols to facilitate this function. In this case
of the manageability considerations described in the previous some of the manageability considerations described in the previous
sections may be devolved to those protocols. sections may be devolved to those protocols.
- Impact on LSRs and TE LSP signaling - Impact on LSRs and TE LSP signaling
The primary example of a PCC identified in this architecture is an The primary example of a PCC identified in this architecture is an
MPLS or GMPLS LSR. Consideration must therefore be given to the MPLS or a GMPLS LSR. Consideration must therefore be given to the
manageability of the LSRs and the additional manageability manageability of the LSRs and the additional manageability
constraints applicable to the TE LSP signaling protocols. constraints applicable to the TE LSP signaling protocols.
As well as allowing the PCC management described in the previous In addition to allowing the PCC management described in the
sections, an LSR must be configurable to determine whether it will previous sections, an LSR must be configurable to determine whether
use a remote PCE at all - the options being to use hop-by-hop it will use a remote PCE at all, the options being to use hop-by-
routing or to supply the PCE function itself. It is likely to be hop routing or to supply the PCE function itself. It is likely to
important to be able to distinguish within an LSR whether the route be important to be able to distinguish within an LSR whether the
used for a TE LSP was supplied in a signaling message from another route used for a TE LSP was supplied in a signaling message from
LSR, by an operator, or by a PCE, and in the case where it was another LSR, by an operator, or by a PCE, and, in the case where it
supplied in a signaling message whether it was enhanced or expanded was supplied in a signaling message, whether it was enhanced or
by a PCE. expanded by a PCE.
- Reuse of existing policy models and mechanisms - Reuse of existing policy models and mechanisms
As policy support mechanisms can be quite extensive, it is As policy support mechanisms can be quite extensive, it is
worthwhile to explore to what extent this prior work can be worthwhile to explore to what extent this prior work can be
leveraged and applied to PCE. This desire to leverage prior work leveraged and applied to PCE. This desire to leverage prior work
should not be interpreted as a requirement to use any particular should not be interpreted as a requirement to use any particular
solution or protocol. solution or protocol.
9.6. Impact on Network Operation 9.6. Impact on Network Operation
This architecture may have two impacts on the operation of a network. This architecture may have two impacts on the operation of a network.
It increases TE LSP setup times while requests are sent to and It increases TE LSP setup times while requests are sent to and
processed by a remote PCE, and it may cause congestion within the processed by a remote PCE, and it may cause congestion within the
network if a significant number of computation requests are issued in network if a significant number of computation requests are issued in
a small period of time. These issues are most severe in busy networks a small period of time. These issues are most severe in busy
and after network failures, although the effect may be mitigated if networks and after network failures, although the effect may be
the protection paths are precomputed or if the path computation load mitigated if the protection paths are precomputed or if the path
is distributed among a set of PCEs. computation load is distributed among a set of PCEs.
Issues of potential congestion during recovery from failures may be Issues of potential congestion during recovery from failures may be
mitigated through the use of pre-established protection schemes such mitigated through the use of pre-established protection schemes such
as fast reroute. as fast reroute.
It is important that network congestion be managed proactively It is important that network congestion be managed proactively
because it may be impossible to manage it reactively once the network 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 is congested. It should be possible for an operator to rate limit
requests that a PCC sends to a PCE, and a PCE should be able to the requests that a PCC sends to a PCE, and a PCE should be able to
report impending congestion (according to a configured threshold) report impending congestion (according to a configured threshold)
both to the operator and to its PCCs. both to the operator and to its PCCs.
9.7. Other Considerations 9.7. Other Considerations
No other management considerations have been identified. No other management considerations have been identified.
10. Security Considerations 10. Security Considerations
The impact of the use of a PCE-based architecture must be considered The impact of the use of a PCE-based architecture must be considered
in the light of the impact that it has on the security of the in the light of the impact that it has on the security of the
existing routing and signaling protocols and techniques in use within existing routing and signaling protocols and techniques in use within
the network. There is unlikely to be any impact on intra-domain the network. The impact may be less likely to be an issue in the
security, but an increase in inter-domain information flows and the case of intra-domain use of PCE, but an increase in inter-domain
facilitation of inter-domain path establishment may increase the information flows and the facilitation of inter-domain path
vulnerability to security attacks. establishment may increase the 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
not necessarily the case that a multi-domain PCE solution will is 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 security sections. detailed security sections.
It should be observed that the use of a non-local PCE (that is, not Note that the use of a non-local PCE (that is, one not co-resident
co-resident with the PCC) does introduce additional security issues. with the PCC) does introduce additional security issues. Most
Most notable amongst these are: notable among these are:
- Interception of PCE requests or responses - interception of PCE requests or responses;
- Impersonation of PCE, or PCC - impersonation of PCE or PCC;
- Falsification of TE information, policy information or PCE - falsification of TE information, policy information, or PCE
capabilities capabilities; and
- 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.
11. IANA Considerations 11. Acknowledgements
This informational document makes no requests for IANA action.
12. 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) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed
Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella,
Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou,
Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for
their review and suggestions. Lou Berger provided valuable and their review and suggestions. Lou Berger provided valuable and
detailed contributions to the discussion of policy in this document. detailed contributions to the discussion of policy in this document.
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review
and constructive discussions during the final stages of publication. and constructive discussions during the final stages of publication.
13. Intellectual Property Considerations 12. Informative References
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
14. Informational References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
J. McManus, "Requirements for Traffic Engineering over McManus, "Requirements for Traffic Engineering Over MPLS",
MPLS", RFC 2702, September 1999. RFC 2702, September 1999.
[RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
March 1999. Networks (VPNs)", RFC 4364, February 2006.
[RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
OSPF Version 2", RFC 3630, September 2003. (TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002. 3413, December 2002.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Switching (GMPLS) Signaling - Resource ReserVation (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Protocol-Traffic Engineering (RSVP-TE) Extensions", Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
RFC 3473, January 2003.
[RFC3748] Smit, H. and Li, T., "Intermediate System to [RFC3748] Smit, H. and T. Li, "Intermediate System to Intermediate
Intermediate System (IS-IS) - Extensions for Traffic System (IS-IS) Extensions for Traffic Engineering (TE)",
Engineering (TE)", RFC 3784, June 2004. RFC 3784, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic "Multiprotocol Label Switching (MPLS) Traffic Engineering
Engineering (TE) Management Information Base (MIB)", (TE) Management Information Base (MIB)", RFC 3812, June
RFC 3812, June 2004. 2004.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for [RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle,
Support of Inter-Area and Inter-AS MPLS Traffic "Requirements for Inter-Area MPLS Traffic Engineering",
Engineering", RFC 4105, June 2005. RFC 4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System
Engineering requirements", RFC 4216, November 2005. (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
[MLN] Shiomoto, K., et. al., "Requirements for GMPLS-based [MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux,
multi-region and multi-layer networks", M., and D. Brungard, "Requirements for GMPLS-based multi-
draft-ietf-ccamp-gmpls-mln-reqs, work in progress. region and multi-layer networks (MRN/MLN)", Work in
Progress, June 2006.
15. Contact Information Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. 1414 Massachussetts Avenue
300 Beaver Brook Road Boxborough, MA 01719
Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com
Jerry Ash EMail: jpv@cisco.com
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: (732)-420-4578 Phone: (732)-420-4578
Fax: (732)-368-8659 Fax: (732)-368-8659
Email: gash@att.com EMail: gash@att.com
16. Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 217 change blocks. 
612 lines changed or deleted 605 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/