Network Working Group                              J.L. Le Roux (Editor)
Internet Draft                                            France Telecom
Category: Informational
Expires: March August 2006

                                                           February 2006

                                                            October 2005

        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

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   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.

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 certain information relevant for PCE selection. It is
   intended that solutions that specify procedures and protocol(s) protocols or
   extensions to existing protocol(s) protocols 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.      Contributors................................................2
   2.      Terminology.................................................3
   3.      Introduction................................................3
   4.      Problem Statement and Requirements overview.................4 Overview.................4
   4.1.    Problem Statement...........................................4
   4.2.    Requirements overview.......................................5
   5.      Example of application scenario.............................6
   6.      Detailed Requirements.......................................7
   6.1.    PCE Information to be disclosed.............................7
   6.1.1.  General PCE Information (Mandatory support).................7
   6.1.1.1.  Discovery of PCE Location.................................7
   6.1.1.2.  Discovery of PCE domain(s) Domains and inter-domain functions.....7 Inter-domain Functions.......8
   6.1.2.  Detailed PCE Information (Optional support).................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.1.  Inter-AS specific requirements.............................10
   6.3.    PCE Information Synchronization............................10
   6.4.    Detecting    Discovery of PCE Liveliness...................................10 deactivation..............................11
   6.5.    Security Requirements......................................10    Policy Support.............................................11
   6.6.    Extensibility..............................................11    Security Requirements......................................11
   6.7.    Scalability................................................11    Extensibility..............................................12
   6.8.    Scalability................................................12
   6.9.    Operational orders of magnitudes...........................11 magnitudes...........................12
   6.10.   Manageability considerations...............................13
   7.      Security Considerations....................................12 Considerations....................................13
   8.      Acknowledgments............................................12      Acknowledgments............................................13
   9.      References.................................................12      References.................................................13
   9.1.    Normative references.......................................13
   9.2.    Informative references.....................................13
   10.     Authors' Addresses:........................................12 Addresses:........................................13
   11.     Intellectual Property Statement............................13 Statement............................14

1. Contributors

   The following are the authors that contributed to the present
   document:

   Jean-Louis Le Roux (France Telecom)
   Paul Mabey (Qwest Communications)
   Eiji Oki (NTT)
   Richard Rabbat (Fujitsu)
   Ting Wo Chung (Bell Canada)
   Raymond Zhang (BT Infonet)

2. Terminology

   Terminology used in this document

   LSR: Label Switch Router

   TE-LSP: Traffic Engineered Label Switched Path

   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, and applying computational constraints.

   PCC: Path Computation Client: any client application requesting a
   path computation to be performed by a Path Computation Element.

   IGP Area: OSPF Area or ISIS level/area

   ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router)

   AS: Autonomous System

   ASBR: AS Border Router

   Intra-area TE LSP: A TE LSP whose path does not cross IGP area
   boundaries.

   Inter-area TE LSP: A TE LSP whose path transits through two or more
   IGP areas.

   Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or
   more ASes ASs or sub-ASes sub-ASs (BGP confederations).

   Domain: any collection of network elements within a common sphere of
   address management or path computational responsibility. Examples of
   domains include IGP areas and Autonomous Systems.

3. Introduction

   The PCE PCE-based network Architecture [PCE-ARCH] defines a Path
   Computation Element (PCE) as an entity capable of computing TE-LSPs TE-LSP
   paths based on a network graph, and applying computational
   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
   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 computation of another PCE (inter-PCE communication). The
   communication between a PCC and a PCE requires a client-server
   protocol whose generic requirements are listed in [PCE-COM-REQ].

   There are several motivations for the adoption of a PCE-based
   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 based architecture requires, of course, that a PCC be aware of the
   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
   computation.

   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, including to determine additional
   information required for PCE selection, and to dynamically detect new
   PCEs or any modification of PCE's the PCEs' information. This includes the
   discovery by a 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 inter-domain path computation computation, for example.

   This document lists a set of functional requirements for such an
   automatic and dynamic PCE discovery mechanism. Section 4 points out
   the problem statement. Section 5 illustrates an application scenario.
   Finally
   Finally, section 6 addresses detailed requirements.

   It is intended that solutions that specify procedures and protocol(s) protocols
   or protocol(s) protocol extensions for such PCE discovery satisfy these requirements.
   There is no intent either to specify solution-specific requirements
   or to make any assumption on the protocol(s) protocols that could be used for the
   discovery.

   Note that requirements listed in this document apply equally to 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
   PCE acting as PCC when requesting a path computation of another PCE
   (inter-PCE communication). Hence, this document does not make the
   distinction between PCE discovery by PCCs and PCE discovery by PCEs.

4. Problem Statement and Requirements overview Overview

4.1. Problem Statement

   A routing domain may may, in practice practice, be comprised of multiple PCEs:
        -The
   - The path computation load may be balanced among a set of PCEs
     to improve scalability;
        -For
   - For the purpose of redundancy, primary and backup PCEs may be
     used;
        -PCEs
   - PCEs may have distinct path computation capabilities (multi-
     constrained path computation, backup path computation...);
        -In computation, etc.);
   - In an inter-domain context there can be several PCEs with
     distinct inter-domain functions (inter-area, inter-AS, inter-layer), inter-
     layer), each PCE being responsible for path computation in one or
     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 PCCs, that is to
   select the appropriate PCE based on its capabilities and perform
   efficient load balancing of requests, a PCC has needs to know the
   location of PCEs in its domain, along with some information relevant
   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
   each PCC, of the set of PCEs along with their capabilities. Such a
   manual configuration approach may be sufficient, and even desired in
   some particular situations, (e.g. inter-AS PCE discovery, where
   manual configuration of neighbor PCEs may be preferred for security
   reasons), but it obviously faces several limitations:
        -This
   - This may imply a substantial configuration overhead (see the
         above example with N PCEs);
        -This overhead;
   - This would not allow a PCC to dynamically detect that a new PCE is
     available, that an existing PCE is no longer available, or that
     there is a change in the PCE's information.

   Furthermore, as with any manual configuration approach, this may lead
   to undesirable there is a
   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
   dynamically discover a set of PCEs is highly desirable.

4.2. Requirements overview

   A PCE discovery mechanism that satisfies the requirements set forth
   in this document MUST allow a PCC to automatically discover the
   location of one or more of the PCEs in its domain and also, potentially, domain.
   Where inter-domain path computation is required, the PCE discovery
   method MUST allow a PCC to automatically discover the location of
   PCEs in other domains, of interest for domains that can assist with inter-domain path computation
   purpose.
   computation.

   A PCE discovery mechanism MUST allow a PCC to discover the set of one
   or more domains under the path computation responsibility of where a PCE. PCE has TE topology visibility and can
   compute paths. It MUST also allow the discovery of the potential
   inter-domain
   function(s) path computation functions of a PCE (inter-area, inter-AS, inter-layer…). 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. It

   A PCE discovery mechanism MUST also allow PCCs to dynamically discover
   that a PCE is no longer available.

   The

   A PCE discovery MUST be secure. support security procedures. In particular, key
   consideration MUST be given in terms of how to establish a trust
   model for PCE discovery.

   OPTIONALLY a PCE discovery mechanism MAY be used so as to disclose a
   set of detailed PCE capabilities. capabilities so that the PCC may make advanced
   and informed choices about which PCE to use.

5. Example of application scenario

   <----------------AS1-------------------->           <----AS2---
    Area 1           Area 0        Area 2
  R1---------R3-----R5-------R6-----------R9----------R11----R13
  |          |               |             |           |
  |          |               |             |           |
  R2---------R4-----R7-------R8-----------R10---------R12----R14
       |
       |
       --
      |S1|
       --

                          Figure 1

   Figure 1 above illustrates a multi-area/AS network with several PCEs:
   -The
   - 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;
   -The
   - The ABR R6 is a PCE that can take part in inter-area path
     computation. It can compute paths in area 0 and area2;
   -The
   - The ASBR R9 is a PCE that can take part in inter-AS path
   computation,
     computation. It is responsible for path computation in AS1 towards
     AS2;
   -The
   - The ASBR R12 is a PCE that can take part in inter-AS path
   computation,
     computation. It is responsible for path computation in AS2 towards
     AS1;
   -The
   - The server S1 is a PCE that can be used to compute diverse paths
     and backup paths in area 1.

   The

   By meeting the requirements set out in this document, the PCE
   discovery mechanism will allow:
   -each LSR
   - each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for
     inter-area path computation as well as its path computation domains:
   area1 computation, and area0;
   -each LSR that R3 can compute paths in area0
     and area1;
   - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for
     inter-area path computation, as well as its path computation domains: and that R6 can compute paths in area2
     and area0;
   -each LSR
   - each PCC in AS1 and some PCEs one or more PCCs in AS2 to dynamically discover
     R9 as a PCE for inter-AS path computation in AS1 towards AS2;
   -each LSR
   - each PCC in AS2 and some PCEs one or more PCCs in AS1 to dynamically discover
     R12 as a PCE for inter-AS path computation in AS2 towards AS1;
   -each LSR
   - each PCC in area 1 to dynamically discover S1, as a PCE for diverse intra-
     area path computation in area1, and backup optionally to discover its path
     computation in area1. capabilities (diverse path computation and backup path
     computation).

6. Detailed Requirements

6.1. PCE Information to be disclosed

   We distinguish two levels of PCE information to be disclosed by the a PCE
   discovery mechanism:
       -General information, whose disclosure
   - General information. Disclosure MUST be supported by the
     PCE discovery mechanism.
       -Detailed information, whose disclosure
   - Detailed information. Disclosure MAY be supported by the
     PCE discovery mechanism.

   The PCE discovery mechanism MUST allow disclosing disclosure of general PCE
   information that will allow PCCs to select appropriate PCEs. This
   comprises discovery of PCE location, PCE domain(s) domains supported by the
   PCEs, and potential PCE inter-domain function(s). functions.

   The PCE discovery mechanism MAY also allow disclosing disclosure of detailed PCE
   information. This comprises discovery of any or all information about PCE path
   computation 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. PCE by a PCC. Support of the exchange
   of this information is optional in the context of the PCE discovery
   mechanism itself. This does not mean that the availability of this
   information is optional in the PCE architecture. Such PCE-based architecture, but such
   information could also be obtained by other mechanisms, such as for
   instance the
   PCC-PCE communication protocol.

6.1.1. General PCE Information (Mandatory support)

6.1.1.1. Discovery of PCE Location

   The PCE discovery mechanism MUST allow discovering, the discovery, for a given
   PCE, of 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
   reachable, if there is any connectivity to the PCE.

   This address will be used by PCCs to communicate with a PCE, thanks
   to through
   a PCC-PCE communication protocol.

6.1.1.2. Discovery of PCE domain(s) Domains and inter-domain functions Inter-domain Functions

   Inter-domain path computation is a key application of the PCE
   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
   collaborate with each other to find the end-to-end-path. This Inter-domain
   path computation can also rely on a single-PCE path computation where
   a PCE has visibility inside multiple domains and can compute an
   entire end-to-end inter-domain path. 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 discovery of the set
   of one or more domains under the path computation responsibility of a
   PCE, i.e. where a PCE has visibility and can compute
   paths. These domains can could be identified using a domain identifier:
   For instance, an IGP area can be identified by the Area ID (OSPF or
   ISIS), and an AS can be identified by the AS number.

   Also the PCE discovery mechanism MUST allow discovering the potential
   inter-domain function(s) discovery of a the inter-
   domain functions of a PCE, i.e. if whether a PCE can be used to compute
   or to take part in the computation of end-to-end paths across
   domains. domain
   borders. The inter-domain functions include: inter-area, include non exhaustively: inter-
   area, inter-AS or and inter-layer path computation. Note that these
   functions are not mutually exclusive.

   Note that the inter-domain functions differ are not necessarily inferred
   from the set of domains
   under control of where a PCE. PCE has visibility. For instance a
   PCE may have visisbility 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 discovering discovery of the set of
   one or more domain(s) towards domains toward 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 paths toward a set of one or more destination
   ASes,
   ASs, and a PCC must discover the destination ASes ASs 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
   available, a PCC has to select one or more appropriate PCEs.

   For that purpose the PCE discovery mechanism MAY be used so as to
   disclose support the
   disclosure of some detailed PCE capabilities.

   For the sake of illustration this could include for instance some the following path
   computation related PCE capabilities:
        -The capability to compute MPLS-TE and/or GMPLS paths;
        -The type of

   - The link and path constraints supported: e.g. bandwidth, affinities, delay;
        -The affinities.
   - The path constraints supported: maximum IGP/TE cost, maximum hop
     count;
   - The objective functions supported: e.g. shortest constrained path, shortest bounded delay widest path;
        -The
   - The capability to compute multiple paths in a synchronized
         manner: correlated paths: e.g. diverse path computation,
     paths, load balanced paths
         computation;
        -Some paths;
   - The capability to compute bidirectional paths;
   - The GMPLS technology specific capabilities: constraints supported: e.g. the
     supported interface switching capabilities, the support for multi-layer
         path computation; encoding types.

   And this could also include some specific PCE capabilities:
        -The
   - The capability to handle request prioritization;
        -The capability to authenticate PCCs and to be authenticated.
        -The
   - The maximum size of a request message;
   - The maximum number of path computation requests per message
        -The in a request message;
   - The PCE computation power (static parameters to be used for
     weighted load balancing of requests) requests).

   Such information regarding PCE capabilities could then be used by a
   PCC to select an appropriate PCE from a list of candidate PCEs.

   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
   described in one or more separate document(s) documents which may be application
   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

   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, for a PCE to
   indicate a set of one or more alternate PCEs that can be selected in
   case a the given PCE fails.

   Hence the PCE Discovery mechanism MAY allow the discovery, for a
   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 or more PCEs for which it acts as alternate
   PCE.

6.2. Scope of PCE Discovery

   The PCE Discovery mechanism MUST allow the control of the scope of the
   PCE information discovery (IGP Area, AS, set of AS) disclosure on a per PCE basis. In other words it MUST
   allow to control of to which PCC or group of PCCs the information
   related to a PCE may be disclosed.

   The choice for the discovery scope of a given PCE MUST include at
   least the
   followings:

        -All followings settings:

   - All PCCs in a single IGP area

        -All
   - All PCCs in a set of adjacent IGP areas

        -All

   - All PCCs in a single AS

        -All

   - All PCCs in a set of ASes
        -A ASs

   - A set of one or more PCCs in a set of one or more ASes

   Particularly ASs

   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.

   Note that it

   The discovery scope MUST be configurable on a per PCE basis.

   It MUST be possible to deactivate PCE discovery on a per PCE basis.

6.3. PCE Information Synchronization

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

   The PCE discovery mechanism MUST allow a PCC to detect discover any change
   in the information related to a PCE. PCE that it has previously
   discovered. This includes changes to both general information (e.g.
   a change in the PCE domain(s) modification), domains supported), and detailed information if
   supported (e.g. capability modification). a modification of the PCE's capabilities).

   In addition it addition, the PCE discovery mechanism MUST be possible allow to dynamically detect
   discover new PCEs.

   The PCEs in a given discovery scope.

   Note that there is no requirement for real-time detection of these
   changes, the PCE Discovery Mechanism SHOULD rather allow such detection under discovery of
   these changes in an order of magnitude of 60
   seconds. seconds, and the
   operator should have the ability to configure the Discovery delay.

   Note that PCE information is relatively static static, and is expected to be
   fairly stable and not to not change frequently.

6.4. Detecting Discovery of PCE Liveliness deactivation

   The PCE discovery mechanism MUST allow a PCC to detect discover when a PCE
   that it has previously discovered is 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 may help reducing or avoiding path computation
   service disruption.

   The

   Note that there is no requirement for real-time detection of PCE discovery mechanism
   failure/deactivation, the PCE Discovery Mechanism SHOULD rather allow
   such detection under discovery in an order of magnitude of 60
   seconds.

   Note that such detection could seconds, and the
   operator should have the ability to configure the Discovery delay.

6.5. Policy Support

   The PCE Discovery mechanism MUST allow for policies to restrict the
   discovery scope to a set of authorized domains, to control and
   restrict the type and nature of the information to be disclosed, and
   also to filter and translate some information at domains borders. It
   MUST be ensured by possible to apply these policies on a per PCE basis.
   The way these policies could be managed is out of the PCC-PCE
   communication protocol (see [PCE-COM-REQ]).

6.5. scope of this
   document.

   Note that the Discovery mechanisms MUST allow disclosing policy
   information so as to control the disclosure policies at domain
   boundaries.

   Also, it MUST be possible to apply different policies when disclosing
   PCE information to different domains.

6.6. Security Requirements

   The three five major threats related to PCE discovery mechanisms are:
        -Impersonation
   - Impersonation of PCE
        -Interception PCE;
   - Interception of PCE discovery information
        -Falsification (sniffing);
   - Falsification of PCE discovery information
        -Information information;
   - Information disclosure to non-authorized PCCs. 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 authentication, integrity authenticity, integrity,
   privacy, and privacy containment of PCE discovery information:
        -There
   - There MUST be a mechanism to authenticate discovery information
        -There information;
   - There MUST be a mechanism to verify discovery information
         integrity
        -There
     integrity;
   - There MUST be a mechanism to encrypt discovery information
        -There information;
   - There MUST be a mechanism to restrict the scope of discovery to a
     set of authorized PCCs. In particular, the identity of any PCCs and to filter PCE information disclosed
     at domain boundaries (as per defined in 6.5).

   Mechanisms MUST only be learnt by authorized PCCs (see also 6.2).

   This is of particular importance defined in an inter-AS context, where PCE
   discovery may increase the vulnerability order to attacks and limit the
   consequences impact of these attacks.

   The a DoS
   attack on the PCE discovery mechanism MUST deliver the operational security
   objectives where required. The overall security objectives of
   privacy, authentication, and integrity may take on varying level of
   importance. These objectives MAY be met by other established means procedure (e.g. filter out excessive PCE
   information change and protocols. flapping PCEs).

   Also, key consideration MUST be given in terms of how to establish a
   trust model for PCE discovery. The PCE discovery mechanism MUST
   explicitly support a specific set of one ore or more trust model(s).

6.6. models.

6.7. Extensibility

   The PCE discovery mechanism MUST be flexible and extensible so as to
   easily allow for the inclusion of some additional PCE information that
   could be defined in the future.

6.7.

6.8. Scalability

   The PCE discovery mechanism MUST be designed to scale well with an
   increase of any of the following parameters:
        -Number
   - Number of PCCs discovering a given PCE;
        -Number
   - Number of PCEs to be discovered by a given PCC;
        -Number
   - Number of domains in the discovery scope;

   Particularly, in case routing protocols (IGP, BGP) are extended to
   support scope.

   The PCE discovery, the extensions discovery mechanism MUST NOT cause a degradation have an adverse effect in the
   performance of other protocols (especially routing protocol performance. The same applies to a signaling
   solution and signaling)
   already operating in the network.

   Note that could serve for this discovery.

6.8. Operational orders of magnitudes

   This section gives minimum order of magnitude estimates of what there is no scalability requirement with regards to the
   PCE discovery mechanism should support

   Number of PCCs discovering a given PCE: 1000
   Number
   amount of PCEs information 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 exchanged.
   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.

6.9. 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

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

   This document is a requirement document and hence does not raise by
   itself any particular security issue.

   A set of security requirements that MUST be addressed when
   considering the design and deployment of a PCE Discovery mechanism
   have been identified in section 6.5. 6.6.

8. Acknowledgments

   We would like to thank Benoit Fondeviole, Thomas Morin, Emile
   Stephan, Jean-Philippe Vasseur, Dean Cheng, Adrian Farrel, Renhai
   Zhang, Mohamed Boucadair, Eric Gray, Igor Bryskin, Dimitri
   Papadimitriou, Arthi Ayyangar and Ayyangar, Andrew Dolganow Dolganow, Lou Berger, Nabil
   Bitar, and Kenji Kumaki for their useful comments and suggestions.

9. References

9.1. Normative references

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   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
   Element (PCE) Architecture", draft-ietf-pce-architecture, work in
   progress.

9.2. Informative references

   [PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE "PCE Communication Protocol
   Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs, work in
   progress.

10. Authors' Addresses:

   Jean-Louis Le Roux (Editor)
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   FRANCE
   Email: jeanlouis.leroux@francetelecom.com

   Paul Mabey
   Qwest Communications
   950 17th Street,
   Denver, CO 80202,
   USA
   Email: pmabey@qwest.com

   Eiji Oki
   NTT
   Midori-cho 3-9-11
   Musashino-shi, Tokyo 180-8585,
   JAPAN
   Email: oki.eiji@lab.ntt.co.jp

   Richard Rabbat
   Fujitsu Laboratories of America
   1240 East Arques Ave, MS 345
   Sunnyvale, CA 94085
   USA
   Email: richard@us.fujitsu.com

   Ting Wo Chung
   Bell Canada
   181 Bay Street, Suite 350
   Toronto, Ontario, M5J 2T3
   CANADA,
   Email: ting_wo.chung@bell.ca

   Raymond Zhang
   BT Infonet
   2160 E. Grand Ave.
   El Segundo, CA 90025
   USA
   Email: raymond_zhang@infonet.com

11. 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.

   Disclaimer of Validity

   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.

   Copyright Statement

   Copyright (C) The Internet Society (2005). (2006).  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.