From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4657.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc4657.txt (limited to 'doc/rfc/rfc4657.txt') 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] + -- cgit v1.2.3