doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4674.txt b/doc/rfc/rfc4674.txt
new file mode 100644
index 0000000..b4c8ef6
--- /dev/null
+++ b/doc/rfc/rfc4674.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                  J.L. Le Roux, Ed.
+Request for Comments: 4674                                France Telecom
+Category: Informational                                     October 2006
+
+
+       Requirements for Path Computation Element (PCE) Discovery
+
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+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 protocols or
+   extensions to existing protocols for such PCE discovery satisfy these
+   requirements.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+      1.2. Terminology ................................................3
+   2. Problem Statement and Requirements Overview .....................4
+      2.1. Problem Statement ..........................................4
+      2.2. Requirements Overview ......................................5
+   3. Example of Application Scenario .................................6
+   4. Detailed Requirements ...........................................7
+      4.1. PCE Information to Be Disclosed ............................7
+           4.1.1. General PCE Information (Mandatory Support) .........8
+                  4.1.1.1. Discovery of PCE Location ..................8
+                  4.1.1.2. Discovery of PCE Domains and
+                           Inter-domain Functions .....................8
+           4.1.2. Detailed PCE Information (Optional Support) .........9
+                  4.1.2.1. Discovery of PCE Capabilities ..............9
+                  4.1.2.2. Discovery of Alternate PCEs ...............10
+      4.2. Scope of PCE Discovery ....................................10
+           4.2.1. Inter-AS Specific Requirements .....................10
+
+
+
+Le Roux                      Informational                      [Page 1]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+      4.3. PCE Information Synchronization ...........................11
+      4.4. Discovery of PCE Deactivation .............................11
+      4.5. Policy Support ............................................12
+      4.6. Security Requirements .....................................12
+      4.7. Extensibility .............................................13
+      4.8. Scalability ...............................................13
+      4.9. Operational Orders of Magnitudes ..........................13
+      4.10. Manageability Considerations .............................14
+           4.10.1. Configuration of PCE Discovery Parameters .........14
+           4.10.2. PCE Discovery MIB Modules .........................14
+                  4.10.2.1. PCC MIB Module ...........................14
+                  4.10.2.2. PCE MIB module ...........................15
+           4.10.3. Monitoring Protocol Operations ....................15
+           4.10.4. Impact on Network Operations ......................16
+   5. Security Considerations ........................................16
+   6. Acknowledgements ...............................................16
+   7. Contributors ...................................................17
+   8. References .....................................................17
+      8.1. Normative References ......................................17
+      8.2. Informative References ....................................17
+
+1.  Introduction
+
+   The PCE-based network architecture [RFC4655] defines a Path
+   Computation Element (PCE) as an entity capable of computing 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 [RFC4657].
+
+   The PCE based architecture requires 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.
+
+
+
+
+
+
+
+
+
+
+
+Le Roux                      Informational                      [Page 2]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   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, to determine additional
+   information required for PCE selection, and to dynamically detect new
+   PCEs or any modification of 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, for example.
+
+   This document lists a set of functional requirements for such an
+   automatic and dynamic PCE discovery mechanism.  Section 2 points out
+   the problem statement.  Section 3 illustrates an application
+   scenario.  Finally, Section 4 addresses detailed requirements.
+
+   It is intended that solutions that specify procedures and protocols
+   or protocol extensions for PCE discovery satisfy these requirements.
+   There is no intent either to specify solution-specific requirements
+   or to make any assumption on the 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.
+
+1.1.  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.
+
+1.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.
+
+
+
+
+Le Roux                      Informational                      [Page 3]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   PCC: Path Computation Client.  Any client application requesting a
+   path computation to be performed by a Path Computation Element.
+
+   Interior Gateway Protocol (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 ASs or 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.
+
+2.  Problem Statement and Requirements Overview
+
+2.1.  Problem Statement
+
+   A routing domain may, in practice, contain multiple PCEs:
+
+   - The path computation load may be balanced among a set of PCEs to
+     improve scalability.
+   - For the purpose of redundancy, primary and backup PCEs may be used.
+   - PCEs may have distinct path computation capabilities (multi-
+     constrained path computation, backup path computation, etc.).
+   - In an inter-domain context, there can be several PCEs with distinct
+     inter-domain functions (inter-area, inter-AS, inter-layer), each
+     PCE being responsible for path computation in one or more domains.
+
+   In order to allow for effective PCE selection by PCCs, that is, to
+   select the appropriate PCE based on its capabilities and perform
+   efficient load balancing of requests, a PCC 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.
+
+
+
+
+
+Le Roux                      Informational                      [Page 4]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   Such PCE information could be learned 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 may imply a substantial configuration 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, 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.
+
+2.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.
+
+   Where inter-domain path computation is required and policy permits,
+   the PCE discovery 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
+   or more domains where a PCE has TE topology visibility and can
+   compute paths.  It MUST also allow the discovery of the potential
+   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.
+
+
+
+
+
+
+Le Roux                      Informational                      [Page 5]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   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 a PCE's information.
+
+   A PCE discovery mechanism MUST allow PCCs to dynamically discover
+   that a PCE is no longer available.
+
+   A PCE discovery mechanism MUST 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 so that the PCC may make advanced
+   and informed choices about which PCE to use.
+
+3.  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 illustrates a multi-area/AS network with several PCEs:
+
+   - 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 ABR R6 is a PCE that can take part in inter-area path
+     computation.  It can compute paths in area 0 and area 2.
+   - The ASBR R9 is a PCE that can take part in inter-AS path
+     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
+     computation.  It is responsible for path computation in AS2 towards
+     AS1.
+   - The server S1 is a PCE that can be used to compute diverse paths
+     and backup paths in area 1.
+
+
+
+
+
+
+Le Roux                      Informational                      [Page 6]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   By meeting the requirements set out in this document, the PCE
+   discovery mechanism will allow:
+
+   - each PCC in areas 1 and 0 to dynamically discover R3, as a PCE for
+     inter-area path computation, and that R3 can compute paths in area
+     0 and area 1.
+   - each PCC in areas 0 and 2 to dynamically discover R6, as a PCE for
+     inter-area path computation, and that R6 can compute paths in area
+     2 and area 0.
+   - each PCC in AS1 and one or more PCCs in AS2 to dynamically discover
+     R9 as a PCE for inter-AS path computation in AS1 towards AS2.
+   - each PCC in AS2 and one or more PCCs in AS1 to dynamically discover
+     R12 as a PCE for inter-AS path computation in AS2 towards AS1.
+   - 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).
+
+4.  Detailed Requirements
+
+4.1.  PCE Information to Be Disclosed
+
+   We distinguish two levels of PCE information to be disclosed by a PCE
+   discovery mechanism:
+
+   - General information.  Disclosure MUST be supported by the PCE
+     discovery mechanism.
+   - Detailed information.  Disclosure MAY be supported by the PCE
+     discovery mechanism.
+
+   The PCE discovery mechanism MUST allow disclosure of general PCE
+   information that will allow PCCs to select appropriate PCEs.  This
+   comprises discovery of PCE location, PCE domains supported by the
+   PCEs, and PCE inter-domain functions.
+
+   The PCE discovery mechanism MAY also allow disclosure of detailed PCE
+   information.  This comprises any or all information about PCE path
+   computation capabilities and alternate PCEs.  This information is not
+   part of PCE discovery; this is additional information that can
+   facilitate the selection of a 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-based architecture, but such
+   information could also be obtained by other mechanisms, such as the
+   PCC-PCE communication protocol.
+
+
+
+
+
+
+Le Roux                      Informational                      [Page 7]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+4.1.1.  General PCE Information (Mandatory Support)
+
+4.1.1.1.  Discovery of PCE Location
+
+   The PCE discovery mechanism MUST allow 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 an 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, through
+   a PCC-PCE communication protocol.
+
+4.1.1.2.  Discovery of PCE Domains and Inter-domain Functions
+
+   Inter-domain path computation is a key application of the PCE-based
+   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.  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 (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 the discovery of the
+   set of one or more domains where a PCE has visibility and can compute
+   paths.  These domains 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 discovery of the inter-
+   domain functions of a PCE, i.e., whether a PCE can be used to compute
+   or to take part in the computation of end-to-end paths across domain
+   borders.  The inter-domain functions include nonexhaustively: inter-
+   area, inter-AS and inter-layer path computation.  Note that these
+   functions are not mutually exclusive.
+
+   Note that the inter-domain functions are not necessarily inferred
+   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 in 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 the PCE
+   to 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
+
+
+
+Le Roux                      Informational                      [Page 8]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   several PCEs in an AS, each one responsible for taking part in the
+   computation of inter-AS paths toward a set of one or more destination
+   ASs, and a PCC may have to discover the destination ASs each PCE is
+   responsible for.
+
+4.1.2.  Detailed PCE Information (Optional Support)
+
+4.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 support the
+   disclosure of some detailed PCE capabilities.
+
+   For the sake of illustration, this could include the following path-
+   computation-related PCE capabilities:
+
+   - The link constraints supported: e.g., bandwidth, affinities.
+   - The path constraints supported: maximum IGP/TE cost, maximum hop
+     count.
+   - The objective functions supported: e.g., shortest path, widest
+     path.
+   - The capability to compute multiple correlated paths: e.g., diverse
+     paths, load balanced paths.
+   - The capability to compute bidirectional paths.
+   - The GMPLS-technology-specific constraints supported: e.g., the
+     supported interface switching capabilities, encoding types.
+
+   And this could also include some specific PCE capabilities:
+
+   - The capability to handle request prioritization.
+   - The maximum size of a request message.
+   - The maximum number of path requests in a request message.
+   - The PCE computation power (static parameters to be used for
+     weighted load balancing of requests).
+
+   Such information regarding PCE capabilities could then be used by a
+   PCC to select an appropriate PCE from a list of candidate PCEs.
+
+   Note that the exact definition and description of PCE capabilities
+   are out of the scope of this document.  It is expected that this will
+   be described in one or more separate documents which may be
+   application specific.
+
+
+
+
+
+
+
+Le Roux                      Informational                      [Page 9]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+4.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 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 or more PCEs for which it acts as alternate
+   PCE.
+
+4.2.  Scope of PCE Discovery
+
+   The PCE discovery mechanism MUST allow control of the scope of the
+   PCE information disclosure on a per-PCE basis.  In other words, it
+   MUST allow 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 settings:
+
+   - 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 set of ASs.
+
+   - A set of one or more PCCs in a set of one or more 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.
+
+   The discovery scope MUST be configurable on a per PCE basis.
+
+   It MUST be possible to deactivate PCE discovery on a per PCE basis.
+
+4.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
+
+
+
+Le Roux                      Informational                     [Page 10]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   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 4.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.
+
+4.3.  PCE Information Synchronization
+
+   The PCE discovery mechanism MUST allow a PCC to discover any change
+   in the information related to a PCE that it has previously
+   discovered.  This includes changes to both general information (e.g.,
+   a change in the PCE domains supported) and detailed information if
+   supported (e.g., a modification of the PCE's capabilities).
+
+   In addition, the PCE discovery mechanism MUST allow dynamic discovery
+   of new 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 discovery of
+   these changes in a range of 60 seconds, and the operator should have
+   the ability to configure the discovery delay.
+
+   Note that PCE information is relatively static and is expected to be
+   fairly stable and not to change frequently.
+
+4.4.  Discovery of PCE Deactivation
+
+   The PCE discovery mechanism MUST allow a PCC to discover when a PCE
+   that it has previously discovered is no longer alive or is
+   deactivated.  This may help in reducing or avoiding path computation
+   service disruption.
+
+   Note that there is no requirement for real-time detection of PCE
+   failure/deactivation; the PCE discovery mechanism SHOULD rather allow
+   such discovery in a range of 60 seconds, and the operator should have
+   the ability to configure the discovery delay.
+
+
+
+
+Le Roux                      Informational                     [Page 11]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+4.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 possible to apply these policies on a per-PCE basis.
+
+   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.
+
+4.6.  Security Requirements
+
+   The five major threats related to PCE discovery mechanisms are
+
+   - impersonation of PCE;
+   - interception of PCE discovery information (sniffing);
+   - falsification of PCE discovery information;
+   - information disclosure to non-authorized PCCs (PCC spoofing);
+   - Denial of Service (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,
+   confidentiality, 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 Section 4.5).
+
+   A PCE and PCC MUST be identified by a globally unique ID, which may
+   be, for instance, a combination of AS number and IP address.
+
+   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).  Note also that DoS attacks
+   may be either accidental (caused by a misbehaving PCE system) or
+   intentional.  As discussed in [RFC4657], such mechanisms may include
+
+
+
+Le Roux                      Informational                     [Page 12]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   packet filtering, rate limiting, no promiscuous listening, and where
+   applicable use of private addresses spaces.
+
+   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 or more trust models.
+
+4.7.  Extensibility
+
+   The PCE discovery mechanism MUST be flexible and extensible so as to
+   easily allow for the inclusion of additional PCE information that
+   could be defined in the future.
+
+4.8.  Scalability
+
+   The PCE discovery mechanism MUST be designed to scale well with an
+   increase of any of the following parameters:
+
+   - Number of PCCs discovering a given PCE.
+   - Number of PCEs to be discovered by a given PCC.
+   - Number of domains in the discovery scope.
+
+   The PCE discovery mechanism MUST NOT have an adverse effect in the
+   performance of other protocols (especially routing and signaling)
+   already operating in the network.
+
+   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
+   static.  Changes in PCE information may occur as a 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.
+
+4.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
+
+
+
+
+
+
+
+
+Le Roux                      Informational                     [Page 13]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+4.10.  Manageability Considerations
+
+   Mechanisms are REQUIRED to manage PCE discovery operations.  This
+   includes the configuration of PCE discovery functions and policies,
+   as well as the monitoring of the discovery protocol activity.
+
+4.10.1.  Configuration of PCE Discovery Parameters
+
+   It MUST be possible to enable and disable the PCE discovery function
+   at a PCC and at a PCE.
+
+   On the PCC, it MUST be possible for an operator to
+   activate/deactivate automatic PCE discovery.  The activation of
+   automatic discovery MUST not prevent static configuration of PCE
+   information that may supplement discovered information.
+
+   On the PCE, it MUST be possible for an operator to control the
+   application of discovery policies by which the specific PCE is
+   discovered.  As described in Section 4.5, this control MUST include
+   the ability to
+
+   - restrict the discovery scope to a set of authorized domains;
+   - define the type and nature of the information disclosed;
+   - specify the filtering and translation to be applied to the PCE
+     information disclosed at domain borders.
+
+   These configuration options MAY be supported through an
+   implementation-specific local configuration interface, or MAY be
+   supported via a standardised interface (such as a MIB module, as
+   below).
+
+4.10.2.  PCE Discovery MIB Modules
+
+   PCE discovery MIB modules MUST be specified for the control of the
+   function on PCCs and PCEs.
+
+4.10.2.1.  PCC MIB Module
+
+   The MIB module that will run on PCCs MUST include at least the
+   following:
+
+   - A control to disable automatic discovery by the PCC,
+   - The set of known PCEs,
+   - The number of known PCEs, and the number of discovered PCEs.
+
+   For each PCE reported in the MIB module, the following information
+   MUST be available:
+
+
+
+
+Le Roux                      Informational                     [Page 14]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   - Information advertised by the PCE (i.e., discovered information),
+   - Information locally configured about the PCE,
+   - The time since the PCE was discovered,
+   - The time since any change to the discovered information for the
+     PCE.
+
+   Note that when a PCE is no longer alive (see Section 4.4), it SHOULD
+   no longer be reported in the PCC MIB module.
+
+   The MIB module SHOULD also provide the average and maximum rates of
+   arrival, departure, and modification of PCE discovery to enable
+   effective analysis of the operation of the protocols.  Furthermore,
+   the MIB module SHOULD report on the operation of the discovery
+   protocol by counting the number of unacceptable and incomprehensible
+   information exchanges.
+
+   The PCC MIB module SHOULD also be used to provide notifications when
+   thresholds (e.g., on the maximum rate of change, on the number of
+   unacceptable messages) are crossed, or when important events occur
+   (e.g., the number of discovered PCEs decreases to zero).
+
+4.10.2.2.  PCE MIB module
+
+   The MIB module that will run on PCEs MUST include at least
+
+   - a control to disable automatic discovery announcements by the PCE;
+   - information to be advertised by the PCE, although this information
+     MAY be present as read-only;
+   - the discovery policies active on the PCE, although this information
+     MAY be present as read-only.
+
+   The MIB module SHOULD also include
+
+   - the time since the last change to the advertised PCE information;
+   - the time since the last change to the advertisement policies;
+   - control of on which interfaces the PCE issues advertisements where
+     this is applicable to the protocol solution selected.
+
+   Note that a PCE MAY also be configured to discover other PCEs.  In
+   this case, it SHOULD operate the MIB module described in Section
+   4.10.2.1 as well as the module described here.
+
+4.10.3.  Monitoring Protocol Operations
+
+   It MUST be possible to monitor the operation of any PCE discovery
+   protocol.  Where an existing protocol is used to support the PCE
+   discovery function, this monitoring SHOULD be achieved using the
+   techniques already defined for that protocol, enhanced by the MIB
+
+
+
+Le Roux                      Informational                     [Page 15]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+   modules described above.  Where those techniques are inadequate, new
+   techniques MUST be developed.
+
+   Monitoring of the protocol operation demands support for at least the
+   following functions:
+
+   - Correlation of information advertised against information received.
+   - Counts of dropped, corrupt, and rejected information elements.
+   - Detection of 'segmented' networks, that is, the ability to detect
+     and diagnose the failure of a PCE advertisement to reach a PCC.
+
+4.10.4.  Impact on Network Operations
+
+   Frequent changes in PCE information may have a significant impact on
+   PCCs that receive the advertisements, might destabilize the operation
+   of the network by causing the PCCs to swap between PCEs, and might
+   harm the network through excessive advertisement traffic.  Hence, it
+   MUST be possible to apply at least the following controls:
+
+   - Configurable limit on the rate of announcement of changed
+     parameters at a PCE.
+   - Control of the impact on PCCs such as through discovery messages
+     rate-limiting.
+   - Configurable control of triggers that cause a PCC to swap to
+     another PCE.
+
+5.  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
+   has been identified in Section 4.6.
+
+6.  Acknowledgements
+
+   We would like to thank, in chronological order, 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, Andrew Dolganow, Lou
+   Berger, Nabil Bitar, and Kenji Kumaki.
+
+   Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley
+   and Sam Hartman for their review and constructive discussions during
+   the final stages of publication.
+
+
+
+
+
+Le Roux                      Informational                     [Page 16]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+7.  Contributors
+
+   The following are the authors who 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)
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+              Computation Element (PCE)-Based Architecture", RFC 4655,
+              August 2006.
+
+8.2.  Informative References
+
+   [RFC4657]  Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol Generic
+              Requirements", RFC 4657, September 2006.
+
+Contributors' Addresses
+
+   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
+
+
+
+
+Le Roux                      Informational                     [Page 17]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+
+   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
+
+Editor's Address
+
+   Jean-Louis Le Roux (Editor)
+   France Telecom
+   2, avenue Pierre-Marzin
+   22307 Lannion Cedex
+   FRANCE
+
+   EMail: jeanlouis.leroux@orange-ft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux                      Informational                     [Page 18]
+
+RFC 4674             Requirements for PCE Discovery         October 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (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.
+
+   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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Le Roux                      Informational                     [Page 19]
+