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
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.
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.
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].
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).
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.
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
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
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.
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
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):
- 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