draft-ietf-pce-discovery-reqs-01.txt   draft-ietf-pce-discovery-reqs-02.txt 
Network Working Group J.L. Le Roux (Editor) Network Working Group J.L. Le Roux (Editor)
Internet Draft France Telecom Internet Draft France Telecom
Category: Informational Category: Informational
Expires: January 2006 Expires: March 2006
July 2005 October 2005
Requirements for Path Computation Element (PCE) Discovery Requirements for Path Computation Element (PCE) Discovery
draft-ietf-pce-discovery-reqs-01.txt draft-ietf-pce-discovery-reqs-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
This document is an Internet-Draft and is in full conformance with Internet-Drafts are working documents of the Internet Engineering
all provisions of Section 10 of RFC2026. Internet-Drafts are working Task Force (IETF), its areas, and its working groups. Note that other
documents of the Internet Engineering Task Force (IETF), its areas, groups may also distribute working documents as Internet-Drafts.
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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document presents a set of requirements for a Path Computation This document presents a set of requirements for a Path Computation
Element (PCE) discovery mechanism that would allow a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation
Client (PCC) to discover dynamically and automatically a set of PCEs Client (PCC) to discover dynamically and automatically a set of PCEs
along with certain information relevant for PCE selection. It is along with certain information relevant for PCE selection. It is
intended that solutions that specify procedures and protocol(s) or intended that solutions that specify procedures and protocol(s) or
protocol(s) extensions for such PCE discovery satisfy these extensions to existing protocol(s) for such PCE discovery satisfy
requirements. these requirements.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
Table of Contents Table of Contents
1. Contributors................................................2 1. Contributors................................................2
2. Terminology.................................................3 2. Terminology.................................................3
3. Introduction................................................3 3. Introduction................................................3
4. Problem Statement and Requirements overview.................4 4. Problem Statement and Requirements overview.................4
skipping to change at page 2, line 22 skipping to change at page 2, line 19
1. Contributors................................................2 1. Contributors................................................2
2. Terminology.................................................3 2. Terminology.................................................3
3. Introduction................................................3 3. Introduction................................................3
4. Problem Statement and Requirements overview.................4 4. Problem Statement and Requirements overview.................4
4.1. Problem Statement...........................................4 4.1. Problem Statement...........................................4
4.2. Requirements overview.......................................5 4.2. Requirements overview.......................................5
5. Example of application scenario.............................6 5. Example of application scenario.............................6
6. Detailed Requirements.......................................7 6. Detailed Requirements.......................................7
6.1. PCE Information to be disclosed.............................7 6.1. PCE Information to be disclosed.............................7
6.1.1. Discovery of PCE Location...................................7 6.1.1. General PCE Information (Mandatory support).................7
6.1.2. Discovery of PCE computation scope(s) and domain(s) 6.1.1.1. Discovery of PCE Location.................................7
under control...............................................7 6.1.1.2. Discovery of PCE domain(s) and inter-domain functions.....7
6.1.3. Discovery of PCE Capabilities...............................8 6.1.2. Detailed PCE Information (Optional support).................8
6.1.4. Discovery of Alternate PCEs.................................8 6.1.2.1. Discovery of PCE Capabilities.............................8
6.1.2.2. Discovery of Alternate PCEs...............................9
6.2. Scope of PCE Discovery......................................9 6.2. Scope of PCE Discovery......................................9
6.3. PCE Information Synchronization.............................9 6.3. PCE Information Synchronization............................10
6.4. Detecting PCE Liveliness....................................9 6.4. Detecting PCE Liveliness...................................10
6.5. Discovery of PCE capacity and congestion...................10 6.5. Security Requirements......................................10
6.6. Security Requirements......................................10 6.6. Extensibility..............................................11
6.7. Extensibility..............................................10 6.7. Scalability................................................11
6.8. Scalability................................................10 6.8. Operational orders of magnitudes...........................11
7. Security Considerations....................................11 7. Security Considerations....................................12
8. Acknowledgments............................................11 8. Acknowledgments............................................12
9. References.................................................11 9. References.................................................12
10. Authors' Addresses:........................................11 10. Authors' Addresses:........................................12
11. Intellectual Property Statement............................12 11. Intellectual Property Statement............................13
1. Contributors 1. Contributors
The following are the authors that contributed to the present The following are the authors that contributed to the present
document: document:
Jean-Louis Le Roux (France Telecom) Jean-Louis Le Roux (France Telecom)
Paul Mabey (Qwest Communications) Paul Mabey (Qwest Communications)
Eiji Oki (NTT) Eiji Oki (NTT)
Richard Rabbat (Fujitsu) Richard Rabbat (Fujitsu)
skipping to change at page 3, line 45 skipping to change at page 3, line 45
Inter-AS MPLS TE LSP: A TE LSP whose path transits Inter-AS MPLS TE LSP: A TE LSP whose path transits
through two or more ASes or sub-ASes (BGP confederations). through two or more ASes or sub-ASes (BGP confederations).
Domain: any collection of network elements within a common sphere Domain: any collection of network elements within a common sphere
of address management or path computational responsibility. of address management or path computational responsibility.
Examples of domains include IGP areas and Autonomous Systems. Examples of domains include IGP areas and Autonomous Systems.
3. Introduction 3. Introduction
The PCE Architecture [PCE-ARCH] defines a Path Computation Element The PCE Architecture [PCE-ARCH] defines a Path Computation Element
(PCE) as an entity capable of computing TE-LSPs paths satisfying a (PCE) as an entity capable of computing TE-LSPs paths based on a
set of constraints. A PCE serves path computation requests sent by network graph, and applying computational constraints. A PCE serves
Path Computation Clients (PCC). path computation requests sent by Path Computation Clients (PCC).
A PCC is a client application requesting a path computation to be A PCC is a client application requesting a path computation to be
performed by a PCE. This can be, for instance, an LSR requesting a performed by a PCE. This can be, for instance, an LSR requesting a
path for a TE-LSP for which it is the head-end, or a PCE requesting a path for a TE-LSP for which it is the head-end, or a PCE requesting a
path computation of another PCE (inter-PCE communication). The path computation of another PCE (inter-PCE communication). The
communication between a PCC and a PCE requires a client-server communication between a PCC and a PCE requires a client-server
protocol whose generic requirements are listed in [PCE-COM-REQ]. protocol whose generic requirements are listed in [PCE-COM-REQ].
There are several motivations for the adoption of a PCE-based There are several motivations for the adoption of a PCE-based
architecture to perform a path computation. They are listed in [PCE- architecture to perform a path computation. They are listed in [PCE-
ARCH]. This includes applications such as CPU intensive path ARCH]. This includes applications such as CPU intensive path
computation, inter-domain path computation and backup path computation, inter-domain path computation and backup path
computation. computation.
The PCE architecture requires, of course, that a PCC be aware of the The PCE architecture requires, of course, that a PCC be aware of the
location of one or more PCEs in its domain, and also potentially of location of one or more PCEs in its domain, and also potentially of
some PCEs in other domains, for inter-domain path computation. some PCEs in other domains, e.g. in case of inter-domain path
computation.
In that context it would be highly desirable to define a mechanism In that context it would be highly desirable to define a mechanism
for automatic and dynamic PCE discovery, which would allow PCCs to for automatic and dynamic PCE discovery, which would allow PCCs to
automatically discover a set of PCEs, including information required automatically discover a set of PCEs, including information required
for PCE selection, and to dynamically detect new PCEs or any for PCE selection, and to dynamically detect new PCEs or any
modification of PCE's information. This includes the discovery by a modification of PCE's information. This includes the discovery by a
PCC of a set of one or more PCEs in its domain, and potentially in PCC of a set of one or more PCEs in its domain, and potentially in
some other domains. The latter is a desirable function in the case of some other domains. The latter is a desirable function in the case of
inter-domain path computation for example. inter-domain path computation for example.
This document lists a set of functional requirements for such an This document lists a set of functional requirements for such an
automatic and dynamic PCE discovery mechanism. Section 3 points out automatic and dynamic PCE discovery mechanism. Section 4 points out
the problem statement. Section 4 illustrates an application scenario. the problem statement. Section 5 illustrates an application scenario.
Finally section 5 addresses detailed requirements. Finally section 6 addresses detailed requirements.
It is intended that solutions that specify procedures and protocol(s) It is intended that solutions that specify procedures and protocol(s)
or protocol(s) extensions for such PCE discovery satisfy these or protocol(s) extensions for such PCE discovery satisfy these
requirements. There is no intent either to specify solution specific requirements. There is no intent either to specify solution-specific
requirements or to make any assumption on the protocol(s) that could requirements or to make any assumption on the protocol(s) that could
be used for the discovery. be used for the discovery.
Note that requirements listed in this document apply equally to MPLS- Note that requirements listed in this document apply equally to PCEs
TE and GMPLS-capable PCEs. that are capable of computing paths in MPLS-TE-enabled networks and
PCEs that are capable of computing paths in GMPLS-enabled networks
(and PCEs capable of both).
It is also important to note that the notion of a PCC encompasses a It is also important to note that the notion of a PCC encompasses a
PCE acting as PCC when requesting a path computation of another PCE PCE acting as PCC when requesting a path computation of another PCE
(inter-PCE communication). Hence, this document does not make the (inter-PCE communication). Hence, this document does not make the
distinction between PCE discovery by PCCs and PCE discovery by PCEs. distinction between PCE discovery by PCCs and PCE discovery by PCEs.
4. Problem Statement and Requirements overview 4. Problem Statement and Requirements overview
4.1. Problem Statement 4.1. Problem Statement
A routing domain may in practice be comprised of multiple PCEs: A routing domain may in practice be comprised of multiple PCEs:
-The path computation load may be balanced among a set of PCEs -The path computation load may be balanced among a set of PCEs
to improve scalability; to improve scalability;
-For the purpose of redundancy, primary and backup PCEs may be -For the purpose of redundancy, primary and backup PCEs may be
used; used;
-PCEs may have distinct path computation capabilities (multi- -PCEs may have distinct path computation capabilities (multi-
constrained path computation, backup path computation...); constrained path computation, backup path computation...);
-In an inter-domain context there can be several PCEs with -In an inter-domain context there can be several PCEs with
distinct path computation scopes (intra-area, inter-area, distinct inter-domain functions (inter-area,
inter-AS, inter-layer), each PCE being responsible for path inter-AS, inter-layer), each PCE being responsible for path
computation in one or more domains within its scope. computation in one or more domains.
As an example, in a multi-area network made of one backbone area and As an example, in a multi-area network made of one backbone area and
N peripheral areas, and where inter-area MPLS-TE path computation N peripheral areas, and where inter-area MPLS-TE path computation
relies on multiple-PCE path computation with ABRs acting as PCEs, the relies on multiple-PCE path computation with ABRs acting as PCEs, the
backbone area would comprise at least N PCEs. In existing multi-area backbone area would comprise at least N PCEs. In existing multi-area
networks, N can be quite large (e.g. beyond fifty). networks, N can be quite large (e.g. beyond fifty).
In order to allow for efficient PCE selection by PCCs and efficient In order to allow for effective PCE selection by PCCs and efficient
load balancing of requests, a PCC has to know the location of PCEs in load balancing of requests, a PCC has to know the location of PCEs in
its domain, along with some information relevant for PCE selection, its domain, along with some information relevant to PCE selection,
and also potentially of some PCEs in other domains, for inter-domain and also potentially of some PCEs in other domains, for inter-domain
path computation purpose. path computation purpose.
Such PCE information could be learnt through manual configuration, on Such PCE information could be learnt through manual configuration, on
each PCC, of the set of PCEs along with their capabilities. Such each PCC, of the set of PCEs along with their capabilities. Such
manual configuration approach may be sufficient, and even desired in manual configuration approach may be sufficient, and even desired in
some particular situations, but it obviously faces several some particular situations, but it obviously faces several
limitations: limitations:
-This may imply a substantial configuration overhead (see the -This may imply a substantial configuration overhead (see the
above example with N PCEs); above example with N PCEs);
-This would not allow a PCC to dynamically detect that a new -This would not allow a PCC to dynamically detect that a new
skipping to change at page 5, line 42 skipping to change at page 5, line 43
dynamically discover a set of PCEs is highly desirable. dynamically discover a set of PCEs is highly desirable.
4.2. Requirements overview 4.2. Requirements overview
A PCE discovery mechanism that satisfies the requirements set forth A PCE discovery mechanism that satisfies the requirements set forth
in this document MUST allow a PCC to automatically discover the in this document MUST allow a PCC to automatically discover the
location of one or more PCEs in its domain and also, potentially, of location of one or more PCEs in its domain and also, potentially, of
PCEs in other domains, of interest for inter-domain path computation PCEs in other domains, of interest for inter-domain path computation
purpose. purpose.
A PCE discovery mechanism MUST allow discovering the path computation A PCE discovery mechanism MUST allow a PCC to discover the set of one
scope(s) of a PCE (intra-area, inter-area, inter-ASŕ). It MUST also or more domains under the path computation responsibility of a PCE.
allow a PCC to discover the set of one or more domains under the path It MUST also allow the discovery of the potential inter-domain
computation responsibility of a PCE. function(s) of a PCE (inter-area, inter-AS, inter-layer…).
A PCE discovery mechanism MUST allow PCCs to dynamically discover A PCE discovery mechanism MUST allow PCCs to dynamically discover
that a new PCE has appeared or that there is a change in PCE's that a new PCE has appeared or that there is a change in PCE's
information. It MUST also allow PCCs to dynamically discover that a information. It MUST also allow PCCs to dynamically discover that a
PCE is no longer available. PCE is no longer available.
The PCE discovery MUST be secure. In particular, key consideration The PCE discovery MUST be secure. In particular, key consideration
MUST be given in terms of how to establish a trust model for PCE MUST be given in terms of how to establish a trust model for PCE
discovery. discovery.
OPTIONALLY a PCE discovery mechanism MAY be used so as to disclose a OPTIONALLY a PCE discovery mechanism MAY be used so as to disclose a
set of PCE capabilities. set of detailed PCE capabilities.
5. Example of application scenario 5. Example of application scenario
<----------------AS1--------------------> <----AS2--- <----------------AS1--------------------> <----AS2---
Area 1 Area 0 Area 2 Area 1 Area 0 Area 2
R1---------R3-----R5-------R6-----------R9----------R11----R13 R1---------R3-----R5-------R6-----------R9----------R11----R13
| | | | | | | | | |
| | | | | | | | | |
R2---------R4-----R7-------R8-----------R10---------R12----R14 R2---------R4-----R7-------R8-----------R10---------R12----R14
|
S1 |
--
|S1|
--
Figure 1 Figure 1
Figure 1 above illustrates a network with several PCEs: Figure 1 above illustrates a multi-area/AS network with several PCEs:
-The ABR R3 is a PCE that can take part in inter area path -The ABR R3 is a PCE that can take part in inter area path
computation. It can compute paths in area 1 and area 0; computation. It can compute paths in area 1 and area 0;
-The ABR R6 is a PCE that can take part in inter-area path -The ABR R6 is a PCE that can take part in inter-area path
computation. It can compute paths in area 0 and area2; computation. It can compute paths in area 0 and area2;
-The ASBR R9 is a PCE that can take part in inter-AS path -The ASBR R9 is a PCE that can take part in inter-AS path
computation, responsible for path computation in AS1 towards AS2; computation, responsible for path computation in AS1 towards AS2;
-The ASBR R12 is a PCE that can take part in inter-AS path -The ASBR R12 is a PCE that can take part in inter-AS path
computation, responsible for path computation in AS2 towards AS1; computation, responsible for path computation in AS2 towards AS1;
-The server S1 is a PCE that can be used to compute diverse paths and -The server S1 is a PCE that can be used to compute diverse paths and
backup paths in area 1. backup paths in area 1.
The PCE discovery mechanism will allow: The PCE discovery mechanism will allow:
-each LSR in area 1 and 0 to dynamically discover R3, as a PCE for -each LSR in areas 1 and 0 to dynamically discover R3, as a PCE for
inter-area path computation as well as its path computation domains: inter-area path computation as well as its path computation domains:
area1 and area0; area1 and area0;
-each LSR in area 0 and 2 to dynamically discover R6, as a PCE for -each LSR in areas 0 and 2 to dynamically discover R6, as a PCE for
inter-area path computation, as well as its path computation domains: inter-area path computation, as well as its path computation domains:
area2 and area0; area2 and area0;
-each LSR in AS1 and some PCEs in AS2 to dynamically discover R9 as a -each LSR in AS1 and some PCEs in AS2 to dynamically discover R9 as a
PCE for inter-AS path computation in AS1 towards AS2; PCE for inter-AS path computation in AS1 towards AS2;
-each LSR in AS2 and some PCEs in AS1 to dynamically discover R12 as
a PCE for inter-AS path computation in AS2 towards AS1;
-each LSR in area 1 to dynamically discover S1, as a PCE for diverse -each LSR in area 1 to dynamically discover S1, as a PCE for diverse
path computation and backup path computation in area1. path computation and backup path computation in area1.
6. Detailed Requirements 6. Detailed Requirements
6.1. PCE Information to be disclosed 6.1. PCE Information to be disclosed
The PCE discovery mechanism MUST allow disclosing some PCE We distinguish two levels of PCE information to be disclosed by the
information that will allow PCCs to select appropriate PCEs. PCE discovery mechanism:
-General information, whose disclosure MUST be supported by the
PCE discovery mechanism.
-Detailed information, whose disclosure MAY be supported by the
PCE discovery mechanism.
We distinguish two levels of information to be disclosed by the PCE The PCE discovery mechanism MUST allow disclosing general PCE
discovery mechanism: information that will allow PCCs to select appropriate PCEs. This
-Mandatory information: This comprises discovery of PCE location, comprises discovery of PCE location, PCE domain(s) and potential PCE
PCE computation scopes and domains under control inter-domain function(s).
-Optional information: This comprises discovery of PCE
capabilities and alternate PCEs.
Note that the latter information is optional in the context of the The PCE discovery mechanism MAY also allow disclosing detailed PCE
PCE discovery mechanism. It could also be obtained by other information. This comprises discovery of PCE path computation
mechanisms, such as for instance the PCC-PCE communication protocol. capabilities and alternate PCEs. This information is not strictly
speaking part of PCE discovery; this is additional information that
can facilitate the selection of a PCE. Support of this information is
optional in the context of the PCE discovery mechanism itself. This
does not mean that this is optional in the PCE architecture. Such
information could also be obtained by other mechanisms, such as for
instance the PCC-PCE communication protocol.
6.1.1. Discovery of PCE Location 6.1.1. General PCE Information (Mandatory support)
6.1.1.1. Discovery of PCE Location
The PCE discovery mechanism MUST allow discovering, for a given PCE, The PCE discovery mechanism MUST allow discovering, for a given PCE,
the IPv4 and/or IPv6 address to be used to reach the PCE. This the IPv4 and/or IPv6 address to be used to reach the PCE. This
address will typically be a loop-back address that is always address will typically be a loop-back address that is always
reachable, if there is any connectivity to the PCE. reachable, if there is any connectivity to the PCE.
This address will be used by PCCs to communicate with a PCE, thanks This address will be used by PCCs to communicate with a PCE, thanks
to a PCC-PCE communication protocol. to a PCC-PCE communication protocol.
6.1.2. Discovery of PCE computation scope(s) and domain(s) under 6.1.1.2. Discovery of PCE domain(s) and inter-domain functions
control
Inter-domain path computation is a key application of the PCE Inter-domain path computation is a key application of the PCE
architecture. This can rely on a multiple-PCE path computation, architecture. This can rely on a multiple-PCE path computation,
where PCEs in each domain compute a part of the end-to-end path and where PCEs in each domain compute a part of the end-to-end path and
collaborate with each other to find the end-to-end-path. This can collaborate with each other to find the end-to-end-path. This can
also rely on a single-PCE path computation where a PCE has visibility also rely on a single-PCE path computation where a PCE has visibility
inside multiple domains and can compute an inter-domain path. inside multiple domains and can compute an inter-domain path.
Hence the PCE discovery mechanism MUST allow discovering the path Hence the PCE discovery mechanism MUST allow discovering the set of
computation scope of a PCE, i.e. if a PCE can be used to compute or
to take part in the computation of intra-area, inter-area or inter-AS
TE-LSP. Note that these path computation scopes are not mutually
exclusive.
Also the PCE discovery mechanism MUST allow discovering the set of
one or more domains under the path computation responsibility of a one or more domains under the path computation responsibility of a
PCE, i.e. where a PCE has visibility and can compute paths. These PCE, i.e. where a PCE has visibility and can compute paths. These
domains can be identified using a domain identifier: For instance, an domains can be identified using a domain identifier: For instance, an
IGP area can be identified by the Area ID (OSPF or ISIS), and an AS IGP area can be identified by the Area ID (OSPF or ISIS), and an AS
can be identified by the AS number. can be identified by the AS number.
It MUST also allow discovering the set of one or more domain(s)
towards which a PCE can compute paths.
6.1.3. Discovery of PCE Capabilities Also the PCE discovery mechanism MUST allow discovering the potential
inter-domain function(s) of a PCE, i.e. if a PCE can be used to
compute or to take part in the computation of end-to-end paths across
domains. The inter-domain functions include: inter-area, inter-AS or
inter-layer path computation. Note that these functions are not
mutually exclusive.
Note that the inter-domain functions differ from the set of domains
under control of a PCE. For instance a PCE may have visisbility
limited to a single domain, but may be able to take part into the
computation of inter-domain paths, by collaborating with PCEs in
other domains.
The PCE discovery mechanisms MUST also allow discovering the set of
one or more domain(s) towards which a PCE can compute paths. For
instance in an inter-AS path computation context, there may be
several PCEs in an AS, each one responsible for taking part in the
computation of inter-AS path towards a set of one or more destination
ASes, and a PCC must discover the destination ASes each PCE is
responsible for.
6.1.2. Detailed PCE Information (Optional support)
6.1.2.1. Discovery of PCE Capabilities
In the case where there are several PCEs with distinct capabilities In the case where there are several PCEs with distinct capabilities
available, a PCC has to select one or more appropriate PCEs. available, a PCC has to select one or more appropriate PCEs.
For that purpose the PCE discovery mechanism MAY be used so as to For that purpose the PCE discovery mechanism MAY be used so as to
disclose some PCE capabilities. disclose some PCE capabilities.
For the sake of illustration this could include for instance some For the sake of illustration this could include for instance some
path computation related capabilities: path computation related PCE capabilities:
-The capability to compute MPLS-TE and/or GMPLS paths; -The capability to compute MPLS-TE and/or GMPLS paths;
-The type of link and path constraints supported: e.g. -The type of link and path constraints supported: e.g.
bandwidth, affinities, delay; bandwidth, affinities, delay;
-The objective functions supported: e.g. shortest constrained -The objective functions supported: e.g. shortest constrained
path, shortest bounded delay path; path, shortest bounded delay path;
-The capability to compute multiple paths in a synchronized -The capability to compute multiple paths in a synchronized
manner: e.g. diverse path computation, load balancing manner: e.g. diverse path computation, load balanced paths
computation; computation;
-Some GMPLS specific capabilities: e.g. the supported interface -Some GMPLS specific capabilities: e.g. the supported interface
switching capabilities, the support for multi-layer switching capabilities, the support for multi-layer
path computation; path computation;
And this could also include some general capabilities:
And this could also include some specific PCE capabilities:
-The capability to handle request prioritization; -The capability to handle request prioritization;
-The capability to authenticate PCCs and to be authenticated. -The capability to authenticate PCCs and to be authenticated.
-The maximum number of path computation requests per message
-The PCE computation power (static parameters to be used for
weighted load balancing of requests)
Such information regarding PCE capabilities could then be used by a Such information regarding PCE capabilities could then be used by a
PCC to select an appropriate PCE from a list of candidate PCEs. PCC to select an appropriate PCE from a list of candidate PCEs.
Note that the description of general and path computation specific Note that the exact definition and description of PCE capabilities is
PCE capabilities is out of the scope of this document. It is expected out of the scope of this document. It is expected that this will be
that this will be described in a separate document. described in one or more separate document(s) which may be
application specific.
It is paramount that dynamic discovery of PCE capabilities MUST NOT It is paramount that dynamic discovery of PCE capabilities MUST NOT
generate an excessive amount of information and SHOULD be limited to generate an excessive amount of information and SHOULD be limited to
a small set of generic capabilities. a small set of generic capabilities.
If required, the exhaustive discovery of detailed capabilities could If required, the exhaustive discovery of all detailed PCE
be ensured by means of the PCC-PCE communication protocol. capabilities could be ensured by means of the PCC-PCE communication
protocol.
Actually a tradeoff should be found between capability discovery by Actually a tradeoff should be found between capability discovery by
the PCE discovery mechanism and by the PCC-PCE communication the PCE discovery mechanism and by the PCC-PCE communication
protocol. One of the objectives of the PCE discovery mechanism is to protocol. One of the objectives of the PCE discovery mechanism is to
help PCCs to select appropriate PCEs and limit the likelihood of PCC- help PCCs to select appropriate PCEs and limit the likelihood of PCC-
PCE communication rejections that may occur in case a PCE cannot PCE session rejections that may occur in case a PCE cannot support a
support a given capability. given capability.
6.1.4. Discovery of Alternate PCEs 6.1.2.2. Discovery of Alternate PCEs
In the case of a PCE failure, a PCC has to select another PCE, if one In the case of a PCE failure, a PCC has to select another PCE, if one
is available. It could be useful in various situations, to indicate a is available. It could be useful in various situations, to indicate a
set of one or more alternate PCEs that can be selected in case a set of one or more alternate PCEs that can be selected in case a
given PCE fails. given PCE fails.
Hence the PCE Discovery mechanism MAY allow the discovery, for a
Hence the PCE Discovery mechanism SHOULD allow the advertising, for a given PCE, of the location of one or more assigned alternate PCEs.
given PCE of the location of one or more assigned alternate PCEs. The PCE Discovery mechanism MAY also allow the discovery, for a given
PCE, of the set of one ore more PCEs for which it acts as alternate
PCE.
6.2. Scope of PCE Discovery 6.2. Scope of PCE Discovery
The PCE Discovery mechanism MUST allow the control of the scope of The PCE Discovery mechanism MUST allow the control of the scope of
the PCE information discovery (IGP Area, AS, set of AS) on a per PCE the PCE information discovery (IGP Area, AS, set of AS) on a per PCE
basis. In other words it MUST allow to control to which PCC or group basis. In other words it MUST allow to control to which PCC or group
of PCCs the information related to a PCE may be disclosed. of PCCs the information related to a PCE may be disclosed.
The choice for the discovery scope of a given PCE MUST include the The choice for the discovery scope of a given PCE MUST include the
followings: followings:
skipping to change at page 9, line 38 skipping to change at page 10, line 16
Particularly this also implies that the PCE Discovery mechanism MUST Particularly this also implies that the PCE Discovery mechanism MUST
allow for the discovery of PCE information across IGP areas and allow for the discovery of PCE information across IGP areas and
across AS boundaries. across AS boundaries.
Note that it MUST be possible to deactivate PCE discovery on a per Note that it MUST be possible to deactivate PCE discovery on a per
PCE basis. PCE basis.
6.3. PCE Information Synchronization 6.3. PCE Information Synchronization
The PCE discovery mechanism MUST allow a PCC to detect any change in The PCE discovery mechanism MUST allow a PCC to detect any change in
the information related to a PCE (e.g. capability modifications). the information related to a PCE. This includes both general
information (e.g. PCE domain(s) modification), and detailed
information if supported (e.g. capability modification).
In addition it MUST be possible to dynamically detect new PCEs. In addition it MUST be possible to dynamically detect new PCEs.
The PCE Discovery Mechanism SHOULD allow such detection under 60 The PCE Discovery Mechanism SHOULD allow such detection under 60
seconds. seconds.
Note that PCE information is expected to be fairly stable and not to Note that PCE information is relatively static and is expected to be
change frequently. fairly stable and not to change frequently.
6.4. Detecting PCE Liveliness 6.4. Detecting PCE Liveliness
The PCE discovery mechanism MUST allow a PCC to detect when a PCE is The PCE discovery mechanism MUST allow a PCC to detect when a PCE is
no longer alive. This allows a PCC to rapidly switch to another PCE no longer alive or is deactivated. This allows a PCC to rapidly
(for instance a predefined alternate PCE), and thus minimizes path switch to another PCE (for instance a predefined alternate PCE), and
computation service disruption. thus minimizes path computation service disruption.
The PCE discovery mechanism SHOULD allow such detection under 60 The PCE discovery mechanism SHOULD allow such detection under 60
seconds. seconds.
6.5. Discovery of PCE capacity and congestion Note that such detection could also be ensured by the PCC-PCE
communication protocol (see [PCE-COM-REQ]).
PCE WG feedback is requested on the following items: 6.5. Security Requirements
-Is there a need for the discovery of PCE capacity in terms of
computation power? This static parameter could be used to
ensure weighted load balancing of requests in case PCEs do not
have the same capacity.
-May the PCE discovery mechanism be used so that a PCE report
its status as "congested" in case it is too busy? PCCs may then
use this dynamic information to prefer a different PCE.
6.6. Security Requirements The three major threats related to PCE discovery mechanisms are:
-Impersonation of PCE
-Interception of PCE discovery information
-Falsification of PCE discovery information
-Information disclosure to non-authorized PCCs.
The PCE Discovery mechanism MUST address security issues across Hence mechanisms MUST be defined to ensure authentication, integrity
multiple ASes. and privacy of PCE discovery information:
-There MUST be a mechanism to authenticate discovery information
-There MUST be a mechanism to verify discovery information
integrity
-There MUST be a mechanism to encrypt discovery information
-There MUST be a mechanism to restrict the scope of discovery to
a set of authorized PCCs. In particular, the identity of any
PCE MUST only be learnt by authorized PCCs (see also 6.2).
Key consideration MUST be given in terms of how to establish a trust This is of particular importance in an inter-AS context, where PCE
model for PCE discovery. The PCE discovery mechanism MUST explicitly discovery may increase the vulnerability to attacks and the
support a specific set of one ore more trust model(s). consequences of these attacks.
The PCE discovery mechanism MUST deliver the operational security The PCE discovery mechanism MUST deliver the operational security
objectives where required. The overall security objectives of objectives where required. The overall security objectives of
privacy, authentication, and integrity may take on varying level of privacy, authentication, and integrity may take on varying level of
importance. These objectives MAY be met by other established means importance. These objectives MAY be met by other established means
and protocols. and protocols.
Particularly, mechanisms MUST be defined to ensure authentication, Also, key consideration MUST be given in terms of how to establish a
integrity and privacy of PCE discovery information. trust model for PCE discovery. The PCE discovery mechanism MUST
explicitly support a specific set of one ore more trust model(s).
It MUST be possible to restrict the scope of discovery to a set of
authorized PCCs. In particular, the identity of any PCE MUST only be
learnt by authorized PCCs.
It MUST be possible for PCEs to authenticate PCCs and for PCCs to
authenticate PCEs. It MUST also be possible to encrypt discovery
information.
6.7. Extensibility 6.6. Extensibility
The PCE discovery mechanism MUST be flexible and extensible so as to The PCE discovery mechanism MUST be flexible and extensible so as to
easily allow for the inclusion of some additional PCE information easily allow for the inclusion of some additional PCE information
that could be defined in the future. that could be defined in the future.
6.8. Scalability 6.7. Scalability
The PCE discovery mechanism MUST be designed to scale well with an The PCE discovery mechanism MUST be designed to scale well with an
increase of any of the following parameters: increase of any of the following parameters:
-Number of PCCs; -Number of PCCs discovering a given PCE;
-Number of PCEs; -Number of PCEs to be discovered by a given PCC;
-Number of IGP Areas in the discovery scope; -Number of domains in the discovery scope;
-Number of ASs in the discovery scope.
Particularly, in case routing protocols (IGP, BGP) are extended to Particularly, in case routing protocols (IGP, BGP) are extended to
support PCE discovery, the extensions MUST NOT cause a degradation in support PCE discovery, the extensions MUST NOT cause a degradation in
routing protocol performance. The same applies to a signaling routing protocol performance. The same applies to a signaling
solution that could serve for this discovery. solution that could serve for this discovery.
6.8. Operational orders of magnitudes
This section gives minimum order of magnitude estimates of what the
PCE discovery mechanism should support
Number of PCCs discovering a given PCE: 1000
Number of PCEs to be discovered by a given PCC: 100 (e.g. inter-area
case with ABRs acting as PCE).
Number of IGP areas in the discovery scope: 100
Number of ASes in the discovery scope: 100
Information disclosed in the PCE discovery mechanism is relatively
static. Changes in PCE information may occur as result of PCE
configuration updates, PCE deployment/activation or PCE
deactivation/suppression, and should not occur as a result of the PCE
activity itself.
Hence, this information is quite stable and will not change
frequently.
7. Security Considerations 7. Security Considerations
This document is a requirement document and hence does not raise by This document is a requirement document and hence does not raise by
itself any particular security issue. itself any particular security issue.
A set of security requirements that MUST be addressed when A set of security requirements that MUST be addressed when
considering the design and deployment of a PCE Discovery mechanism considering the design and deployment of a PCE Discovery mechanism
have been identified in section 6.6. have been identified in section 6.5.
8. Acknowledgments 8. Acknowledgments
We would like to thank Benoit Fondeviole, Thomas Morin, Emile We would like to thank Benoit Fondeviole, Thomas Morin, Emile
Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai
Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin and Dimitri Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri
Papadimitriou, for their useful comments and suggestions. Papadimitriou, Arthi Ayyangar and Andrew Dolganow for their useful
comments and suggestions.
9. References 9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004. 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
 End of changes. 56 change blocks. 
131 lines changed or deleted 186 lines changed or added

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