PCE Working Group JL Le Roux
France Telecom
Internet Draft Paul Mabey
Qwest
Raymond Zhang
Infonet
Eiji Oki
NTT
Ting Wo Chung
Bell Canada
Category: Informational
Expires: August 2005 February 2005
Requirements for Path Computation Element (PCE) Discovery
draft-leroux-pce-discovery-reqs-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Le Roux et al. [Page 1]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
Abstract
This document presents a set of requirements for a Path Computation
Element (PCE) discovery mechanism that would allow a Path Computation
Client (PCC) to discover dynamically and automatically a set of PCEs
along with their capabilities. It is intended that solutions that
specify procedures and protocol extensions for such PCE discovery
satisfy these requirements.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Terminology.................................................3
2. Introduction................................................3
3. Problem Statement and Requirements overview.................4
3.1. Problem Statement...........................................4
3.2. Requirements overview.......................................5
4. Examples of application scenarios...........................5
5. Detailed Requirements.......................................5
5.1. Discovery of PCE location...................................5
5.2. Discovery of PCE capabilities...............................6
5.3. Discovery of Backup PCEs....................................7
5.4. Scope of PCE Discovery......................................7
5.5. PCE Information Synchronization.............................7
5.6. Detecting PCE Liveliness....................................8
5.7. PCE Selection...............................................8
5.8. Scalability.................................................8
6. Security Considerations.....................................8
7. Intellectual Property Statement.............................9
7.1. IPR Disclosure Acknowledgement..............................9
8. Acknowledgments.............................................9
9. References..................................................9
10. Authors' Addresses:.........................................9
Le Roux et al. [Page 2]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
1. Terminology
Terminology used in this document
LSR: Label Switch Router.
PCC: Path Computation Client: any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: an entity (component, application,
or network node) that is capable of computing a network path or
route based on a network graph or topology, and applying
computational constraints.
IGP Area: OSPF Area or ISIS level
Intra-area TE LSP: TE LSP whose path does not cross area
boundaries.
Inter-area TE LSP: A TE LSP whose path transits at least through
two different IGP areas.
Inter-AS MPLS TE LSP: A TE LSP whose path transits at
least through two different ASes or sub-ASes (BGP confederations).
Domain: IGP Area or Autonomous System
2. Introduction
The PCE Architecture [PCE-ARCH] defines a Path Computation Element
(PCE) as an entity capable of computing TE-LSPs paths satisfying a
set of constraints. The PCE function can be located on a router, a
LSR or a dedicated network server.
A PCE serves TE-LSP path computation requests sent by Path
Computation Clients (PCC).
A Path Computation Client (PCC) can be an LSR or a PCE.
Note that in this document the notion of PCC encompasses PCEs acting
as PCCs when requesting a TE-LSP path computation of another PCE.
The PCE architecture has various applications, such as CPU intensive
path computation, inter-domain path computation or backup path
computation.
The PCE architecture requires, of course, that PCCs be aware of the
location of one or more PCEs in its domain, and also potentially of
some relevant PCEs in other domains (in the context of inter-domain
path computation), along with their capabilities.
Le Roux et al. [Page 3]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
In that context it would be highly desirable to define a mechanism
for automatic and dynamic PCE discovery, which would allow PCCs, to
automatically discover a set of PCEs along with their capabilities,
and to dynamically detect new PCEs or any modification of the PCE
capabilities.
This includes the discovery by a PCE of a set of PCEs in its domain
and in other domains, which is highly required for inter-domain path
computation implying inter-PCE communication.
This document lists a set of functional requirements for such an
automatic and dynamic PCE discovery mechanism. The problem statement
is pointed out in section 3. Section 4 illustrates several
applications scenarios. Finally detailed requirements are addressed
in section 5.
It is intended that solutions that specify procedures and protocol
extensions for such PCE discovery satisfy these requirements. There
is no intent neither to specify solution specific requirements nor to
make any assumption on the protocol(s) that could be used for the
discovery.
Note that requirements listed in this document apply equally to MPLS-
TE and GMPLS capable PCEs.
Note that current version of this document does not make any
distinction between PCC-PCE discovery and PCE-PCE discovery. This may
be addressed in future revisions.
3. Problem Statement and Requirements overview
3.1. Problem Statement
A routing domain may in practice comprise of multiple PCEs:
-Path computation load may be balanced among a set of PCEs, for
scalability purposes;
-There can be several PCEs with distinct path computation
capabilities (P2P, P2MP, backupà) and distinct computation
scopes (intra-area, inter-area, inter-AS, inter-layer);
-For redundancy purpose primary and backup PCEs may be used.
In order to allow for efficient PCE selection by PCCs and efficient
load balancing of requests, a PCC must have knowledge of the location
of PCEs in its domain, along with their capabilities, and also
potentially of some relevant PCEs in other domains (for inter-domain
path computation purpose).
Such PCE information could be learnt manually by configuring, on each
PCC, a set of PCEs along with their capabilities and scopes. Such
manual configuration approach may be sufficient, and even desired in
some particular situations, but it obviously faces several
limitations:
Le Roux et al. [Page 4]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
-This may imply a huge configuration overhead;
-This would not allow detecting that a new PCE is alive or
that an existing PCE disappears, or when there is a change in
PCE capabilities.
Furthermore, as with any manual configuration approach, this may lead
to undesirable configuration errors.
Hence, an automatic PCE discovery mechanism allowing a PCC to
automatically discover a set of PCEs and their capabilities is highly
required.
3.2. Requirements overview
A PCE discovery mechanism compliant with this document MUST allow a
PCC to automatically discover a set of PCEs in its domain and also,
potentially, PCEs of other domains that are relevant for inter-domain
path computation purpose. The discovery procedure MUST also allow
learning information about a set of PCE capabilities.
A PCE discovery mechanism compliant with this draft MUST allow PCCs
to dynamically discover that a new PCE has been activated or that a
PCE capability has changed.
A PCE Discovery mechanism SHOULD also allow PCCs to dynamically
discover that a PCE is no longer alive.
Note that such PCE liveliness information can also be obtained thanks
to a PCC-PCE communication protocol.
4. Examples of application scenarios
This section will be completed in next revisions of this document.
5. Detailed Requirements
5.1. Discovery of PCE location
The PCE Discovery mechanism MUST allow advertising, for a given PCE,
the IP address to be used to reach the PCE. This address will
typically be a loop-back address that is always reachable, (provided
that the PCE node is not isolated).
Le Roux et al. [Page 5]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
5.2. Discovery of PCE capabilities
In case there are several PCEs available, a PCC has to select an
appropriate PCE.
For that purpose the PCE Discovery mechanism MUST allow advertising,
some PCE path computation capabilities, such as:
-The type of path than can be computed: P2P, P2MP, Primary, Backupà
-The capability to handle multiple path constraints.
-The capability to handle computation of multiple paths in a single
pass, i.e. when a PCE can compute more than one path obeying a set
of specified constraints, in a synchronized manner.
-The capability to support computation of diverse paths.
-The capability to support path computation request prioritization.
The notion of request priority allows a PCC to specify the degree of
urgency of a particular request.
-The capability to act as stateful PCE.
-GMPLS specific path computation capabilities such as
-The switching capabilities supported (PSC, L2SC, TDM, LSC,
FSC);
-The list of link and path constraints supported (delay,
polarization, optical powerà);
-The capability to support inter-layer path computation;
-The capability to support lower-layer path setup control;
-The capability to support path computation in a domain made of
MPLS and GMPLS capable nodes.
-Intra/Inter domain capabilities
-The supported path computation scopes: intra-area, inter-
area or Inter-AS. That is the capability to compute or
take part into the computation of intra area, inter area or
inter-AS TE LSPs.
-The identifiers of the domain(s) (area IDs, AS numbersà) where
the PCE can compute paths.
-The PCE capacity in terms of computation power.
This could be used to ensure weighted load balancing of requests in
case PCEs do not have the same capacity.
Such information regarding PCE capabilities could then be used by a
PCC to select an appropriate PCE among a list of candidate PCEs, and
to ensure efficient load balancing of path computation reqests among
PCEs.
Le Roux et al. [Page 6]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
5.3. Discovery of Backup PCEs
In case of PCE failure, a PCC has to select another PCE. It could be
useful in various situations, to indicate a set of one or more backup
PCEs, to be selected in case a given PCE fails.
Hence the PCE Discovery mechanism SHOULD allow advertising, for a
given PCE, the location of one or more backup PCEs.
5.4. Scope of PCE Discovery
The PCE Discovery mechanism MUST allow controlling the scope of PCE
information discovery (IGP Area, AS, set of AS) on a per PCE basis.
In other words it MUST allow controlling to which PCC or group of
PCCs the information related to a PCE will be advertised.
The choice for the discovery scope of a given PCE MUST include the
followings:
-All PCCs in a single IGP area
-All PCCs in a set of adjacent IGP areas
-All PCCs in a single AS
-All PCCs in a group of ASs
-A set of one or more PCCs in a set of one or more ASs
Particularly this also implies that the PCE Discovery mechanism MUST
allow for the discovery of PCE information across IGP areas and
across AS boundaries.
Note that it MUST be possible to deactivate PCE discovery on a per
PCE basis.
5.5. PCE Information Synchronization
The PCE discovery mechanism MUST allow a PCC to detect any change in
the information related to a PCE (e.g. capability modifications).
Also it MUST be possible to dynamically detect new PCEs.
The delay for such detection MUST be beyond 60s.
Note that PCE capabilities are expected to be quite stable and not to
change frequently.
Le Roux et al. [Page 7]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
5.6. Detecting PCE Liveliness
The PCE discovery mechanism SHOULD allow a PCC detecting when a PCE
is no longer alive. This allows a PCC to rapidily switch to another
PCE (for instance a pre defined backup PCE), and thus minimizes path
computation service disruption.
Note that such PCE liveliness information could also be obtained
thanks to a PCC-PCE communication protocol.
In case PCE discovery is used for PCE liveliness detection, the delay
for PCE failure detection SHOULD be of the order of several seconds,
and MUST not go beyond 60 seconds.
5.7. PCE Selection
A PCC may have to select among a set of candidate PCEs having the
same capabilities. A specific PCE selection algorithm SHOULD be
defined in order to ensure consistency in load balancing behavior and
avoid all PCC sending all the requests to only one PCE. The precise
requirements and mechanisms for this function are out of the scope of
this document. It is expected that this requirement will be covered
in another document.
5.8. Scalability
The PCE discovery mechanism MUST be designed to scale well with an
increase of any of the following parameters:
-Number of PCCs;
-Number of PCEs;
-Number of IGP Areas in the discovery scope;
-Number of ASs in the discovery scope.
Particularly, in case routing protocols (IGP, BGP) are extended to
support PCE discovery, the extensions MUST not cause a degradation of
routing protocol performances.
6. Security Considerations
PCE discovery and particularly inter-AS PCE discovery may raise new
security issues that will be addressed in future revisions of this
document.
Le Roux et al. [Page 8]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
7. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org..
7.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
8. Acknowledgments
We would like to thank Benoit Fondeviole, Thomas Morin, Emile Stephan
and Jean-Philippe Vasseur, for their useful comments and suggestions.
9. References
[PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element
(PCE) Architecture", draft-ash-pce-architecture-00.txt, work in progress.
10. Authors' Addresses:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@francetelecom.com
Le Roux et al. [Page 9]
Internet Draft draft-leroux-pce-discovery-reqs-00.txt February 2005
Paul Mabey
Qwest Communications
950 17th Street,
Denver, CO 80202, USA
Email: pmabey@qwest.com
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025
USA
Email: raymond_zhang@infonet.com
Eiji Oki
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Ting Wo Chung
Bell Canada
181 Bay Street, Suite 350
Toronto, Ontario, Canada, M5J 2T3
Email: ting_wo.chung@bell.ca
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Le Roux et al. [Page 10]