draft-ietf-pce-discovery-reqs-02.txt   draft-ietf-pce-discovery-reqs-03.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: March 2006 Expires: August 2006
October 2005 February 2006
Requirements for Path Computation Element (PCE) Discovery Requirements for Path Computation Element (PCE) Discovery
draft-ietf-pce-discovery-reqs-02.txt draft-ietf-pce-discovery-reqs-03.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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 protocols or
extensions to existing protocol(s) for such PCE discovery satisfy extensions to existing protocols for such PCE discovery satisfy these
these requirements. 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
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. General PCE Information (Mandatory support).................7 6.1.1. General PCE Information (Mandatory support).................7
6.1.1.1. Discovery of PCE Location.................................7 6.1.1.1. Discovery of PCE Location.................................7
6.1.1.2. Discovery of PCE domain(s) and inter-domain functions.....7 6.1.1.2. Discovery of PCE Domains and Inter-domain Functions.......8
6.1.2. Detailed PCE Information (Optional support).................8 6.1.2. Detailed PCE Information (Optional support).................8
6.1.2.1. Discovery of PCE Capabilities.............................8 6.1.2.1. Discovery of PCE Capabilities.............................8
6.1.2.2. Discovery of Alternate PCEs...............................9 6.1.2.2. Discovery of Alternate PCEs...............................9
6.2. Scope of PCE Discovery......................................9 6.2. Scope of PCE Discovery......................................9
6.2.1. Inter-AS specific requirements.............................10
6.3. PCE Information Synchronization............................10 6.3. PCE Information Synchronization............................10
6.4. Detecting PCE Liveliness...................................10 6.4. Discovery of PCE deactivation..............................11
6.5. Security Requirements......................................10 6.5. Policy Support.............................................11
6.6. Extensibility..............................................11 6.6. Security Requirements......................................11
6.7. Scalability................................................11 6.7. Extensibility..............................................12
6.8. Operational orders of magnitudes...........................11 6.8. Scalability................................................12
7. Security Considerations....................................12 6.9. Operational orders of magnitudes...........................12
8. Acknowledgments............................................12 6.10. Manageability considerations...............................13
9. References.................................................12 7. Security Considerations....................................13
10. Authors' Addresses:........................................12 8. Acknowledgments............................................13
11. Intellectual Property Statement............................13 9. References.................................................13
9.1. Normative references.......................................13
9.2. Informative references.....................................13
10. Authors' Addresses:........................................13
11. Intellectual Property Statement............................14
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 13 skipping to change at page 3, line 14
Raymond Zhang (BT Infonet) Raymond Zhang (BT Infonet)
2. Terminology 2. Terminology
Terminology used in this document Terminology used in this document
LSR: Label Switch Router LSR: Label Switch Router
TE-LSP: Traffic Engineered Label Switched Path TE-LSP: Traffic Engineered Label Switched Path
PCE: Path Computation Element: an entity (component, application, PCE: Path Computation Element: an entity (component, application, or
or network node) that is capable of computing a network path or network node) that is capable of computing a network path or route
route based on a network graph, and applying computational based on a network graph, and applying computational constraints.
constraints.
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
IGP Area: OSPF Area or ISIS level/area IGP Area: OSPF Area or ISIS level/area
ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router) ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router)
AS: Autonomous System AS: Autonomous System
ASBR: AS Border Router ASBR: AS Border Router
Intra-area TE LSP: A TE LSP whose path does not cross IGP area Intra-area TE LSP: A TE LSP whose path does not cross IGP area
boundaries. boundaries.
Inter-area TE LSP: A TE LSP whose path transits through Inter-area TE LSP: A TE LSP whose path transits through two or more
two or more IGP areas. IGP areas.
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
through two or more ASes or sub-ASes (BGP confederations). more ASs or sub-ASs (BGP confederations).
Domain: any collection of network elements within a common sphere Domain: any collection of network elements within a common sphere of
of address management or path computational responsibility. address management or path computational responsibility. Examples of
Examples of domains include IGP areas and Autonomous Systems. domains include IGP areas and Autonomous Systems.
3. Introduction 3. Introduction
The PCE Architecture [PCE-ARCH] defines a Path Computation Element The PCE-based network Architecture [PCE-ARCH] defines a Path
(PCE) as an entity capable of computing TE-LSPs paths based on a Computation Element (PCE) as an entity capable of computing TE-LSP
network graph, and applying computational constraints. A PCE serves paths based on a network graph, and applying computational
path computation requests sent by Path Computation Clients (PCC). constraints. A PCE serves 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 The PCE based architecture requires, that a PCC be aware of the
architecture to perform a path computation. They are listed in [PCE-
ARCH]. This includes applications such as CPU intensive path
computation, inter-domain path computation and backup path
computation.
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, e.g. in case of inter-domain path some PCEs in other domains, e.g. in case of inter-domain path
computation. 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, to determine additional
for PCE selection, and to dynamically detect new PCEs or any information required for PCE selection, and to dynamically detect new
modification of PCE's information. This includes the discovery by a PCEs or any modification of the PCEs' information. This includes the
PCC of a set of one or more PCEs in its domain, and potentially in discovery by a PCC of a set of one or more PCEs in its domain, and
some other domains. The latter is a desirable function in the case of potentially in some other domains. The latter is a desirable function
inter-domain path computation for example. in the case of 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 4 points out automatic and dynamic PCE discovery mechanism. Section 4 points out
the problem statement. Section 5 illustrates an application scenario. the problem statement. Section 5 illustrates an application scenario.
Finally section 6 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 protocols
or protocol(s) extensions for such PCE discovery satisfy these or protocol extensions for PCE discovery satisfy these requirements.
requirements. There is no intent either to specify solution-specific There is no intent either to specify solution-specific requirements
requirements or to make any assumption on the protocol(s) that could or to make any assumption on the protocols that could be used for the
be used for the discovery. discovery.
Note that requirements listed in this document apply equally to PCEs Note that requirements listed in this document apply equally to PCEs
that are capable of computing paths in MPLS-TE-enabled networks and that are capable of computing paths in MPLS-TE-enabled networks and
PCEs that are capable of computing paths in GMPLS-enabled networks PCEs that are capable of computing paths in GMPLS-enabled networks
(and PCEs capable of both). (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, etc.);
-In an inter-domain context there can be several PCEs with -In an inter-domain context there can be several PCEs with
distinct inter-domain functions (inter-area, distinct inter-domain functions (inter-area, inter-AS, inter-
inter-AS, inter-layer), each PCE being responsible for path layer), each PCE being responsible for path computation in one or
computation in one or more domains. more domains.
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
relies on multiple-PCE path computation with ABRs acting as PCEs, the
backbone area would comprise at least N PCEs. In existing multi-area
networks, N can be quite large (e.g. beyond fifty).
In order to allow for effective PCE selection by PCCs and efficient In order to allow for effective PCE selection by PCCs, that is to
load balancing of requests, a PCC has to know the location of PCEs in select the appropriate PCE based on its capabilities and perform
its domain, along with some information relevant to PCE selection, efficient load balancing of requests, a PCC needs to know the
and also potentially of some PCEs in other domains, for inter-domain location of PCEs in its domain, along with some information relevant
path computation purpose. to PCE selection, and also potentially needs to know the location of
some PCEs in other domains, for inter-domain 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 a
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, (e.g. inter-AS PCE discovery, where
limitations: manual configuration of neighbor PCEs may be preferred for security
-This may imply a substantial configuration overhead (see the reasons), but it obviously faces several limitations:
above example with N PCEs); - This may imply a substantial configuration overhead;
-This would not allow a PCC to dynamically detect that a new - This would not allow a PCC to dynamically detect that a new PCE is
PCE is available, that an existing PCE is no longer available, available, that an existing PCE is no longer available, or that
or that there is a change in the PCE's information. there is a change in the PCE's information.
Furthermore, as with any manual configuration approach, this may lead Furthermore, as with any manual configuration approach, there is a
to undesirable configuration errors. risk of configuration errors.
As an example, in a multi-area network made up of one backbone area
and N peripheral areas, and where inter-area MPLS-TE path computation
relies on multiple-PCE path computation with ABRs acting as PCEs, the
backbone area would comprise at least N PCEs, and the configuration
of PCC would be too cumbersome (e.g. in existing multi-area networks,
N can be beyond fifty).
Hence, an automated PCE discovery mechanism allowing a PCC to Hence, an automated PCE discovery mechanism allowing a PCC to
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 of the PCEs in its domain.
PCEs in other domains, of interest for inter-domain path computation Where inter-domain path computation is required, the PCE discovery
purpose. method MUST allow a PCC to automatically discover the location of
PCEs in other domains that can assist with inter-domain path
computation.
A PCE discovery mechanism MUST allow a PCC to discover the set of one A PCE discovery mechanism MUST allow a PCC to discover the set of one
or more domains under the path computation responsibility of a PCE. or more domains where a PCE has TE topology visibility and can
It MUST also allow the discovery of the potential inter-domain compute paths. It MUST also allow the discovery of the potential
function(s) of a PCE (inter-area, inter-AS, inter-layer…). inter-domain path computation functions of a PCE (inter-area, inter-
AS, inter-layer, etc.).
A PCE discovery mechanism MUST allow the control of the discovery
scope, that is the set of one or more domains (areas, ASs) where
information related to a given PCE has to be disclosed.
A PCE discovery mechanism MUST allow PCCs in a given discovery scope
to dynamically discover that a new PCE has appeared or that there is
a change in PCE's information.
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 PCE is no longer available.
information. It MUST also allow PCCs to dynamically discover that a
PCE is no longer available.
The PCE discovery MUST be secure. In particular, key consideration A PCE discovery MUST support security procedures. In particular, key
MUST be given in terms of how to establish a trust model for PCE consideration MUST be given in terms of how to establish a trust
discovery. model for PCE 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 detailed PCE capabilities. set of detailed PCE capabilities so that the PCC may make advanced
and informed choices about which PCE to use.
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 multi-area/AS network with several PCEs: Figure 1 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. It is 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. It is responsible for path computation in AS2 towards
-The server S1 is a PCE that can be used to compute diverse paths and AS1;
backup paths in area 1. - The server S1 is a PCE that can be used to compute diverse paths
and backup paths in area 1.
The PCE discovery mechanism will allow: By meeting the requirements set out in this document, the PCE
-each LSR in areas 1 and 0 to dynamically discover R3, as a PCE for discovery mechanism will allow:
inter-area path computation as well as its path computation domains: - each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for
area1 and area0; inter-area path computation, and that R3 can compute paths in area0
-each LSR in areas 0 and 2 to dynamically discover R6, as a PCE for and area1;
inter-area path computation, as well as its path computation domains: - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for
area2 and area0; inter-area path computation, and that R6 can compute paths in area2
-each LSR in AS1 and some PCEs in AS2 to dynamically discover R9 as a and area0;
PCE for inter-AS path computation in AS1 towards AS2; - each PCC in AS1 and one or more PCCs in AS2 to dynamically discover
-each LSR in AS2 and some PCEs in AS1 to dynamically discover R12 as R9 as a PCE for inter-AS path computation in AS1 towards AS2;
a PCE for inter-AS path computation in AS2 towards AS1; - each PCC in AS2 and one or more PCCs in AS1 to dynamically discover
-each LSR in area 1 to dynamically discover S1, as a PCE for diverse R12 as a PCE for inter-AS path computation in AS2 towards AS1;
path computation and backup path computation in area1. - each PCC in area 1 to dynamically discover S1, as a PCE for intra-
area path computation in area1, and optionally to discover its path
computation capabilities (diverse path computation and backup path
computation).
6. Detailed Requirements 6. Detailed Requirements
6.1. PCE Information to be disclosed 6.1. PCE Information to be disclosed
We distinguish two levels of PCE information to be disclosed by the We distinguish two levels of PCE information to be disclosed by a PCE
PCE discovery mechanism: discovery mechanism:
-General information, whose disclosure MUST be supported by the - General information. Disclosure MUST be supported by the
PCE discovery mechanism. PCE discovery mechanism.
-Detailed information, whose disclosure MAY be supported by the - Detailed information. Disclosure MAY be supported by the
PCE discovery mechanism. PCE discovery mechanism.
The PCE discovery mechanism MUST allow disclosing general PCE The PCE discovery mechanism MUST allow disclosure of general PCE
information that will allow PCCs to select appropriate PCEs. This information that will allow PCCs to select appropriate PCEs. This
comprises discovery of PCE location, PCE domain(s) and potential PCE comprises discovery of PCE location, PCE domains supported by the
inter-domain function(s). PCEs, and PCE inter-domain functions.
The PCE discovery mechanism MAY also allow disclosing detailed PCE The PCE discovery mechanism MAY also allow disclosure of detailed PCE
information. This comprises discovery of PCE path computation information. This comprises any or all information about PCE path
capabilities and alternate PCEs. This information is not strictly computation capabilities and alternate PCEs. This information is not
speaking part of PCE discovery; this is additional information that part of PCE discovery; this is additional information that can
can facilitate the selection of a PCE. Support of this information is facilitate the selection of a PCE by a PCC. Support of the exchange
optional in the context of the PCE discovery mechanism itself. This of this information is optional in the context of the PCE discovery
does not mean that this is optional in the PCE architecture. Such mechanism itself. This does not mean that the availability of this
information could also be obtained by other mechanisms, such as for information is optional in the PCE-based architecture, but such
instance the PCC-PCE communication protocol. information could also be obtained by other mechanisms, such as the
PCC-PCE communication protocol.
6.1.1. General PCE Information (Mandatory support) 6.1.1. General PCE Information (Mandatory support)
6.1.1.1. Discovery of PCE Location 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 the discovery, for a given
the IPv4 and/or IPv6 address to be used to reach the PCE. This PCE, of the IPv4 and/or IPv6 address to be used to reach the PCE.
address will typically be a loop-back address that is always This 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
to a PCC-PCE communication protocol.
6.1.1.2. Discovery of PCE domain(s) and inter-domain functions This address will be used by PCCs to communicate with a PCE, through
a PCC-PCE communication protocol.
6.1.1.2. Discovery of PCE Domains and Inter-domain Functions
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
where PCEs in each domain compute a part of the end-to-end path and 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. Inter-domain
also rely on a single-PCE path computation where a PCE has visibility path computation can also rely on a single-PCE path computation where
inside multiple domains and can compute an inter-domain path. a PCE has visibility inside multiple domains and can compute an
entire end-to-end inter-domain path (that is a path from the inter-
domain TE-LSP head-end to the inter-domain TE-LSP tail end).
Hence the PCE discovery mechanism MUST allow discovering the set of Hence the PCE discovery mechanism MUST allow the discovery of the set
one or more domains under the path computation responsibility of a of one or more domains where a PCE has visibility and can compute
PCE, i.e. where a PCE has visibility and can compute paths. These paths. These domains could be identified using a domain identifier:
domains can be identified using a domain identifier: For instance, an For instance, an IGP area can be identified by the Area ID (OSPF or
IGP area can be identified by the Area ID (OSPF or ISIS), and an AS ISIS), and an AS can be identified by the AS number.
can be identified by the AS number.
Also the PCE discovery mechanism MUST allow discovering the potential Also the PCE discovery mechanism MUST allow discovery of the inter-
inter-domain function(s) of a PCE, i.e. if a PCE can be used to domain functions of a PCE, i.e. whether a PCE can be used to compute
compute or to take part in the computation of end-to-end paths across or to take part in the computation of end-to-end paths across domain
domains. The inter-domain functions include: inter-area, inter-AS or borders. The inter-domain functions include non exhaustively: inter-
inter-layer path computation. Note that these functions are not area, inter-AS and inter-layer path computation. Note that these
mutually exclusive. 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 Note that the inter-domain functions are not necessarily inferred
one or more domain(s) towards which a PCE can compute paths. For from the set of domains where a PCE has visibility. For instance a
PCE may have visibility 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. Conversely, a PCE may have
visibility in multiple domains but the operator may not want that the
PCE be used for inter-domain path computations.
The PCE discovery mechanisms MUST also allow discovery of the set of
one or more domains toward which a PCE can compute paths. For
instance in an inter-AS path computation context, there may be instance in an inter-AS path computation context, there may be
several PCEs in an AS, each one responsible for taking part in the 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 computation of inter-AS paths toward a set of one or more destination
ASes, and a PCC must discover the destination ASes each PCE is ASs, and a PCC must discover the destination ASs each PCE is
responsible for. responsible for.
6.1.2. Detailed PCE Information (Optional support) 6.1.2. Detailed PCE Information (Optional support)
6.1.2.1. Discovery of PCE Capabilities 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 support the
disclose some PCE capabilities. disclosure of some detailed PCE capabilities.
For the sake of illustration this could include for instance some For the sake of illustration this could include the following path
path computation related PCE capabilities: computation related PCE capabilities:
-The capability to compute MPLS-TE and/or GMPLS paths;
-The type of link and path constraints supported: e.g. - The link constraints supported: e.g. bandwidth, affinities.
bandwidth, affinities, delay; - The path constraints supported: maximum IGP/TE cost, maximum hop
-The objective functions supported: e.g. shortest constrained count;
path, shortest bounded delay path; - The objective functions supported: e.g. shortest path, widest path;
-The capability to compute multiple paths in a synchronized - The capability to compute multiple correlated paths: e.g. diverse
manner: e.g. diverse path computation, load balanced paths paths, load balanced paths;
computation; - The capability to compute bidirectional paths;
-Some GMPLS specific capabilities: e.g. the supported interface - The GMPLS technology specific constraints supported: e.g. the
switching capabilities, the support for multi-layer supported interface switching capabilities, encoding types.
path computation;
And this could also include some specific PCE 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 maximum size of a request message;
-The maximum number of path computation requests per message - The maximum number of path requests in a request message;
-The PCE computation power (static parameters to be used for -The PCE computation power (static parameters to be used for
weighted load balancing of requests) 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 exact definition and description of PCE capabilities is Note that the exact definition and description of PCE capabilities is
out of the scope of this document. It is expected that this will be out of the scope of this document. It is expected that this will be
described in one or more separate document(s) which may be described in one or more separate documents which may be application
application specific. specific.
It is paramount that dynamic discovery of PCE capabilities MUST NOT
generate an excessive amount of information and SHOULD be limited to
a small set of generic capabilities.
If required, the exhaustive discovery of all detailed PCE
capabilities could be ensured by means of the PCC-PCE communication
protocol.
Actually a tradeoff should be found between capability discovery by
the PCE discovery mechanism and by the PCC-PCE communication
protocol. One of the objectives of the PCE discovery mechanism is to
help PCCs to select appropriate PCEs and limit the likelihood of PCC-
PCE session rejections that may occur in case a PCE cannot support a
given capability.
6.1.2.2. 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, for a PCE to
set of one or more alternate PCEs that can be selected in case a indicate a set of one or more alternate PCEs that can be selected in
given PCE fails. case the given PCE fails.
Hence the PCE Discovery mechanism MAY allow the discovery, for a Hence the PCE Discovery mechanism MAY allow the discovery, 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 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, of the set of one or more PCEs for which it acts as alternate
PCE. 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 control of the scope of the
the PCE information discovery (IGP Area, AS, set of AS) on a per PCE PCE information disclosure on a per PCE basis. In other words it MUST
basis. In other words it MUST allow to control to which PCC or group allow control of to which PCC or group of PCCs the information
of PCCs the information related to a PCE may be disclosed. 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 at
followings: least the followings settings:
-All PCCs in a single IGP area -All PCCs in a single IGP area
-All PCCs in a set of adjacent IGP areas -All PCCs in a set of adjacent IGP areas
-All PCCs in a single AS -All PCCs in a single AS
-All PCCs in a set of ASes - All PCCs in a set of ASs
-A set of one or more PCCs in a set of one or more ASes
Particularly this also implies that the PCE Discovery mechanism MUST - A set of one or more PCCs in a set of one or more ASs
allow for the discovery of PCE information across IGP areas and
In particular, this also implies that the PCE Discovery mechanism
MUST 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 The discovery scope MUST be configurable on a per PCE basis.
PCE basis.
It MUST be possible to deactivate PCE discovery on a per PCE basis.
6.2.1. Inter-AS specific requirements
When using a PCE-based approach for inter-AS path computation, a PCC
in one AS may need to learn information related to inter-AS capable
PCEs located in other ASs. For that purpose, and as pointed out in
the previous section, the PCE discovery mechanism MUST allow
disclosure of information related to inter-AS capable PCEs across AS
boundaries.
Such inter-AS PCE discovery must be carefully controlled. For
security and confidentiality reasons, particularly in an inter-
provider context, the discovery mechanism MUST allow the discovery
scope to be limited to a set of ASs and MUST also provide control of
the PCE information to be disclosed across ASs. This is achieved by
applying policies (See also section 6.4). This implies the capability
to contain a PCE advertisement to a restricted set of one or more
ASs, and to filter and translate any PCE parameter (PCE domains, PCE
inter-domain functions, PCE capabilities, etc.) in disclosures that
cross AS borders. For the sake of illustration, it may be useful to
disclose detailed PCE information (such as detailed capabilities)
locally in the PCE's AS but only general information (such as
location and supported domains) in other ASs.
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 discover any change
the information related to a PCE. This includes both general in the information related to a PCE that it has previously
information (e.g. PCE domain(s) modification), and detailed discovered. This includes changes to both general information (e.g.
information if supported (e.g. capability modification). a change in the PCE domains supported), and detailed information if
In addition it MUST be possible to dynamically detect new PCEs. supported (e.g. a modification of the PCE's capabilities).
The PCE Discovery Mechanism SHOULD allow such detection under 60 In addition, the PCE discovery mechanism MUST allow to dynamically
seconds. discover new PCEs in a given discovery scope.
Note that PCE information is relatively static and is expected to be Note that there is no requirement for real-time detection of these
fairly stable and not to change frequently. changes, the PCE Discovery Mechanism SHOULD rather allow discovery of
these changes in an order of magnitude of 60 seconds, and the
operator should have the ability to configure the Discovery delay.
6.4. Detecting PCE Liveliness Note that PCE information is relatively static, and is expected to be
fairly stable and to not change frequently.
The PCE discovery mechanism MUST allow a PCC to detect when a PCE is 6.4. Discovery of PCE deactivation
no longer alive or is deactivated. This allows a PCC to rapidly
switch to another PCE (for instance a predefined alternate PCE), and
thus minimizes path computation service disruption.
The PCE discovery mechanism SHOULD allow such detection under 60 The PCE discovery mechanism MUST allow a PCC to discover when a PCE
seconds. that it has previously discovered is no longer alive or is
deactivated. This may help reducing or avoiding path computation
service disruption.
Note that such detection could also be ensured by the PCC-PCE Note that there is no requirement for real-time detection of PCE
communication protocol (see [PCE-COM-REQ]). failure/deactivation, the PCE Discovery Mechanism SHOULD rather allow
such discovery in an order of magnitude of 60 seconds, and the
operator should have the ability to configure the Discovery delay.
6.5. Security Requirements 6.5. Policy Support
The three major threats related to PCE discovery mechanisms are: The PCE Discovery mechanism MUST allow for policies to restrict the
-Impersonation of PCE discovery scope to a set of authorized domains, to control and
-Interception of PCE discovery information restrict the type and nature of the information to be disclosed, and
-Falsification of PCE discovery information also to filter and translate some information at domains borders. It
-Information disclosure to non-authorized PCCs. MUST be possible to apply these policies on a per PCE basis.
The way these policies could be managed is out of the scope of this
document.
Hence mechanisms MUST be defined to ensure authentication, integrity Note that the Discovery mechanisms MUST allow disclosing policy
and privacy of PCE discovery information: information so as to control the disclosure policies at domain
-There MUST be a mechanism to authenticate discovery information boundaries.
-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).
This is of particular importance in an inter-AS context, where PCE Also, it MUST be possible to apply different policies when disclosing
discovery may increase the vulnerability to attacks and the PCE information to different domains.
consequences of these attacks.
The PCE discovery mechanism MUST deliver the operational security 6.6. Security Requirements
objectives where required. The overall security objectives of
privacy, authentication, and integrity may take on varying level of The five major threats related to PCE discovery mechanisms are:
importance. These objectives MAY be met by other established means - Impersonation of PCE;
and protocols. - Interception of PCE discovery information (sniffing);
- Falsification of PCE discovery information;
- Information disclosure to non-authorized PCCs (PCC spoofing).
- DoS Attacks
Note that security of the PCE Discovery procedures is of particular
importance in an inter-AS context, where PCE discovery may increase
the vulnerability to attacks and the consequences of these attacks.
Hence mechanisms MUST be defined to ensure authenticity, integrity,
privacy, and containment 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 and to filter PCE information disclosed
at domain boundaries (as per defined in 6.5).
Mechanisms MUST be defined in order to limit the impact of a DoS
attack on the PCE discovery procedure (e.g. filter out excessive PCE
information change and flapping PCEs).
Also, key consideration MUST be given in terms of how to establish a Also, key consideration MUST be given in terms of how to establish a
trust model for PCE discovery. The PCE discovery mechanism MUST trust model for PCE discovery. The PCE discovery mechanism MUST
explicitly support a specific set of one ore more trust model(s). explicitly support a specific set of one or more trust models.
6.6. Extensibility 6.7. 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 additional PCE information that
that could be defined in the future. could be defined in the future.
6.7. Scalability 6.8. 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 discovering a given PCE; -Number of PCCs discovering a given PCE;
-Number of PCEs to be discovered by a given PCC; -Number of PCEs to be discovered by a given PCC;
-Number of domains in the discovery scope; - Number of domains in the discovery scope.
Particularly, in case routing protocols (IGP, BGP) are extended to
support PCE discovery, the extensions MUST NOT cause a degradation in
routing protocol performance. The same applies to a signaling
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 The PCE discovery mechanism MUST NOT have an adverse effect in the
Number of PCEs to be discovered by a given PCC: 100 (e.g. inter-area performance of other protocols (especially routing and signaling)
case with ABRs acting as PCE). already operating in the network.
Number of IGP areas in the discovery scope: 100
Number of ASes in the discovery scope: 100
Note that there is no scalability requirement with regards to the
amount of information to be exchanged.
Information disclosed in the PCE discovery mechanism is relatively Information disclosed in the PCE discovery mechanism is relatively
static. Changes in PCE information may occur as result of PCE static. Changes in PCE information may occur as result of PCE
configuration updates, PCE deployment/activation or PCE configuration updates, PCE deployment/activation or PCE
deactivation/suppression, and should not occur as a result of the PCE deactivation/suppression, and should not occur as a result of the PCE
activity itself. activity itself. Hence, this information is quite stable and will not
change frequently.
Hence, this information is quite stable and will not change 6.9. Operational orders of magnitudes
frequently.
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
6.10. Manageability considerations
Manageability of PCE discovery MUST addresses the following
considerations:
- need for a MIB module for PCE discovery;
- configuration implications for the protocol.
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.5. have been identified in section 6.6.
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, Dimitri Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri
Papadimitriou, Arthi Ayyangar and Andrew Dolganow for their useful Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou Berger, Nabil
comments and suggestions. Bitar, and Kenji Kumaki for their useful comments and suggestions.
9. References 9. References
9.1. Normative 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
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture, work in Element (PCE) Architecture", draft-ietf-pce-architecture, work in
progress. progress.
9.2. Informative references
[PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol [PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol
Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in
progress. progress.
10. Authors' Addresses: 10. Authors' Addresses:
Jean-Louis Le Roux Jean-Louis Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Paul Mabey Paul Mabey
Qwest Communications Qwest Communications
950 17th Street, 950 17th Street,
Denver, CO 80202, Denver, CO 80202,
USA USA
Email: pmabey@qwest.com Email: pmabey@qwest.com
Eiji Oki Eiji Oki
NTT NTT
Midori-cho 3-9-11 Midori-cho 3-9-11
skipping to change at page 14, line 23 skipping to change at page 15, line 23
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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
 End of changes. 91 change blocks. 
284 lines changed or deleted 344 lines changed or added

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