doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc4657.txt b/doc/rfc/rfc4657.txt
new file mode 100644
index 0000000..08c4499
--- /dev/null
+++ b/doc/rfc/rfc4657.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                        J. Ash, Ed.
+Request for Comments: 4657                                          AT&T
+Category: Informational                                J.L. Le Roux, Ed.
+                                                          France Telecom
+                                                          September 2006
+
+
+         Path Computation Element (PCE) Communication Protocol
+                          Generic Requirements
+
+
+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
+
+   The PCE model is described in the "PCE Architecture" document and
+   facilitates path computation requests from Path Computation Clients
+   (PCCs) to Path Computation Elements (PCEs).  This document specifies
+   generic requirements for a communication protocol between PCCs and
+   PCEs, and also between PCEs where cooperation between PCEs is
+   desirable.  Subsequent documents will specify application-specific
+   requirements for the PCE communication protocol.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. Terminology .....................................................3
+   4. Overview of PCE Communication Protocol (PCECP) ..................4
+   5. PCE Communication Protocol Generic Requirements .................5
+      5.1. Basic Protocol Requirements ................................5
+           5.1.1. Commonality of PCC-PCE and PCE-PCE Communication ....5
+           5.1.2. Client-Server Communication .........................5
+           5.1.3. Transport ...........................................5
+           5.1.4. Path Computation Requests ...........................5
+           5.1.5. Path Computation Responses ..........................7
+           5.1.6. Cancellation of Pending Requests ....................7
+           5.1.7. Multiple Requests and Responses .....................8
+           5.1.8. Reliable Message Exchange ...........................8
+           5.1.9. Secure Message Exchange .............................9
+
+
+
+Ash & Le Roux                Informational                      [Page 1]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+           5.1.10. Request Prioritization ............................10
+           5.1.11. Unsolicited Notifications .........................10
+           5.1.12. Asynchronous Communication ........................10
+           5.1.13. Communication Overhead Minimization ...............10
+           5.1.14. Extensibility .....................................11
+           5.1.15. Scalability .......................................11
+           5.1.16. Constraints .......................................12
+           5.1.17. Objective Functions Supported .....................13
+      5.2. Deployment Support Requirements ...........................13
+           5.2.1. Support for Different Service Provider
+                  Environments .......................................13
+           5.2.2. Policy Support .....................................14
+      5.3. Aliveness Detection & Recovery Requirements ...............14
+           5.3.1. Aliveness Detection ................................14
+           5.3.2. Protocol Recovery ..................................14
+           5.3.3. LSP Rerouting & Reoptimization .....................14
+   6. Security Considerations ........................................15
+   7. Manageability Considerations ...................................16
+   8. Contributors ...................................................17
+   9. Acknowledgements ...............................................18
+   10. References ....................................................19
+      10.1. Normative References .....................................19
+      10.2. Informative References ...................................19
+
+1.  Introduction
+
+   A Path Computation Element (PCE) [RFC4655] supports requests for path
+   computation issued by a Path Computation Client (PCC), which may be
+   'composite' (co-located) or 'external' (remote) from a PCE.  When the
+   PCC is external from the PCE, a request/response communication
+   protocol is required to carry the path computation request and return
+   the response.  In order for the PCC and PCE to communicate, the PCC
+   must know the location of the PCE; PCE discovery is described in
+   [PCE-DISC-REQ].
+
+   The PCE operates on a network graph in order to compute paths based
+   on the path computation request(s) issued by the PCC(s).  The path
+   computation request will include the source and destination of the
+   paths to be computed and a set of constraints to be applied during
+   the computation, and it may also include an objective function.  The
+   PCE response includes the computed paths or the reason for a failed
+   computation.
+
+
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                      [Page 2]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   This document lists a set of generic requirements for the PCE
+   Communication Protocol (PCECP).  Application-specific requirements
+   are beyond the scope of this document, and will be addressed in
+   separate documents.  For example, application-specific communication
+   protocol requirements are given in [PCECP-INTER-AREA] and
+   [PCECP-INTER-LAYER] for inter-area and inter-layer PCE applications,
+   respectively.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY NOT", and
+   "OPTIONAL" in this document are to be interpreted as described in RFC
+   2119 [RFC2119].
+
+3.  Terminology
+
+   Domain: Any collection of network elements within a common sphere of
+   address management or path computational responsibility.  Examples of
+   domains include Interior Gateway Protocol (IGP) areas, Autonomous
+   Systems (ASs), multiple ASs within a service provider network, or
+   multiple ASs across multiple service provider networks.
+
+   GMPLS: Generalized Multi-Protocol Label Switching
+
+   LSP: MPLS/GMPLS Label Switched Path
+
+   LSR: Label Switch Router
+
+   MPLS: Multi-Protocol Label Switching
+
+   PCC: Path Computation Client: Any client application requesting a
+   path computation to be performed by the PCE.
+
+   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 (see
+   further description in [RFC4655]).
+
+   TED: Traffic Engineering Database, which contains the topology and
+   resource information of the network or network segment used by a PCE.
+
+   TE LSP: Traffic Engineering (G)MPLS Label Switched Path.
+
+   See [RFC4655] for further definitions of terms.
+
+
+
+
+
+
+Ash & Le Roux                Informational                      [Page 3]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+4.  Overview of PCE Communication Protocol (PCECP)
+
+   In the PCE model, path computation requests are issued by a PCC to a
+   PCE that may be composite (co-located) or external (remote).  If the
+   PCC and PCE are not co-located, a request/response communication
+   protocol is required to carry the request and return the response.
+   If the PCC and PCE are co-located, a communication protocol is not
+   required, but implementations may choose to utilize a protocol for
+   exchanges between the components.
+
+   In order for a PCC and PCE to communicate, the PCC must know the
+   location of the PCE.  This can be configured or discovered.  The PCE
+   discovery mechanism is out of scope of this document, but
+   requirements are documented in [PCE-DISC-REQ].
+
+   The PCE operates on a network graph built from the TED in order to
+   compute paths.  The mechanism by which the TED is populated is out of
+   scope for the PCECP.
+
+   A path computation request issued by the PCC includes a specification
+   of the path(s) needed.  The information supplied includes, at a
+   minimum, the source and destination for the paths, but may also
+   include a set of further requirements (known as constraints) as
+   described in Section 5.
+
+   The response from the PCE may be positive in which case it will
+   include the paths that have been computed.  If the computation fails
+   or cannot be performed, a negative response is required with an
+   indication of the type of failure.
+
+   A request/response protocol is also required for a PCE to communicate
+   path computation requests to another PCE and for that PCE to return
+   the path computation response.  As described in [RFC4655], there is
+   no reason to assume that two different protocols are needed, and this
+   document assumes that a single protocol will satisfy all requirements
+   for PCC-PCE and PCE-PCE communication.
+
+   [RFC4655] describes four models of PCE: composite, external, multiple
+   PCE path computation, and multiple PCE path computation with inter-
+   PCE communication.  In all cases except the composite PCE model, a
+   PCECP is required.  The requirements defined in this document are
+   applicable to all models described in [RFC4655].
+
+
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                      [Page 4]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+5.  PCE Communication Protocol Generic Requirements
+
+5.1.  Basic Protocol Requirements
+
+5.1.1.  Commonality of PCC-PCE and PCE-PCE Communication
+
+   A single protocol MUST be defined for PCC-PCE and PCE-PCE
+   communication.  A PCE requesting a path from another PCE can be
+   considered a PCC, and in the remainder of this document we refer to
+   all communications as PCC-PCE regardless of whether they are PCC-PCE
+   or PCE-PCE.
+
+5.1.2.  Client-Server Communication
+
+   PCC-PCE communication is by nature client-server based.  The PCECP
+   MUST allow a PCC to send a request message to a PCE to request path
+   computation, and for a PCE to reply with a response message to the
+   requesting PCC once the path has been computed.
+
+   In addition to this request-response mode, there are cases where
+   there is unsolicited communication from the PCE to the PCC (see
+   Section 5.1.11).
+
+5.1.3.  Transport
+
+   The PCECP SHOULD utilize an existing transport protocol that supports
+   congestion control.  This transport protocol may also be used to
+   satisfy some requirements in other sections of this document, such as
+   reliability.  The PCECP SHOULD be defined for one transport protocol
+   only in order to ensure interoperability.  The transport protocol
+   MUST NOT limit the size of the message used by the PCECP.
+
+5.1.4.  Path Computation Requests
+
+   The path computation request message MUST include at least the source
+   and destination.  Note that the path computation request is for an
+   LSP or LSP segment, and the source and destination supplied are the
+   start and end of the computation being requested (i.e., of the LSP
+   segment).
+
+
+
+
+
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                      [Page 5]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   The path computation request message MUST support the inclusion of a
+   set of one or more path constraints, including but not limited to the
+   requested bandwidth or resources (hops, affinities, etc.) to
+   include/exclude.  For example, a PCC may request the PCE to exclude
+   points of failure in the computation of a new path if an LSP setup
+   fails.  The actual inclusion of constraints is a choice for the PCC
+   issuing the request.  A list of core constraints that must be
+   supported by the PCECP is supplied in Section 5.1.16.  Specification
+   of constraints MUST be future-proofed as described in Section 5.1.14.
+
+   The requester MUST be allowed to select from or prefer an advertised
+   list or minimal subset of standard objective functions and functional
+   options.  An objective function is used by the PCE to process
+   constraints to a path computation request when it computes a path in
+   order to select the "best" candidate paths (e.g., minimum hop path),
+   and corresponds to the optimization criteria used for the computation
+   of one path, or the synchronized computation of a set of paths.  In
+   the case of unsynchronized path computation, this can be, for
+   example, the path cost or the residual bandwidth on the most loaded
+   path link.  In the case of synchronized path computation, this can
+   be, for example, the global bandwidth consumption or the residual
+   bandwidth on the most loaded network link.
+
+   A list of core objective functions that MUST be supported by the
+   PCECP is supplied in Section 5.1.17.  Specification of objective
+   functions MUST be future-proofed as described in Section 5.1.14.
+
+   The requester SHOULD also be able to select a vendor-specific or
+   experimental objective function or functional option.  Furthermore,
+   the requester MUST be allowed to customize the function/options in
+   use.  That is, individual objective functions will often have
+   parameters to be set in the request from PCC to PCE.  Support for the
+   specification of objective functions and objective parameters is
+   required in the protocol extensibility specified in Section 5.1.14.
+
+   A request message MAY include TE parameters carried by the MPLS/GMPLS
+   LSP setup signaling protocol.  Also, it MUST be possible for the PCE
+   to apply additional objective functions.  This might include policy-
+   based routing path computation for load balancing instructed by the
+   management plane.
+
+   Shortest path selection may rely either on the TE metric or on the
+   IGP metric [METRIC].  Hence the PCECP request message MUST allow the
+   PCC to indicate the metric type (IGP or TE) to be used for shortest
+   path selection.  Note that other metric types may be specified in the
+   future.
+
+
+
+
+
+Ash & Le Roux                Informational                      [Page 6]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   There may be cases where a single path cannot fit a given bandwidth
+   request, while a set of paths could be combined to fit the request.
+   Such path combination to serve a given request is called load-
+   balancing.  The request message MUST allow the PCC to indicate if
+   load-balancing is allowed.  It MUST also include the maximum number
+   of paths in a load-balancing path group, and the minimum path
+   bandwidth in a load-balancing path group.  The request message MUST
+   allow specification of the degree of disjointness of the members of
+   the load-balancing group.
+
+5.1.5.  Path Computation Responses
+
+   The path computation response message MUST allow the PCE to return
+   various elements including, at least, the computed path(s).
+
+   The protocol MUST be capable of returning any explicit path that
+   would be acceptable for use for MPLS and GMPLS LSPs once converted to
+   an Explicit Route Object for use in RSVP-TE signaling.  In addition,
+   anything that can be expressed in an Explicit Route Object MUST be
+   capable of being returned in the computed path.  Note that the
+   resultant path(s) may be made up of a set of strict or loose hops, or
+   any combination of strict and loose hops.  Moreover, a hop may have
+   the form of a non-simple abstract node.  See [RFC3209] for the
+   definition of strict hop, loose hop, and abstract node.
+
+   A positive response from the PCE MUST include the paths that have
+   been computed.  A positive PCECP computation response MUST support
+   the inclusion of a set of attributes of the computed path, such as
+   the path costs (e.g., cumulative link TE metrics and cumulative link
+   IGP metrics) and the computed bandwidth.  The latter is useful when a
+   single path cannot serve the requested bandwidth and load balancing
+   is applied.
+
+   When a path satisfying the constraints cannot be found, or if the
+   computation fails or cannot be performed, a negative response MUST be
+   sent.  This response MAY include further details of the reason(s) for
+   the failure and MAY include advice about which constraints might be
+   relaxed to be more likely to achieve a positive result.
+
+   The PCECP response message MUST support the inclusion of the set of
+   computed paths of a load-balancing path group, as well as their
+   respective bandwidths.
+
+5.1.6.  Cancellation of Pending Requests
+
+   A PCC MUST be able to cancel a pending request using an appropriate
+   message.  A PCC that has sent a request to a PCE and no longer needs
+   a response, for instance, because it no longer wants to set up the
+
+
+
+Ash & Le Roux                Informational                      [Page 7]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   associated service, MUST be able to notify the PCE that it can clear
+   the request (i.e., stop the computation if already started, and clear
+   the context).  The PCE may also wish to cancel a pending request
+   because of some congested state.
+
+5.1.7.  Multiple Requests and Responses
+
+   It MUST be possible to send multiple path computation requests within
+   the same request message.  Such requests may be correlated (e.g.,
+   requesting disjoint paths) or uncorrelated (requesting paths for
+   unrelated services).  It MUST be possible to limit by configuration
+   of both PCCs and PCEs the number of requests that can be carried
+   within a single message.
+
+   Similarly, it MUST be possible to return multiple computed paths
+   within the same response message, corresponding either to the same
+   request (e.g., multiple suited paths, paths of a load-balancing path
+   group) or to distinct requests, correlated or not, of the same
+   request message or distinct request messages.
+
+   It MUST be possible to provide "continuation correlation" where all
+   related requests or computed paths cannot fit within one message and
+   are carried in a sequence of correlated messages.
+
+   The PCE MUST inform the PCC of its capabilities.  Maximum acceptable
+   message sizes and the maximum number of requests per message
+   supported by a PCE MAY form part of PCE capabilities advertisement
+   [PCE-DISC-REQ] or MAY be exchanged through information messages from
+   the PCE as part of the protocol described here.
+
+   It MUST be possible for a PCC to specify, in the request message, the
+   maximum acceptable response message sizes and the maximum number of
+   computed paths per response message it can support.
+
+   It MUST be possible to limit the message size by configuration on
+   PCCs and PCEs.
+
+5.1.8.  Reliable Message Exchange
+
+   The PCECP MUST support reliable transmission of PCECP packets.  This
+   may form part of the protocol itself or may be achieved by the
+   selection of a suitable transport protocol (see Section 5.1.3).
+
+   In particular, it MUST allow for the detection and recovery of lost
+   messages to occur quickly and not impede the operation of the PCECP.
+
+   In some cases (e.g., after link failure), a large number of PCCs may
+   simultaneously send requests to a PCE, leading to a potential
+
+
+
+Ash & Le Roux                Informational                      [Page 8]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   saturation of the PCEs.  The PCECP MUST support indication of
+   congestion state and rate limitation state.  This should enable, for
+   example, a PCE to limit the rate of incoming request messages if the
+   request rate is too high.
+
+   The PCECP or its transport protocol MUST provide the following:
+
+   - Detection and report of lost or corrupted messages
+   - Automatic attempts to retransmit lost messages without reference to
+     the application
+   - Handling of out-of-order messages
+   - Handling of duplicate messages
+   - Flow control and back-pressure to enable throttling of requests and
+     responses
+   - Rapid PCECP communication failure detection
+   - Distinction between partner failure and communication channel
+     failure after the PCECP communication is recovered
+
+   If it is necessary to add functions to PCECP to overcome shortcomings
+   in the chosen transport mechanisms, these functions SHOULD be based
+   on and re-use where possible techniques developed in other protocols
+   to overcome the same shortcomings.  Functionality MUST NOT be added
+   to the PCECP where the chosen transport protocol already provides it.
+
+5.1.9.  Secure Message Exchange
+
+   The PCC-PCE communication protocol MUST include provisions to ensure
+   the security of the exchanges between the entities.  In particular,
+   it MUST support mechanisms to prevent spoofing (e.g.,
+   authentication), snooping (e.g., preservation of confidentiality of
+   information through techniques such as encryption), and Denial of
+   Service (DoS) attacks (e.g., packet filtering, rate limiting, no
+   promiscuous listening).  Once a PCC is identified and authenticated,
+   it has the same privileges as all other PCCs.
+
+   To ensure confidentiality, the PCECP SHOULD allow local policy to be
+   configured on the PCE to not provide explicit path(s).  If a PCC
+   requests an explicit path when this is not allowed, the PCE MUST
+   return an error message to the requesting PCC and the pending path
+   computation request MUST be discarded.
+
+   Authorization requirements [RFC3127] include reject capability,
+   reauthorization on demand, support for access rules and filters, and
+   unsolicited disconnect.
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                      [Page 9]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   IP addresses are used to identify PCCs and PCEs.  Where the PCC-PCE
+   communication takes place entirely within one limited domain, the use
+   of a private address space that is not available to customer systems
+   MAY be used to help protect the information exchange, but other
+   mechanisms MUST also be available.
+
+   These functions may be provided by the transport protocol or directly
+   by the PCECP.  See Section 6 for further discussion of security
+   considerations.
+
+5.1.10.  Request Prioritization
+
+   The PCECP MUST allow a PCC to specify the priority of a computation
+   request.
+
+   Implementation of priority-based activity within a PCE is subject to
+   implementation and local policy.  This application processing is out
+   of scope of the PCECP.
+
+5.1.11.  Unsolicited Notifications
+
+   The normal operational mode is for the PCC to make path computation
+   requests to the PCE and for the PCE to respond.
+
+   The PCECP MUST support unsolicited notifications from PCE to PCC, or
+   PCC to PCE.  This requirement facilitates the unsolicited
+   communication of information and alerts between PCCs and PCEs.  As
+   specified in Section 5.1.8, these notification messages must be
+   supported by a reliable transmission protocol.  The PCECP MAY also
+   support response messages to the unsolicited notification messages.
+
+5.1.12.  Asynchronous Communication
+
+   The PCC-PCE protocol MUST allow for asynchronous communication.  A
+   PCC MUST NOT have to wait for a response to one request before it can
+   make another request.
+
+   It MUST also be possible to have the order of responses differ from
+   the order of the corresponding requests.  This may occur, for
+   instance, when path request messages have different priorities (see
+   Requirement 5.1.10).  A consequent requirement is that path
+   computation responses MUST include a direct correlation to the
+   associated request.
+
+5.1.13.  Communication Overhead Minimization
+
+   The request and response messages SHOULD be designed so that the
+   communication overhead is minimized.  In particular, the overhead per
+
+
+
+Ash & Le Roux                Informational                     [Page 10]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   message SHOULD be minimized, and the number of bytes exchanged to
+   arrive at a computation answer SHOULD be minimized.  Other
+   considerations in overhead minimization include the following:
+
+   - the number of background messages used by the protocol or its
+     transport protocol to keep alive any session or association
+     between the PCE and PCC
+   - the processing cost at the PCE (or PCC) associated with
+     request/response messages (as distinct from processing the
+     computation requests themselves)
+
+5.1.14.  Extensibility
+
+   The PCECP MUST provide a way for the introduction of new path
+   computation constraints, diversity types, objective functions,
+   optimization methods and parameters, and so on, without requiring
+   major modifications in the protocol.
+
+   For example, the PCECP MUST be extensible to support various PCE-
+   based applications, such as the following:
+
+   - intra-area path computation
+   - inter-area path computation [PCECP-INTER-AREA]
+   - inter-AS intra provider and inter-AS inter-provider path
+     computation [PCECP-INTER-AS]
+   - inter-layer path computation [PCECP-INTER-LAYER]
+
+   The PCECP MUST support the requirements specified in the
+   application-specific requirements documents.  The PCECP MUST also
+   allow extensions as more PCE applications will be introduced in the
+   future.
+
+   The PCECP SHOULD also be extensible to support future applications
+   not currently in the scope of the PCE working group, such as, for
+   instance, point-to-multipoint path computations, multi-hop pseudowire
+   path computation, etc.
+
+   Note that application specific requirements are out of the scope of
+   this document and will be addressed in separate requirements
+   documents.
+
+5.1.15.  Scalability
+
+   The PCECP MUST scale well, at least as good as linearly, with an
+   increase of any of the following parameters.  Minimum order of
+   magnitude estimates of what the PCECP should support are given in
+   parenthesis (note: these are requirements on the PCECP, not on the
+   PCE):
+
+
+
+Ash & Le Roux                Informational                     [Page 11]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   - number of PCCs (1000/domain)
+   - number of PCEs (100/domain)
+   - number of PCCs communicating with a single PCE (1000)
+   - number of PCEs communicated to by a single PCC (100)
+   - number of domains (20)
+   - number of path request messages (average of 10/second/PCE)
+   - handling bursts of requests (burst of 100/second/PCE within a 10-
+     second interval).
+
+   Note that path requests can be bundled in path request messages, for
+   example, 10 PCECP request messages/second may correspond to 100 path
+   requests/second.
+
+   Bursts of requests may arise, for example, after a network outage
+   when multiple recomputations are requested.  The PCECP MUST handle
+   the congestion in a graceful way so that it does not unduly impact
+   the rest of the network, and so that it does not gate the ability of
+   the PCE to perform computation.
+
+5.1.16.  Constraints
+
+   This section provides a list of generic constraints that MUST be
+   supported by the PCECP.  Other constraints may be added to service
+   specific applications as identified by separate application-specific
+   requirements documents.  Note that the provisions of Section 5.1.14
+   mean that new constraints can be added to this list without impacting
+   the protocol to a level that requires major protocol changes.
+
+   The set of supported generic constraints MUST include at least the
+   following:
+
+   o MPLS-TE and GMPLS generic constraints:
+     - Bandwidth
+     - Affinities inclusion/exclusion
+     - Link, Node, Shared Risk Link Group (SRLG) inclusion/exclusion
+     - Maximum end-to-end IGP metric
+     - Maximum hop count
+     - Maximum end-to-end TE metric
+     - Degree of paths disjointness (Link, Node, SRLG)
+
+   o MPLS-TE specific constraints
+     - Class-type
+     - Local protection
+     - Node protection
+     - Bandwidth protection
+
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 12]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   o GMPLS specific constraints
+     - Switching type, encoding type
+     - Link protection type
+
+5.1.17.  Objective Functions Supported
+
+   This section provides a list of generic objective functions that MUST
+   be supported by the PCECP.  Other objective functions MAY be added to
+   service specific applications as identified by separate application-
+   specific requirements documents.  Note that the provisions of Section
+   5.1.14 mean that new objective functions MAY be added to this list
+   without impacting the protocol.
+
+   The PCECP MUST support at least the following "unsynchronized"
+   functions:
+
+   - Minimum cost path with respect to a specified metric
+     (shortest path)
+   - Least loaded path
+   - Maximum available bandwidth path
+
+   Also, the PCECP MUST support at least the following "synchronized"
+   objective functions:
+
+   - Minimize aggregate bandwidth consumption on all links
+   - Maximize the residual bandwidth on the most loaded link
+   - Minimize the cumulative cost of a set of diverse paths
+
+5.2.  Deployment Support Requirements
+
+5.2.1.  Support for Different Service Provider Environments
+
+   The PCECP must at least support the following environments:
+
+   - MPLS-TE and GMPLS networks
+   - Packet and non-packet networks
+   - Centralized and distributed PCE path computation
+   - Single and multiple PCE path computation
+
+   For example, PCECP is possibly applicable to packet networks (e.g.,
+   IP networks), non-packet networks (e.g., time-division multiplexed
+   (TDM) transport), and perhaps to multi-layer GMPLS control plane
+   environments.  Definitions of centralized, distributed, single, and
+   multiple PCE path computation can be found in [RFC4655].
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 13]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+5.2.2.  Policy Support
+
+   The PCECP MUST allow for the use of policies to accept/reject
+   requests.  It MUST include the ability for a PCE to supply sufficient
+   detail when it rejects a request for policy reasons to allow the PCC
+   to determine the reason for rejection or failure.  For example,
+   filtering could be required for a PCE that serves one domain (perhaps
+   an AS) such that all requests that come from another domain (AS) are
+   rejected.  However, specific policy details are left to application-
+   specific PCECP requirements.  Actual policies, configuration of
+   policies, and applicability of policies are out of scope.
+
+   Note that work on supported policy models and the corresponding
+   requirements/implications is being undertaken as a separate work item
+   in the PCE working group.
+
+   PCECP messages MUST be able to carry transparent policy information.
+
+5.3.  Aliveness Detection & Recovery Requirements
+
+5.3.1.  Aliveness Detection
+
+   The PCECP MUST allow a PCC/PCE to
+
+   - check the liveliness of the PCC-PCE communication,
+   - rapidly detect PCC-PCE communication failure (indifferently to
+     partner failure or connectivity failure), and
+   - distinguish PCC/PCE node failures from PCC-PCE connectivity
+     failures, after the PCC-PCE communication is recovered.
+
+   The aliveness detection mechanism MUST ensure reciprocal knowledge of
+   PCE and PCC liveness.
+
+5.3.2.  Protocol Recovery
+
+   In the event of the failure of a sender or of the communication
+   channel, the PCECP, upon recovery, MUST support resynchronization of
+   information (e.g., PCE congestion status) and requests between the
+   sender and the receiver; this SHOULD be arranged so as to minimize
+   repeat data transfer.
+
+5.3.3.  LSP Rerouting & Reoptimization
+
+   If an LSP fails owing to the failure of a link or node that it
+   traverses, a new computation request may be made to a PCE in order to
+   repair the LSP.  Since the PCC cannot know that the PCE's TED has
+   been updated to reflect the failure network information, it is useful
+   to include this information in the new path computation request.
+
+
+
+Ash & Le Roux                Informational                     [Page 14]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   Also, in order to re-use the resources used by the old LSP, it may be
+   advantageous to indicate the route of the old LSP as part of the new
+   path computation request.
+
+   Hence the path computation request message MUST allow an indication
+   of whether the computation is for LSP restoration, and it MUST
+   support the inclusion of the previously computed path as well as the
+   identity of the failed element.  Note that the old path might only be
+   useful if the old LSP has not yet been torn down.  The PCE MAY choose
+   to take failure indication information carried in a given request
+   into account when handling subsequent requests.  This should be
+   driven by local policy decision.
+
+   Note that a network failure may impact a large number of LSPs.  In
+   this case, a potentially large number of PCCs will simultaneously
+   send requests to the PCE.  The PCECP MUST properly handle such
+   overload situations, such as, for instance, through throttling of
+   requests as set forth in Section 5.1.8.
+
+   The path computation request message MUST support TE LSP path
+   reoptimization and the inclusion of a previously computed path.  This
+   will help ensure optimal routing of a reoptimized path, since it will
+   allow the PCE to avoid double bandwidth accounting and help reduce
+   blocking issues.
+
+6.  Security Considerations
+
+   Key management MUST be provided by the PCECP to provide for the
+   authenticity and integrity of PCECP messages.  This will allow
+   protecting against PCE or PCC impersonation and also against message
+   content falsification.
+
+   The impact of the use of a PCECP MUST be considered in light of the
+   impact that it has on the security of the existing routing and
+   signaling protocols and techniques in use within the network.
+   Intra-domain security is impacted since there is a new interface,
+   protocol, and element in the network.  Any host in the network could
+   impersonate a PCC and receive detailed information on network paths.
+   Any host could also impersonate a PCE, both gathering information
+   about the network before passing the request on to a real PCE and
+   spoofing responses.  Some protection here depends on the security of
+   the PCE discovery process (see [PCE-DISC-REQ]).  An increase in
+   inter-domain information flows may increase the vulnerability to
+   security attacks, and the facilitation of inter-domain paths may
+   increase the impact of these security attacks.
+
+   Of particular relevance are the implications for confidentiality
+   inherent in a PCECP for multi-domain networks.  It is not necessarily
+
+
+
+Ash & Le Roux                Informational                     [Page 15]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   the case that a multi-domain PCE solution will compromise security,
+   but solutions MUST examine their impacts in this area.
+
+   Applicability statements for particular combinations of signaling,
+   routing, and path computation techniques are expected to contain
+   detailed security sections.
+
+   It should be observed that the use of an external PCE introduces
+   additional security issues.  Most notable among these are the
+   following:
+
+   - Interception of PCE requests or responses
+   - Impersonation of PCE or PCC
+   - DoS attacks on PCEs or PCCs
+
+   The PCECP MUST address these issues in detail using authentication,
+   encryption, and DoS protection techniques.  See also Section 5.1.9.
+
+   There are security implications of allowing arbitrary objective
+   functions, as discussed in Section 5.1.17, and the PCECP MUST allow
+   mitigating the risk of, for example, a PCC using complex objectives
+   to intentionally drive a PCE into resource exhaustion.
+
+7.  Manageability Considerations
+
+   Manageability of the PCECP MUST address the following considerations:
+
+   - The need for a MIB module for control and monitoring of PCECP
+   - The need for built-in diagnostic tools to test the operation of the
+     protocol (e.g., partner failure detection, Operations
+     Administration and Maintenance (OAM), etc.)
+   - Configuration implications for the protocol
+
+   PCECP operations MUST be modeled and controlled through appropriate
+   MIB modules.  There are enough specific differences between PCCs and
+   PCEs to lead to the need of defining separate MIB modules.
+   Statistics gathering will form an important part of the operation of
+   the PCECP.  The MIB modules MUST provide information that will allow
+   an operator to determine PCECP historical interactions and the
+   success rate of requests.  Similarly, it is important for an operator
+   to be able to determine PCECP and PCE load and whether an individual
+   PCC is responsible for a disproportionate amount of the load.  It
+   MUST be possible, through use of MIB modules, to record and inspect
+   statistics about the PCECP communications, including issues such as
+   malformed messages, unauthorized messages, and messages discarded
+   owing to congestion.
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 16]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   The new MIB modules should also be used to provide notifications
+   (traps) when thresholds are crossed or when important events occur.
+   For example, the MIB module may support indication of exceeding the
+   congestion state threshold or rate limitation state.
+
+   PCECP techniques must enable a PCC to determine the liveness of a PCE
+   both before it sends a request and in the period between sending a
+   request and receiving a response.
+
+   It is also important for a PCE to know about the liveness of PCCs to
+   gain a predictive view of the likely loading of a PCE in the future
+   and to allow a PCE to abandon processing of a received request.
+
+   The PCECP MUST support indication of congestion state and rate
+   limitation state, and MAY allow the operator to control such a
+   function.
+
+8.  Contributors
+
+   This document is the result of the PCE Working Group PCECP
+   requirements design team joint effort.  In addition to the
+   authors/editors listed in the "Authors' Addresses" section, the
+   following are the design team members who contributed to the
+   document:
+
+   Alia K.  Atlas
+   Google Inc.
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043 USA
+   EMail: akatlas@alum.mit.edu
+
+   Arthi Ayyangar
+   Nuova Systems,
+   2600 San Tomas Expressway
+   Santa Clara, CA 95051
+   EMail: arthi@nuovasystems.com
+
+   Nabil Bitar
+   Verizon
+   40 Sylvan Road
+   Waltham, MA 02145 USA
+   EMail: nabil.bitar@verizon.com
+
+   Igor Bryskin
+   Independent Consultant
+   EMail: i_bryskin@yahoo.com
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 17]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+   Dean Cheng
+   Cisco Systems, Inc.
+   3700 Cisco Way
+   San Jose CA 95134 USA
+   Phone:  408 527 0677
+   EMail: dcheng@cisco.com
+
+   Durga Gangisetti
+   MCI
+   EMail: durga.gangisetti@mci.com
+
+   Kenji Kumaki
+   KDDI Corporation
+   Garden Air Tower
+   Iidabashi, Chiyoda-ku,
+   Tokyo 102-8460, JAPAN
+   Phone: 3-6678-3103
+   EMail: ke-kumaki@kddi.com
+
+   Eiji Oki
+   NTT
+   Midori-cho 3-9-11
+   Musashino-shi, Tokyo 180-8585, JAPAN
+   EMail: oki.eiji@lab.ntt.co.jp
+
+   Raymond Zhang
+   BT INFONET Services Corporation
+   2160 E. Grand Ave.
+   El Segundo, CA 90245 USA
+   EMail: Raymond_zhang@bt.infonet.com
+
+9.  Acknowledgements
+
+   The authors would like to extend their warmest thanks to (in
+   alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas
+   Morin, Dimitri Papadimitriou, Robert Sparks, and J.P. Vasseur for
+   their review and suggestions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 18]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+10.  References
+
+10.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.
+
+10.2.  Informative References
+
+   [METRIC]            Le Faucheur, F., Uppili, R., Vedrenne, A.,
+                       Merckx, P., and T. Telkamp, "Use of Interior
+                       Gateway Protocol (IGP) Metric as a second MPLS
+                       Traffic Engineering (TE) Metric", BCP 87, RFC
+                       3785, May 2004.
+
+   [PCE-DISC-REQ]      Le Roux, J.L., et al., "Requirements for Path
+                       Computation Element (PCE) Discovery", Work in
+                       Progress.
+
+   [PCECP-INTER-AREA]  Le Roux, J.L., et al., "PCE Communication
+                       Protocol (PCECP) specific requirements for
+                       Inter-Area (G)MPLS Traffic Engineering", Work in
+                       Progress.
+
+   [PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication
+                       Requirements for Inter-Layer Traffic
+                       Engineering", Work in Progress.
+
+   [PCECP-INTER-AS]    Bitar, N., Zhang, R., Kumaki, K., "Inter-AS
+                       Requirements for the Path Computation Element
+                       Communication Protocol (PCECP)", Work in
+                       Progress.
+
+   [RFC3209]           Awduche, D., Berger, L., Gan, D., Li, T.,
+                       Srinivasan, V., and G. Swallow, "RSVP-TE:
+                       Extensions to RSVP for LSP Tunnels", RFC 3209,
+                       December 2001.
+
+   [RFC3127]           Mitton, D., St.Johns, M., Barkley, S., Nelson,
+                       D., Patil, B., Stevens, M., and B. Wolff,
+                       "Authentication, Authorization, and Accounting:
+                       Protocol Evaluation", RFC 3127, June 2001.
+
+
+
+
+Ash & Le Roux                Informational                     [Page 19]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 2006
+
+
+Authors' Addresses
+
+   Jerry Ash (Editor)
+   AT&T
+   Room MT D5-2A01
+   200 Laurel Avenue
+   Middletown, NJ 07748, USA
+
+   Phone: (732)-420-4578
+   EMail: gash@att.com
+
+
+   Jean-Louis Le Roux (Editor)
+   France Telecom
+   2, avenue Pierre-Marzin
+   22307 Lannion Cedex, FRANCE
+
+   EMail: jeanlouis.leroux@orange-ft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 20]
+
+RFC 4657       PCE Communication Protocol Generic Reqmnts September 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).
+
+
+
+
+
+
+
+Ash & Le Roux                Informational                     [Page 21]
+