draft-ietf-pce-comm-protocol-gen-reqs-03.txt   draft-ietf-pce-comm-protocol-gen-reqs-04.txt 
IETF Internet Draft PCE Working Group Jerry Ash (AT&T) IETF Internet Draft PCE Working Group Jerry Ash (AT&T)
Proposed Status: Informational Editor Proposed Status: Informational Editor
Expires: June 2006 J.L. Le Roux (France Telecom) Expires: August 2006 J.L. Le Roux (France Telecom)
Editor Editor
December 2005 February 2006
draft-ietf-pce-comm-protocol-gen-reqs-03.txt draft-ietf-pce-comm-protocol-gen-reqs-04.txt
PCE Communication Protocol Generic Requirements PCE Communication Protocol Generic Requirements
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 20, 2006. This Internet-Draft will expire on August 1, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The PCE model is described in the "PCE Architecture" document and The PCE model is described in the "PCE Architecture" document and
facilitates path computation requests from Path Computation Clients facilitates path computation requests from Path Computation Clients
(PCCs) to Path Computation Elements (PCEs). This document specifies (PCCs) to Path Computation Elements (PCEs). This document specifies
generic requirements for a communication protocol between PCCs and generic requirements for a communication protocol between PCCs and
PCEs, and also between PCEs where cooperation between PCEs is PCEs, and also between PCEs where cooperation between PCEs is
desirable. Subsequent documents will specify application-specific desirable. Subsequent documents will specify application-specific
requirements for the PCE communication protocol. requirements for the PCE communication protocol.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 5 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 3
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 4
6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 5
6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 5
6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 5
6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 6
6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 7
6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 8
6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 8
6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 8
6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 9
6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 12 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 9
6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 10
6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 10
6.1.13 Communication Overhead Minimization . . . . . . . . . 12 6.1.13 Communication Overhead Minimization . . . . . . . . . 10
6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 13 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 10
6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 11
6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 14 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 11
6.1.17 Objective Functions Supported . . . . . . . . . . . . 15 6.1.17 Objective Functions Supported . . . . . . . . . . . . 12
6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 15 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 13
6.2.1 Support for Different Service Provider Environments . . 15 6.2.1 Support for Different Service Provider Environments . . 13
6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 15 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 13
6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 16 6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . 13
6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 16 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 13
6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 16 6.3.2 Protocol Recovery . . . . . . . . . . . . . . . . . . . 14
6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 16 6.3.3 LSP Rerouting & Reoptimization . . . . . . . . . . . . 14
6.3.4 LSP Rerouting & Reoptimization . . . . . . . . . . . . 17 6.4 Requirements Summary . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Manageability Considerations . . . . . . . . . . . . . . . . . . 18 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 19 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 18
12. Informational References . . . . . . . . . . . . . . . . . . . . 19 12. Informational References . . . . . . . . . . . . . . . . . . . . 18
13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 20 13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 19
Intellectual Property Statement . . . . . . . . . . . . . . . . . . 21 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 20
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 22 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Contributors 1. Contributors
This document is the result of the PCE Working Group PCE This document is the result of the PCE Working Group PCE
Communication Protocol (PCECP) requirements design team joint effort. Communication Protocol (PCECP) requirements design team joint effort.
The following are the design team member authors that contributed to The following are the design team member authors that contributed to
the present document: the present document:
Jerry Ash (AT&T) Jerry Ash (AT&T)
Alia Atlas (Google, Inc.) Alia Atlas (Google, Inc.)
skipping to change at page 3, line 39 skipping to change at page 3, line 33
3. Introduction 3. Introduction
A Path Computation Element (PCE) [PCE-ARCH] supports requests for A Path Computation Element (PCE) [PCE-ARCH] supports requests for
path computation issued by a Path Computation Client (PCC), which may path computation issued by a Path Computation Client (PCC), which may
be 'composite' (co-located) or 'external' (remote) from a PCE. When be 'composite' (co-located) or 'external' (remote) from a PCE. When
the PCC is external from the PCE, a request/response communication the PCC is external from the PCE, a request/response communication
protocol is required to carry the path computation request and return protocol is required to carry the path computation request and return
the response. In order for the PCC and PCE to communicate, the PCC 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 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 [PCE-DISC-REQ].
compute paths based on the path computation request issued by the
PCC. The path computation request will normally include the source
and destination of the paths to be computed, and a set of constraints
to be applied during the computation. 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 The PCE operates on a network graph in order to compute paths based
Communication Protocol (PCECP). Application-specific requirements on the path computation request(s) issued by the PCC(s). The path
are beyond the scope of this document, and will be addressed in computation request will include the source and destination of the
separate documents. paths to be computed, a set of constraints to be applied during the
computation, and 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 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.
4. Terminology 4. Terminology
Domain: any collection of network elements within a common sphere of Domain: any collection of network elements within a common sphere of
address management or path computational responsibility. Examples of address management or path computational responsibility. Examples of
domains include IGP areas, Autonomous Systems (ASs), multiple ASs domains include IGP areas, Autonomous Systems (ASs), multiple ASs
within a service provider network, or multiple ASs across multiple within a service provider network, or multiple ASs across multiple
service provider networks. service provider networks.
GMPLS: Generalized Multi-Protocol Label Switching GMPLS: Generalized Multi-Protocol Label Switching
LSP: MPLS Label Switched Path. LSP: MPLS/GMPLS Label Switched Path
LSR: Label Switch Router
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
Path computation to be performed by the PCE. path computation to be performed by the PCE.
PCE: Path Computation Element: an entity (component, application or PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints (see based on a network graph and applying computational constraints (see
further description in [PCE-ARCH]). further description in [PCE-ARCH]).
TED: Traffic Engineering Database, which contains the topology and TED: Traffic Engineering Database, which contains the topology and
resource information of the network or network segment used by a PCE. resource information of the network or network segment used by a PCE.
TE LSP: Traffic Engineering MPLS Label Switched Path. TE LSP: Traffic Engineering (G)MPLS Label Switched Path.
See [PCE-ARCH] for further definitions of terms. See [PCE-ARCH] for further definitions of terms.
5. Overview of PCE Communication Protocol (PCECP) 5. Overview of PCE Communication Protocol (PCECP)
In the PCE model, path computation requests are issued by a PCC In the PCE model, path computation requests are issued by a PCC
to a PCE that may be composite (co-located) or external (remote). to a PCE that may be composite (co-located) or external (remote). If
If the PCC and PCE are not composite, a request/response the PCC and PCE are not co-located, a request/response communication
communication protocol is required to carry the request and return protocol is required to carry the request and return the response.
the response. If the PCC and PCE are composite, a communication If the PCC and PCE are co-located, a communication protocol is not
protocol is not required, but implementations may choose to utilize required, but implementations may choose to utilize a protocol for
a protocol for exchanges between the components. exchanges between the components.
In order that a PCC and PCE can communicate, the PCC must know the In order that a PCC and PCE can communicate, the PCC must know the
location of the PCE. This can be configured or discovered. The PCE location of the PCE. This can be configured or discovered. The PCE
discovery mechanism is out of scope of this document, but discovery mechanism is out of scope of this document, but
requirements are documented in [PCE-DISC-REQ]. requirements are documented in [PCE-DISC-REQ].
The PCE operates on a network graph built from the TED in order to 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 compute paths. The mechanism by which the TED is populated is out of
scope for the PCECP. scope for the PCECP.
skipping to change at page 5, line 22 skipping to change at page 5, line 25
for PCC-PCE and PCE-PCE communication. for PCC-PCE and PCE-PCE communication.
[PCE-ARCH] describes four models of PCE: composite, external, [PCE-ARCH] describes four models of PCE: composite, external,
multiple PCE path computation, and multiple PCE path computation with multiple PCE path computation, and multiple PCE path computation with
inter-PCE communication. In all cases except the composite PCE model, inter-PCE communication. In all cases except the composite PCE model,
a PCECP is required. The requirements defined in this document are a PCECP is required. The requirements defined in this document are
applicable to all models described in the [PCE-ARCH]. applicable to all models described in the [PCE-ARCH].
6. PCE Communication Protocol Generic Requirements 6. PCE Communication Protocol Generic Requirements
The following is a summary of the requirements in Section 6: Section 6.4 contains a summary of the requirements in this section.
Requirement Necessity Ref.
------------------------------------------------------------------
Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1
Client-server communication MUST 6.1.2
Support PCC/PCE request message to request path
computation MUST 6.1.2
Support PCE response message with computed path MUST 6.1.2
Support unsolicited communication PCE-PCC SHOULD 6.1.2
Maintain PCC-PCE session NON-RQMT 6.1.2
Use of existing transport protocol MAY 6.1.3
Transport protocol satisfy reliability & security
requirements MAY 6.1.3
Transport protocol limits size of message MUST NOT 6.1.3
Support path computation requests MUST 6.1.4
include source & destination
support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude MUST 6.1.4
Allow to select/prefer from advertised list of
standard objective functions/options MUST 6.1.4
Allow to customize objective function/options MUST 6.1.4
Allow indicating the metric type (IGP or TE) to
be used for shortest path selection MUST 6.1.4
Allow indicating the set of aggregate path
attributes required in response message MUST 6.1.4
Allow indicating if load-balancing is allowed MUST 6.1.4
Support path computation responses MUST 6.1.5
Negative response support reasons for failure,
constraints to relax to achieve positive result SHOULD 6.1.5
Support inclusion of set of aggregate path
attributes MUST 6.1.5
Support inclusion of set of computed paths of a
load-balancing path group, as well as their
respective bandwidth MUST 6.1.5
Cancellation of pending requests MUST 6.1.6
Multiple requests and responses MUST 6.1.7
Limit by configuration number of requests within
a message MUST 6.1.7
Support multiple computed paths in response MUST 6.1.7
Support "continuation correlation" where related
requests or computed paths cannot fit within one
message MUST 6.1.7
Maximum message size & maximum number of requests
per message exchanged through PCE messages to PCC,
or indicated in request message MAY 6.1.7
Reliable message exchange (achieved by PCECP
itself or transport protocol MUST 6.1.8
Allow detection & recovery of lost messages to
occur quickly & not impede operation of PCECP MUST 6.1.8
Handle overload situations without significant
decrease in performance, e.g., through throttling
of requests MUST 6.1.8
Provide acknowledged message delivery with
retransmission, in order message delivery or
facility to restore order, message corruption
detection, flow control & back-pressure to
throttle requests, rapid partner failure
detection, informed rapidly of failure of PCE-PCC
connection MUST 6.1.8
Functionality added to PCECP if transport protocol
provides it SHOULD NOT 6.1.8
Secure message exchange (provided by PCECP or
transport protocol MUST 6.1.9
Support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption),
DOS attacks MUST 6.1.9
Request prioritization MUST 6.1.10
Unsolicited notifications SHOULD 6.1.11
Allow asynchronous communication MUST 6.1.12
PCC has to wait for response before making
another request MUST NOT 6.1.12
Allow order of responses differ from order of
requests MUST 6.1.12
Communication overhead minimization SHOULD 6.1.13
Give particular attention to message size SHOULD 6.1.13
Extensibility without requiring modifications to
the protocol MUST 6.1.14
Easily extensible to support intra-area,
inter-area, inter-AS intra provider, inter-AS
inter-provider, multi-layer path & virtual network
topology path computation MUST 6.1.14
Easily extensible to support future applications
not in scope (e.g., P2MP path computations) SHOULD 6.1.14
Scalability at least linearly with increase in
number of PCCs, PCEs, PCCs communicating with a
single PCE, PCEs communicated to by a single PCC,
PCEs communicated to by another PCE, domains, path
requests, handling bursts of requests MUST 6.1.15
Support path computation constraints MUST 6.1.16
Support "unsynchronized" & "synchronized"
objective functions MUST 6.1.17
Support different service provider environments
(e.g., MPLS-TE and GMPLS networks, centralized &
distributed PCE path computation, single &
multiple PCE path computation) MUST 6.2.1
Policy support for policies to accept/reject
requests, PCC to determine reason for rejection,
notification of policy violation MUST 6.2.2
Aliveness detection of PCCs/PCEs, partner failure
detection MUST 6.3.1
PCC/PCE failure response procedures defined for
PCE/PCC failures, PCC able to clear pending
request must 6.3.2
PCC select another PCE upon detection of PCE
failure MUST 6.3.2
PCE able to clear pending requests from a PCC
(e.g. when it detects PCC failure or request
buffer full) must 6.3.2
Protocol recovery support resynchronization of
information & requests between sender & receiver MUST 6.3.3
Minimize repeat data transfer, allow PCE to
respond to computation requests issued before
failure without requests being re-issued SHOULD 6.3.3
Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD 6.3.3
Allow indicating if computation is for LSP
restoration (support inclusion of previously
computed path & failed element) MUST 6.3.4
Support inclusion in response message of upper
bound of a random waiting time for further
requests MAY 6.3.4
Support path reoptimization & inclusion of a
previously computed path MUST 6.3.4
6.1 Basic Protocol Requirements 6.1 Basic Protocol Requirements
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication
A single protocol MUST be defined for PCC-PCE and PCE-PCE A single protocol MUST be defined for PCC-PCE and PCE-PCE
communication. A PCE requesting a path from another PCE can be communication. A PCE requesting a path from another PCE can be
considered as a PCC. considered as 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.
6.1.2 Client-Server Communication 6.1.2 Client-Server Communication
PCC-PCE and PCE-PCE communication is by nature client-server based. PCC-PCE communication is by nature client-server based. The PCECP
The PCECP MUST allow for a PCC or a PCE to send a request message to MUST allow a PCC to send a request message to a PCE to request path
a PCE to request path computation, and for a PCE to reply with a computation, and for a PCE to reply with a response message to the
response message to the requesting PCC or PCE, once the path has been requesting PCC once the path has been computed.
computed.
In addition to this request-response mode, there may be cases where In addition to this request-response mode, there are cases where
there is unsolicited communication from the PCE to PCC (see there is unsolicited communication from the PCE to the PCC (see
Requirement 6.1.6). Section 6.1.11).
6.1.3 Transport 6.1.3 Transport
The PCECP may utilize an existing transport protocol or operate The PCECP may utilize an existing transport protocol or operate
directly over IP. directly over IP.
If a transport protocol is used, it may be used to satisfy some If a transport protocol is used, it MAY be used to satisfy some
requirements stated in other sections of this document (for example, requirements stated in other sections of this document (for example,
reliability and security). reliability and security). Where requirements expressed in this
document match the function of existing transport protocols,
consideration MUST be given to the use of those protocols.
If a transport protocol is used, it MUST NOT limit the size of the If a transport protocol is used, it MUST NOT limit the size of the
message used by the PCECP. message used by the PCECP.
Where requirements expressed in this document match the function of
existing transport protocols, consideration MUST be given to the use
of those protocols.
6.1.4 Path Computation Requests 6.1.4 Path Computation Requests
The request message MUST include, at least, a source and a The path computation request message MUST include at least the source
destination. However, there is no assumption that the receiving PCE and destination. Note that the path computation request is for an
has the complete source/destination domain topology, particularly in LSP or LSP segment, and the source and destination supplied are the
the multiple PCE path computation model [PCE-ARCH]. In the latter start and end of the computation being requested (i.e. of the LSP
case, the PCE may have incomplete topological information for segment).
multiple domains.
The message MUST support the inclusion of a set of one or more path The path computation request message MUST support the inclusion of a
constraints, including the requested bandwidth or resources (hops, set of one or more path constraints, including but not limited to the
affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to requested bandwidth or resources (hops, affinities, etc.) to
exclude points of failure in the computation of the new path if an include/exclude. For example, a PCC may request the PCE to exclude
LSP setup fails). The actual inclusion of constraints is a choice points of failure in the computation of a new path if an LSP setup
for the PCC issuing the request. A list of core constraints that fails. The actual inclusion of constraints is a choice for the PCC
MUST be supported by the PCECP is supplied in Section 6.1.16. issuing the request. A list of core constraints that must be
Specification of constraints must be future-proofed as described in supported by the PCECP is supplied in Section 6.1.16. Specification
Section 6.1.14. of constraints MUST be future-proofed as described in Section 6.1.14.
The requester MUST be allowed to select or prefer from an advertised The requester MUST be allowed to select or prefer from an advertised
list or minimal subset of standard objective functions and functional list or minimal subset of standard objective functions and functional
options. An objective function is used by the PCE to compute a path options. An objective function is used by the PCE to process
metric in order to select the best candidate paths (e.g., minimum hop constraints to a path computation request when it computes a path in
path), and corresponds to the optimization criteria used for the order to select the "best" candidate paths (e.g., minimum hop path),
computation of one path, or the synchronized computation of a set of and corresponds to the optimization criteria used for the computation
paths. In case of unsynchronized path computation, this can be, for 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 example, the path cost or the residual bandwidth on the most loaded
path link. In case of synchronized path computation, this can be, path link. In the case of synchronized path computation, this can
for example, the global bandwidth consumption or the residual be, for example, the global bandwidth consumption or the residual
bandwidth on the most loaded network link. bandwidth on the most loaded network link.
A list of core objective functions that MUST be supported by the A list of core objective functions that MUST be supported by the
PCECP is supplied in Section 6.1.17. Specification of objective PCECP is supplied in Section 6.1.17. Specification of objective
functions MUST be future-proofed as described in Section 6.1.14. functions MUST be future-proofed as described in Section 6.1.14.
The shortest path selection may rely either on the TE metric or on
the IGP metric [METRIC]. Hence the PCECP request message MUST allow
indicating the metric type (IGP or TE) to be used for shortest path
selection. It MUST also allow indicating the set of aggregate path
attributes (hop-count, cumulated TE-metric, cumulated IGP-Metric)
that are required in the PCECP response message.
The request message MUST allow indicating if load-balancing is
allowed or not. 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 requester SHOULD also be able to select a vendor-specific or The requester SHOULD also be able to select a vendor-specific or
experimental objective function or functional option. Furthermore, experimental objective function or functional option. Furthermore,
the requester MUST be allowed to customize the function/options in the requester MUST be allowed to customize the function/options in
use. That is, individual objective functions will often have use. That is, individual objective functions will often have
parameters to be set in the request from PCC to PCE. Specification parameters to be set in the request from PCC to PCE. Support for the
of objective functions and objective parameters is required in the specification of objective functions and objective parameters is
protocol extensibility specified in Section 6.1.14. required in the protocol extensibility specified in Section 6.1.14.
Note that a PCC MAY send a request that is based on the set of TE A request message MAY include TE parameters carried by the MPLS/GMPLS
parameters carried by the MPLS/GMPLS LSP setup signaling protocol, LSP setup signaling protocol. Also, it MUST be possible for the PCE
and as long as those parameters are satisfied, the PCC MAY not care to apply additional objective functions. This might include policy
about which objective function is used. Also, the PCE MAY execute based routing path computation for load balancing instructed by the
additional objective functions not explicitly requested by the PCC. management plane.
This might include policy based routing path computation for load
balancing instructed by the management plane. The PCC MUST NOT be Shortest path selection may rely either on the TE metric or on the
allowed to request or cause a computation to fail because it does not IGP metric [METRIC]. Hence the PCECP request message MUST allow the
wish the PCE to apply a specific objective function. Allowing such PCC to indicate the metric type (IGP or TE) to be used for shortest
behavior would constitute a security risk. 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 or not. 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.
6.1.5 Path Computation Responses 6.1.5 Path Computation Responses
The response message MUST allow returning various elements including, The path computation response message MUST allow the PCE to return
at least, the computed path(s). various elements including, at least, the computed path(s).
The protocol MUST be capable of returning any explicit path that The protocol MUST be capable of returning any explicit path that
would be acceptable for use for MPLS and GMPLS LSPs once converted to 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, an Explicit Route Object for use in RSVP-TE signaling. In addition,
anything that can be expressed in an Explicit Route Object MUST be anything that can be expressed in an Explicit Route Object MUST be
capable of being returned in the computed path. Note that the 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 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 any combination of strict and loose hops. Moreover, a hop may have
the form of a non-simple abstract node. See RFC 3209 for the the form of a non-simple abstract node. See [RFC 3209] for the
definition of strict hop, loose hop, and abstract node. definition of strict hop, loose hop, and abstract node.
A positive response from the PCE will include the paths that have A positive response from the PCE MUST include the paths that have
been computed. When a path satisfying the constraints cannot be been computed. A positive PCECP computation response MUST support
found, or if the computation fails or cannot be performed, a the inclusion of a set of attributes of the computed path, such as
negative response MUST be sent. This response MAY include further the path costs (e.g., cumulative link TE metrics and cumulative link
details of the reason(s) for the failure, and potentially advice IGP metrics) and the computed bandwidth. The latter is useful when a
about which constraints might be relaxed to be more likely to achieve single path cannot serve the requested bandwidth and load balancing
a positive result. is applied.
The PCECP response message MUST support the inclusion of a set of When a path satisfying the constraints cannot be found, or if the
aggregate path attributes. 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 The PCECP response message MUST support the inclusion of the set of
computed paths of a load-balancing path group, as well as their computed paths of a load-balancing path group, as well as their
respective bandwidth. respective bandwidths.
6.1.6 Cancellation of Pending Requests 6.1.6 Cancellation of Pending Requests
A PCC or PCE MUST be able to cancel a pending request, using an A PCC MUST be able to cancel a pending request using a notification
appropriate notification between PCECP peers. A PCC that has sent a message. A PCC that has sent a request to a PCE and no longer needs
request to a PCE and no longer needs a response, for instance, a response, for instance because it no longer wants to set up the
because it received a satisfactory answer from another PCE, MUST be associated service, MUST be able to notify the PCE that it can clear
able to notify the PCE that it must clear the request (i.e. stop the the request (i.e. stop the computation if already started, and clear
computation, if already started, and clear the context). Similarly, the context). The PCE may also wish to cancel a pending request
a PCE that received a request from a PCC that it cannot serve, for because of some congested state.
example, due to congestion, MUST be able to notify the PCC, that the
request will not be served.
6.1.7 Multiple Requests and Responses 6.1.7 Multiple Requests and Responses
It MUST be possible to send multiple path computation requests, It MUST be possible to send multiple path computation requests
correlated or not, within the same request message. There are within the same request message. Such requests may be correlated (for
various motivations for doing so (optimality, path diversity, etc.). example, requesting disjoint paths) or uncorrelated (requesting paths
It MUST be possible to limit by configuration of both PCCs and PCEs for unrelated services). It MUST be possible to limit by
the number of requests that can be carried within a single message. 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 Similarly, it MUST be possible to return multiple computed paths
within the same response message, corresponding either to the same within the same response message, corresponding either to the same
request (e.g. load balancing) or to distinct requests, correlated or request (e.g. multiple suited paths, paths of a load balancing path
not, of the same request message or distinct request messages. 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 It MUST be possible to provide "continuation correlation" where all
related requests or computed paths cannot fit within one message. related requests or computed paths cannot fit within one message, and
are carried in a sequence of correlated messages.
Maximum acceptable message sizes and the maximum number of requests The PCE MUST inform the PCC of its capabilities. Maximum acceptable
per message supported by a PCE MAY form part of PCE capabilities message sizes and the maximum number of requests per message
advertisement [PCE-DISC-REQ], or MAY be exchanged through information supported by a PCE MAY form part of PCE capabilities advertisement
messages from the PCE as part of the protocol described here. [PCE-DISC-REQ], or MAY be exchanged through information messages from
the PCE as part of the protocol described here.
Maximum acceptable message sizes and the maximum number of computed It MUST be possible for a PCC to specify, in the request message, the
paths per message supported by a PCC MAY be indicated in the request maximum acceptable response message sizes and the maximum number of
message. computed paths per response message it can support.
An implementation MAY choose to limit message size to avoid a big It MUST be possible to limit the message size by configuration on
message from unduly delaying a small message. PCCs and PCEs.
6.1.8 Reliable Message Exchange 6.1.8 Reliable Message Exchange
The PCECP MUST include reliability. This may form part of the The PCECP MUST include reliability. This may form part of the
protocol itself or may be achieved by the selection of a suitable protocol itself or may be achieved by the selection of a suitable
transport protocol (see Section 6.1.3). transport protocol (see Section 6.1.3).
In particular, it MUST allow for the detection and recovery of lost In particular, it MUST allow for the detection and recovery of lost
messages to occur quickly and not impede the operation of the PCECP. 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 In some cases (e.g. after link failure), a large number of PCCs may
simultaneously send requests to a PCE, leading to a potential simultaneously send requests to a PCE, leading to a potential
saturation of the PCEs. The PCECP or the transport protocol it uses saturation of the PCEs. The PCECP MUST support indication of
MUST properly handle such overload situations, such as through congestion state and rate limitation state. This should enable, for
throttling of requests. For example, a PCE MUST be able to limit the example, a PCE to limit the rate of incoming request messages if the
rate of incoming request messages to a manageable rate by notifying request rate is too high.
PCCs and/or peering PCEs.
The PCECP or the transport protocol it uses MUST provide: The PCECP MUST provide:
- Acknowledged message delivery with retransmission. - Detection and report of lost or corrupted messages
- In order message delivery or the facility (such as message - Automatic attempts to retransmit lost messages without reference to
numbering) to restore the order of received messages. the application
- Message corruption detection. - Handling of out-of-order messages
- Flow control and back-pressure, as specified above with the - Handling of duplicate messages
throttling of requests. - Flow control and back-pressure to enable throttling of requests and
- Rapid partner failure detection. responses
- Rapid PCE/PCC or PCC-PCE connection failure detection after - Rapid PCECP communication failure detection
failure happens. - 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 If it is necessary to add functions to PCECP to overcome shortcomings
in the chosen transport mechanisms, these functions SHOULD be based in the chosen transport mechanisms, these functions SHOULD be based
on and re-use where possible techniques developed in other protocols on and re-use where possible techniques developed in other protocols
to overcome the same shortcomings. Functionality SHOULD NOT be added to overcome the same shortcomings. Functionality MUST NOT be added
to the PCECP where the chosen transport protocol already provides it. to the PCECP where the chosen transport protocol already provides it.
6.1.9 Secure Message Exchange 6.1.9 Secure Message Exchange
The PCC-PCE and PCE-PCE communication protocol MUST include The PCC-PCE communication protocol MUST include provisions to insure
provisions to improve the security of the exchanges between the the security of the exchanges between the entities. In particular,
entities. In particular, it MUST support mechanisms to prevent it MUST support mechanisms to prevent spoofing (e.g.,
spoofing (e.g., authentication), snooping (e.g., encryption) and DOS authentication), snooping (e.g., encryption) and DOS attacks (e.g.,
attacks (e.g., rate limiting, no promiscuous listening). rate limiting, no promiscuous listening).
This function may be provided by the transport protocol or directly This function may be provided by the transport protocol or directly
by the PCECP. by the PCECP.
See Section 7 for further discussion of security considerations. See Section 7 for further discussion of security considerations.
6.1.10 Request Prioritization 6.1.10 Request Prioritization
The PCECP MUST allow a PCC to specify the priority of a computation The PCECP MUST allow a PCC to specify the priority of a computation
request. This priority MAY be used by a PCE to service high priority request.
requests before lower priority requests considering all requests
received and queued by a single PCE from all PCCs.
Implementation of priority-based activity within a PCE is subject to Implementation of priority-based activity within a PCE is subject to
implementation and local policy. This application processing is out implementation and local policy. This application processing is out
of scope of the PCECP. of scope of the PCECP.
6.1.11 Unsolicited Notifications 6.1.11 Unsolicited Notifications
The normal operational mode is for the PCC to make path computation The normal operational mode is for the PCC to make path computation
requests to the PCE, and for the PCE to respond. requests to the PCE, and for the PCE to respond.
The PCECP SHOULD support unsolicited notifications from PCE to PCC, The PCECP MUST support unsolicited notifications from PCE to PCC, or
PCE to PCE, or PCC to PCE. This requirement facilitates the PCC to PCE. This requirement facilitates the unsolicited
unsolicited communication of information and alerts between PCCs and communication of information and alerts between PCCs and PCEs.
PCEs and between PCEs.
6.1.12 Asynchronous Communication 6.1.12 Asynchronous Communication
The PCC-PCE protocol MUST allow for asynchronous communication. A The PCC-PCE protocol MUST allow for asynchronous communication. A
PCC MUST NOT have to wait for a response before it can make another PCC MUST NOT have to wait for a response to one request before it can
request. make another request.
It MUST also be possible to have the order of responses differ from It MUST also be possible to have the order of responses differ from
the order of the corresponding requests. This may occur, for the order of the corresponding requests. This may occur, for
instance, when path request messages have different priorities (see instance, when path request messages have different priorities (see
Requirement 6.1.10). Requirement 6.1.10). A consequent requirement is that path
computation responses MUST include a direct correlation to the
associated request.
6.1.13 Communication Overhead Minimization 6.1.13 Communication Overhead Minimization
The request and response messages SHOULD be designed so that the The request and response messages SHOULD be designed so that the
communication overhead is minimized. In particular, the overhead per communication overhead is minimized. In particular, the overhead per
message should be minimized, and the number of bytes exchanged to message SHOULD be minimized, and the number of bytes exchanged to
arrive at a computation answer should be minimized. Note that arrive at a computation answer SHOULD be minimized. Other
compression techniques are not required. Other considerations in considerations in overhead minimization include the following:
overhead minimization include the following:
- the amount of background messages used by the protocol or its - the number of background messages used by the protocol or its
transport protocol to keep alive any session or association transport protocol to keep alive any session or association
between the PCE and PCC between the PCE and PCC
- the processing cost at the PCE (or PCC) associated with - the processing cost at the PCE (or PCC) associated with
request/response messages (as distinct from processing the request/response messages (as distinct from processing the
computation requests themselves). computation requests themselves).
6.1.14 Extensibility 6.1.14 Extensibility
The PCECP MUST provide a way for the introduction of new path The PCECP MUST provide a way for the introduction of new path
computation constraints, diversity types, objective functions, computation constraints, diversity types, objective functions,
optimization methods and parameters, etc., without requiring optimization methods and parameters, etc., without requiring
modifications in the protocol. major modifications in the protocol.
The PCECP MUST be easily extensible to support various PCE based The PCECP MUST be easily extensible to support various PCE based
applications that have been currently identified including: applications that have been currently identified including:
- intra-area path computation - intra-area path computation [PCECP-INTER-AREA]
- inter-area path computation - inter-area path computation
- inter-AS intra provider and inter-AS inter-provider path - inter-AS intra provider and inter-AS inter-provider path
computation computation
- inter-layer path computation [PCECP-MULTI-LAYER]
The PCECP MUST also allow extensions as more PCE applications will be The PCECP MUST support the requirements specified in the
introduced in the future. For example, the protocol may be extended application-specific requirements documents. The PCECP MUST also
to support PCE-based multi-layer path computation and virtual network allow extensions as more PCE applications will be introduced in the
topology computation/reconfiguration. future.
The PCECP SHOULD also be easily extensible to support future The PCECP SHOULD also be extensible to support future applications
applications not currently in the scope of the PCE working group, not currently in the scope of the PCE working group, such as, for
such as, for instance, P2MP path computations, multi-hop pseudowire instance, point-to-multipoint path computations, multi-hop pseudowire
path computation, etc. path computation, etc.
Note that application specific requirements are out of the scope of Note that application specific requirements are out of the scope of
this document and will be addressed in separate requirements this document and will be addressed in separate requirements
documents. documents.
6.1.15 Scalability 6.1.15 Scalability
The PCECP MUST scale well, at least as good as linearly, with an The PCECP MUST scale well, at least as good as linearly, with an
increase of any of the following parameters (note, minimum order of increase of any of the following parameters (note, minimum order of
magnitude estimates of what the PCECP should support are given in magnitude estimates of what the PCECP should support are given in
parenthesis): parenthesis):
- number of PCCs (1000/domain) - number of PCCs (1000/domain)
- number of PCEs (100/domain) - number of PCEs (100/domain)
- number of PCCs communicating with a single PCE (1000) - number of PCCs communicating with a single PCE (1000)
- number of PCEs communicated to by a single PCC (100) - number of PCEs communicated to by a single PCC (100)
- number of PCEs communicated to by another PCE (100)
- number of domains (20) - number of domains (20)
- number of path request messages (average of 10/second/PCE) - number of path request messages (average of 10/second/PCE)
- handling bursts of requests (burst of 100/second/PCE within a 10- - handling bursts of requests (burst of 100/second/PCE within a 10-
second interval). second interval).
Note that path requests can be bundled in path request messages, for Note that path requests can be bundled in path request messages, for
example, 10 path request messages/second may correspond to 100 path example, 10 PCECP request messages/second may correspond to 100 path
requests/second. requests/second.
Bursts of requests may arise, for example, after a network outage Bursts of requests may arise, for example, after a network outage
when multiple recomputations are requested. It is RECOMMENDED that when multiple recomputations are requested. The PCECP MUST handle
the protocol handle the congestion in a graceful way so that it does the congestion in a graceful way so that it does not unduly impact
not unduly impact the rest of the network, and so that it does not the rest of the network, and so that it does not gate the ability of
gate the ability of the PCE to perform computation. the PCE to perform computation.
6.1.16 Constraints 6.1.16 Constraints
This section provides a list of generic constraints that MUST be This section provides a list of generic constraints that MUST be
supported by the PCECP. Other constraints may be added to service supported by the PCECP. Other constraints may be added to service
specific applications as identified by separate application-specific specific applications as identified by separate application-specific
requirements documents. requirements documents.
Note that the absence of a constraint in this list does not mean that Note that the absence of a constraint in this list does not mean that
that constraint must not be supported. Note also that the provisions the constraint must not be supported. Note also that the provisions
of Section 6.1.14 mean that new constraints can be added to this list of Section 6.1.14 mean that new constraints can be added to this list
without impacting the protocol. without impacting the protocol to a level that requires major
protocol changes.
Here is the list of generic constraints that MUST be supported: Here is the list of generic constraints that MUST be supported:
o MPLS-TE and GMPLS generic constraints: o MPLS-TE and GMPLS generic constraints:
- Bandwidth - Bandwidth
- Affinities inclusion/exclusion - Affinities inclusion/exclusion
- Link, Node, SRLG inclusion/exclusion - Link, Node, SRLG inclusion/exclusion
- Maximum end-to-end IGP metric - Maximum end-to-end IGP metric
- Hop Count - Maximum Hop Count
- Maximum end-to-end TE metric - Maximum end-to-end TE metric
- Multiple disjoint path computation to allow path protection - Degree of paths disjointess (Link, Node, SRLG)
o MPLS-TE specific constraints o MPLS-TE specific constraints
- Class-type - Class-type
- Local protection - Local protection
- Node protection - Node protection
- Bandwidth protection - Bandwidth protection
o GMPLS specific constraints o GMPLS specific constraints
- Switching type, encoding type - Switching type, encoding type
- Link protection type - Link protection type
Regarding affinities inclusion/exclusion, note the three categories
used in [RSVP-TE]: exclude-any, include-any, include-all. Regarding
link, node, SRLG inclusion/exclusion, note the mandatory and desired
exclusion approach in [EXCLUDE-ROUTE].
6.1.17 Objective Functions Supported 6.1.17 Objective Functions Supported
This section provides a list of generic objective functions that MUST This section provides a list of generic objective functions that MUST
be supported by the PCECP. Other objectives functions MAY be added be supported by the PCECP. Other objectives functions MAY be added
to service specific applications as identified by separate to service specific applications as identified by separate
application-specific requirements documents. application-specific requirements documents.
Note that the absence of an objective function in this list does not Note that the absence of an objective function in this list does not
mean that the objective function may not be supported. Note also mean that the objective function may not be supported. Note also
that the provisions of Section 6.1.14 mean that new objective that the provisions of Section 6.1.14 mean that new objective
functions MAY be added to this list without impacting the protocol. functions MAY be added to this list without impacting the protocol.
The PCECP MUST support the following "unsynchronized" objective The PCECP MUST support the following "unsynchronized" objective
functions: functions:
o Minimum cost path (shortest path) - Minimum cost path with respect to a specified metric(shortest path)
o Least loaded path (widest path) - Least loaded path
o To be determined - Maximum available bandwidth path
Also the PCECP MUST support the following "synchronized" objective Also the PCECP MUST support the following "synchronized" objective
functions: functions:
o Minimize aggregate bandwidth consumption on all links - Minimize aggregate bandwidth consumption on all links
o Maximize the residual bandwidth on the most loaded link. - Maximize the residual bandwidth on the most loaded link
O Minimize the cumulative cost of a set of diverse paths. - Minimize the cumulative cost of a set of diverse paths.
6.2 Deployment Support Requirements 6.2 Deployment Support Requirements
6.2.1 Support for Different Service Provider Environments 6.2.1 Support for Different Service Provider Environments
The PCECP MUST operate in various different service provider network The PCECP MUST operate in various different service provider network
environments that utilize an IP-based control plane, including environments that utilize an IP-based control plane, including
- MPLS-TE and GMPLS networks - MPLS-TE and GMPLS networks
- packet and non-packet networks - packet and non-packet networks
skipping to change at page 15, line 40 skipping to change at page 13, line 14
6.2 Deployment Support Requirements 6.2 Deployment Support Requirements
6.2.1 Support for Different Service Provider Environments 6.2.1 Support for Different Service Provider Environments
The PCECP MUST operate in various different service provider network The PCECP MUST operate in various different service provider network
environments that utilize an IP-based control plane, including environments that utilize an IP-based control plane, including
- MPLS-TE and GMPLS networks - MPLS-TE and GMPLS networks
- packet and non-packet networks - packet and non-packet networks
- centralized and distributed PCE path computation - centralized and distributed PCE path computation
- single and multiple PCE path computation - single and multiple PCE path computation
Definitions of centralized, distributed, single, and multiple PCE Definitions of centralized, distributed, single, and multiple PCE
path computation can be found in [PCE-ARCH]. path computation can be found in [PCE-ARCH].
6.2.2 Policy Support 6.2.2 Policy Support
The PCECP MUST allow for policies to accept/reject requests, and The PCECP MUST allow for the use of policies to accept/reject
include the ability for a PCE to reject requests with sufficient requests, and include the ability for a PCE to supply sufficient
detail to allow the PCC to determine the reason for rejection or detail when it rejects a request for policy reasons to allow the PCC
failure. For example, filtering could be required for intra-AS PCE to determine the reason for rejection or failure. For example,
path computation such that all requests are rejected that come from filtering could be required for a PCE that serves one domain (perhaps
another AS. However, specific policy details are left to an AS) such that all requests that come from another domain (AS) are
application-specific PCECP requirements. Furthermore, the PCECP MUST rejected. However, specific policy details are left to
allow for the notification of a policy violation. Actual policies, application-specific PCECP requirements. Actual policies,
configuration of policies, and applicability of policies are out of configuration of policies, and applicability of policies are out of
scope. scope.
Note that work on supported policy models and the corresponding Note that work on supported policy models and the corresponding
requirements/implications is being undertaken as a separate work item requirements/implications is being undertaken as a separate work item
in the PCE working group. in the PCE working group.
6.3 Detection & Recovery Requirements PCECP messages MUST be able to carry transparent policy information.
6.3 Aliveness Detection & Recovery Requirements
6.3.1 Aliveness Detection 6.3.1 Aliveness Detection
The PCECP MUST allow a PCC to check the liveliness of PCEs it is The PCECP MUST allow a PCC to
using for path computation, and a PCE to check the liveliness of
PCCs it is serving. This includes detection of PCE liveness before a - check the liveliness of the PCC-PCE communication
PCE is used for computation. i.e. during PCE selection. A PCC should - rapidly detect PCC-PCE communication failure (indifferently to
be aware of PCE liveness at all times. The PCECP MUST provide partner failure or connectivity failure),
partner failure detection. - 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 The aliveness detection mechanism MUST ensure reciprocal knowledge of
PCE and PCC liveness. PCE and PCC liveness.
Note that the PCE or PCC software component can be lost without 6.3.2 Protocol Recovery
losing the connection or the transport end-point, when a transport
protocol is used.
6.3.2 PCC/PCE Failure Response
Appropriate PCC and PCE procedures MUST be defined to deal with PCE
and PCC failures. A PCC must be able to clear any pending request to
a PCE so that it is no longer waiting for a response. Clearing a
pending request does not imply any message exchange; this differs
from pending request cancellation (Section 6.1.6), which requires
message exchange. It is RECOMMENDED that a PCC select another PCE
upon detection of PCE failure or unreachability of a PCE but note
that PCE selection procedure are out of the scope of this document.
Similarly, a PCE must be able to clear pending requests from a PCC,
for instance, when it detects the failure of the requesting PCC or
when its buffer of requests is full. Clearing a pending request does
not imply any message exchange.
6.3.3 Protocol Recovery
Information distributed in asynchronous/unsolicited messages MAY
persist at the recipient in the event of the failure of the sender or
of the communication channel. Upon recovery, the Communication
Protocol MUST support resynchronization of information and requests
between the sender and the receiver, and this SHOULD be arranged so
as to minimize repeat data transfer.
The response to a computation request issued before the PCC is
restarted will not be helpful and could be a waste of effort. Thus
it is better to allow the request to be re-issued in shorthand (e.g.
by request number) if the PCC remembers that it had previously issued
it and is still interested in the response.
The PCECP SHOULD allow a PCE to respond to computation requests
issued before the failure without the requests being re-issued.
6.3.4 LSP Rerouting & Reoptimization In the event of the failure of a sender or of the communication
channel, the PCECP, upon recovery, MUST support resynchronization of
information and requests between the sender and the receiver, and
this SHOULD be arranged so as to minimize repeat data transfer.
Upon LSP failure, due to link, node or SRLG failure, a head-end LSR 6.3.3 LSP Rerouting & Reoptimization
may send a request to the PCE so as to reroute the LSP over an
alternate path. So as to ease the computation such request should
include the previous path and the failed element (if it can be
identified).
Hence the request message MUST allow indicating if the computation is If an LSP fails owing to the failure of a link or node that it
for an LSP restoration, and MUST support the inclusion of the traverses, a new computation request may be made to a PCE in order to
previously computed path as well as the failed element. Note that repair the LSP. Since the PCC cannot know that the PCE's TED has been
the old path is actually useful only if the old LSP is not torn down updated to reflect the failure network information, it is useful to
yet. This is up to the PCC to decide if it includes the old path or include this information in the new path computation request. Also,
not. 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.
Note that a network failure may impact a large number of LSPs. A Hence the path computation request message MUST allow an indication
potentially large number of PCCs, are going to simultaneously send a of whether the computation is for LSP restoration, and MUST support
request to the PCE. Some jittering may be used on PCCs so as to delay the inclusion of the previously computed path as well as the identity
a request to the PCE, under network failure condition. of the failed element. Note that the old path might only be useful
if the old LSP has not yet been torn down.
The PCECP MAY support the inclusion, in a response message to a PCC, Note that a network failure may impact a large number of LSPs. In
of an upper bound of a random waiting time to be used for further this case, a potentially large number of PCCs is going to
requests to the PCE (e.g. the PCC will wait for a random value simultaneously send requests to the PCE. The PCECP MUST properly
between 0 and the upper bound before sending another request). This handle such overload situations, such as for instance through
upper bound would depend on the level of congestion of the PCE. throttling of requests as set forth in section 6.1.8.
The path computation request message MUST support TE LSP path The path computation request message MUST support TE LSP path
reoptimization and the inclusion of a previously computed path. This reoptimization and the inclusion of a previously computed path. This
will help ensure optimal routing of a reoptimized path, since it will will help ensure optimal routing of a reoptimized path, since it will
allow the PCE to avoid double bandwidth accounting and help reduce allow the PCE to avoid double bandwidth accounting and help reduce
blocking issues. blocking issues.
6.4 Requirements Summary
The following is a summary of the requirements in Section 6:
Requirement Necessity Ref.
------------------------------------------------------------------
Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1
Client-server communication MUST 6.1.2
Support PCC/PCE request message to request path
computation MUST 6.1.2
Support PCE response message with computed path MUST 6.1.2
Support unsolicited communication PCE-PCC SHOULD 6.1.2
Maintain PCC-PCE session NON-RQMT 6.1.2
Use of existing transport protocol MAY 6.1.3
Transport protocol satisfy reliability & security
requirements MAY 6.1.3
Transport protocol limits size of message MUST NOT 6.1.3
Support path computation requests MUST 6.1.4
Path computation request includes source &
destination MUST 6.1.4
Support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude MUST 6.1.4
Allow to select/prefer from advertised list of
standard objective functions/options MUST 6.1.4
Allow to customize objective function/options MUST 6.1.4
Allow indicating the metric type (IGP or TE) to
be used for shortest path selection MUST 6.1.4
Allow indicating the set of path attributes
required in response message MUST 6.1.4
Allow indicating if load-balancing is allowed MUST 6.1.4
Support path computation responses MUST 6.1.5
Negative response support reasons for failure,
constraints to relax to achieve positive result SHOULD 6.1.5
Support inclusion of set of path attributes MUST 6.1.5
Support inclusion of set of computed paths of a
load-balancing path group, as well as their
respective bandwidth MUST 6.1.5
Cancellation of pending requests MUST 6.1.6
Multiple requests and responses MUST 6.1.7
Limit by configuration number of requests within
a message MUST 6.1.7
Support multiple computed paths in response MUST 6.1.7
Support "continuation correlation" where related
requests or computed paths cannot fit within
one message MUST 6.1.7
Maximum message size & maximum number of requests
per message exchanged through PCE messages to
PCC, or indicated in request message MAY 6.1.7
Reliable message exchange (achieved by PCECP
itself or transport protocol) MUST 6.1.8
Allow detection & recovery of lost messages to
occur quickly & not impede operation of PCECP MUST 6.1.8
Handle overload situations without significant
decrease in performance, e.g., through
throttling of requests MUST 6.1.8
Detect/report lost/corrupted messages, retransmit
lost messages, handle out-of-order messages &
duplicate messages, provide flow control/
back-pressure to throttle messages, detect
PCECP communication failure detection MUST 6.1.8
Functionality added to PCECP if transport
protocol provides it SHOULD NOT 6.1.8
Secure message exchange (provided by PCECP or
transport protocol MUST 6.1.9
Support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption),
DOS attacks MUST 6.1.9
Request prioritization MUST 6.1.10
Unsolicited notifications SHOULD 6.1.11
Allow asynchronous communication MUST 6.1.12
PCC has to wait for response before making
another request MUST NOT 6.1.12
Allow order of responses differ from order of
requests MUST 6.1.12
Communication overhead minimization SHOULD 6.1.13
Give particular attention to message size SHOULD 6.1.13
Extensibility without requiring modifications to
protocol MUST 6.1.14
Easily extensible to support intra-area,
inter-area, inter-AS intra provider, inter-AS
inter-provider, multi-layer path & virtual
network topology path computation MUST 6.1.14
Easily extensible to support future applications
not in scope (e.g., point-to-multipoint path
computations) SHOULD 6.1.14
Scale at least linearly with number of PCCs,
PCEs, PCCs communicating with single PCE, PCEs
communicated to by single PCC, domains, path
requests, handling bursts of requests MUST 6.1.15
Support path computation constraints MUST 6.1.16
Support "unsynchronized" & "synchronized"
objective functions MUST 6.1.17
Support different service provider environments
(e.g., MPLS-TE and GMPLS networks, centralized
& distributed PCE path computation, single &
multiple PCE path computation) MUST 6.2.1
Policy support for policies to accept/reject
requests, PCC to determine reason for
rejection, notification of policy violation MUST 6.2.2
Aliveness detection of PCCs/PCEs, PCECP failure
detection MUST 6.3.1
Protocol recovery support resynchronization of
information & requests between sender &
receiver MUST 6.3.2
Minimize repeat data transfer, allow PCE to
respond to computation requests issued before
failure without requests being re-issued SHOULD 6.3.2
Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD 6.3.2
Allow indicating if computation is for LSP
restoration (support inclusion of previously
computed path & failed element) MUST 6.3.3
Support path reoptimization & inclusion of a
previously computed path MUST 6.3.3
7. Security Considerations 7. Security Considerations
The impact of the use of a PCECP MUST be considered in the light of The impact of the use of a PCECP MUST be considered in the light of
the impact that it has on the security of the existing routing and the impact that it has on the security of the existing routing and
signaling protocols and techniques in use within the network. signaling protocols and techniques in use within the network.
Intra-domain security is impacted since there is a new interface, Intra-domain security is impacted since there is a new interface,
protocol and element in the network. Any host in the network could protocol and element in the network. Any host in the network could
impersonate a PCC, and receive detailed information on network paths. impersonate a PCC, and receive detailed information on network paths.
Any host could also impersonate a PCE, both gathering information Any host could also impersonate a PCE, both gathering information
about the network before passing the request on to a real PCE, and about the network before passing the request on to a real PCE, and
spoofing responses. Some protection here depends on the PCE spoofing responses. Some protection here depends on the security of
discovery process (if it uses the IGP it relies on IGP security). An the PCE discovery process (see [PCE-DISC-REQ]). An increase in
increase in inter-domain information flows may increase the inter-domain information flows may increase the vulnerability to
vulnerability to security attacks, and the facilitation of security attacks, and the facilitation of inter-domain paths may
inter-domain path may increase the impact of these security attacks. increase the impact of these security attacks.
Of particular relevance are the implications for confidentiality Of particular relevance are the implications for confidentiality
inherent in a PCECP for multi-domain networks. It is not necessarily inherent in a PCECP for multi-domain networks. It is not necessarily
the case that a multi-domain PCE solution will compromise security, the case that a multi-domain PCE solution will compromise security,
but solutions MUST examine their impacts in this area. but solutions MUST examine their impacts in this area.
Applicability statements for particular combinations of signaling, Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain routing and path computation techniques are expected to contain
detailed security sections. detailed security sections.
It should be observed that the use of an external PCE does introduce It should be observed that the use of an external PCE introduces
additional security issues. Most notable amongst these are: additional security issues. Most notable amongst these are:
- interception of PCE requests or responses - interception of PCE requests or responses
- impersonation of PCE or PCC - impersonation of PCE or PCC
- denial of service attacks on PCE or PCE communication mechanisms - DoS attacks on PCEs or PCCs
It is expected that the PCECP will address these issues in detail The PCECP MUST address these issues in detail using authentication,
using authentication, encryption and DoS protection techniques. See encryption and DoS protection techniques. See also Section 6.1.9.
also Section 6.1.9.
8. Manageability Considerations 8. Manageability Considerations
Manageability of the PCECP MUST address the following considerations: Manageability of the PCECP MUST address the following considerations:
- need for a MIB module for control and monitoring - the need for a MIB module for control and monitoring of PCECP
- need for built-in diagnostic tools (e.g., partner failure - the need for built-in diagnostic tools to test the operation of the
detection, OAM, etc.) protocol (e.g., partner failure detection, OAM, etc.)
- configuration implications for the protocol - configuration implications for the protocol
It is expected that PCECP operations will be modeled and controlled PCECP operations MUST be modeled and controlled through appropriate
through appropriate MIB modules. Statistics gathering will form an MIB modules. Statistics gathering will form an important part of the
important part of the operation of the PCECP. The operator must be operation of the PCECP. The operator MUST be able to determine PCECP
able to determine PCECP historical interactions and success rate of historical interactions and the success rate of requests using data
requests. Similarly, it is important for an operator to be able to from MIB modules. Similarly, it is important for an operator to be
determine PCECP load and whether an individual PCC is responsible for able to determine PCECP and PCE load and whether an individual PCC is
a disproportionate amount of the load. It will also be important to responsible for a disproportionate amount of the load. It MUST be
be able to record and inspect statistics about the PCECP possible, through use of MIB modules, to record and inspect
communications, including issues such as malformed messages, statistics about the PCECP communications, including issues such as
unauthorized messages and messages discarded owing to congestion. malformed messages, unauthorized messages and messages discarded
owing to congestion.
The new MIB modules should also be used to provide notifications The new MIB modules should also be used to provide notifications
(traps) when thresholds are crossed or when important events occur. (traps) when thresholds are crossed or when important events occur.
PCECP techniques must enable a PCC to determine the liveness of a PCE 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 both before it sends a request and in the period between sending a
request and receiving a response. request and receiving a response.
It is also important for a PCE to know about the liveness of PCCs to 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, 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. and to allow a PCE to abandon processing of a received request.
It should be possible for an operator to rate limit the requests that The PCECP MUST support indication of congestion state and rate
a PCC sends to a PCE, and a PCE should be able to report impending limitation state, and MAY allow the operator to control such a
congestion (according to a configured threshold) both to the operator function.
and to its PCCs.
9. IANA Considerations 9. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
10. Acknowledgements 10. Acknowledgements
The authors would like to extend their warmest thanks to (in The authors would like to extend their warmest thanks to (in
alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri
Papadimitriou, and JP Vasseur for their review and suggestions. Papadimitriou, and JP Vasseur for their review and suggestions.
11. Normative References 11. Normative References
[PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation
Element (PCE) Architecture", work in progress. Element (PCE) Architecture", work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
12. Informational References 12. Informational References
[METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol [METRIC] Le Faucheur, F., et. al., "Use of Interior Gateway Protocol
(IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP
87, RFC 3785, May 2004. 87, RFC 3785, May 2004.
[PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path
Computation Element (PCE) Discovery," work in progress. Computation Element (PCE) Discovery," work in progress.
[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001. Tunnels," RFC 3209, December 2001.
[PCE-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol
(PCECP) specific requirements for Inter-Area (G)MPLS Traffic
Engineering," work in progress.
[PCE-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication
Requirements for Inter-Layer Traffic Engineering," work in progress.
13. Authors' & Contributors' Addresses 13. Authors' & Contributors' Addresses
Jerry Ash (Editor) Jerry Ash (Editor)
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578 Phone: (732)-420-4578
Email: gash@att.com Email: gash@att.com
Jean-Louis Le Roux (Editor) Jean-Louis Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE 22307 Lannion Cedex, FRANCE
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Alia K. Atlas Alia K. Atlas
Google Inc. Google Inc.
skipping to change at page 20, line 47 skipping to change at page 19, line 54
Email: nabil.bitar@verizon.com Email: nabil.bitar@verizon.com
Igor Bryskin Igor Bryskin
Independent Consultant Independent Consultant
Email: i_bryskin@yahoo.com Email: i_bryskin@yahoo.com
Dean Cheng Dean Cheng
Cisco Systems Inc. Cisco Systems Inc.
3700 Cisco Way 3700 Cisco Way
San Jose CA 95134 USA San Jose CA 95134 USA
Phone: +1 408 527 0677 Phone: 408 527 0677
Email: dcheng@cisco.com Email: dcheng@cisco.com
Durga Gangisetti Durga Gangisetti
MCI MCI
Email: durga.gangisetti@mci.com Email: durga.gangisetti@mci.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
Iidabashi, Chiyoda-ku, Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103 Phone: 3-6678-3103
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
Eiji Oki Eiji Oki
NTT NTT
Midori-cho 3-9-11 Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Raymond Zhang Raymond Zhang
BT INFONET Services Corporation BT INFONET Services Corporation
skipping to change at page 22, line 7 skipping to change at page 21, line 17
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
 End of changes. 92 change blocks. 
464 lines changed or deleted 427 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/