draft-ietf-pce-comm-protocol-gen-reqs-01.txt   draft-ietf-pce-comm-protocol-gen-reqs-02.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: January 2006 J.L. Le Roux (France Telecom) Expires: March 2006 J.L. Le Roux (France Telecom)
Editor Editor
July 2005 September 2005
draft-ietf-pce-comm-protocol-gen-reqs-01.txt draft-ietf-pce-comm-protocol-gen-reqs-02.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 36 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 November 26, 2005. This Internet-Draft will expire on March 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 (PCEP) . . . . . . . . . . 4 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 4
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5
6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 7
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 7
6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 7
6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 7
6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8
6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9
6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 9
6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 9
6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 10
6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11
6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 11 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 11
6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 11
6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 11
6.1.13 Communication Overhead Minimization . . . . . . . . . 12 6.1.13 Communication Overhead Minimization . . . . . . . . . 12
6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 12 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 12
6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13
6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13
6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14
6.2.1 Support for Different Service Provider Environments . . 14 6.2.1 Support for Different Service Provider Environments . . 14
6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14
6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 14 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 15
6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 14 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 15
6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 15 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 15
6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 16 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 17
12. Informational References . . . . . . . . . . . . . . . . . . . . 17 12. Informational References . . . . . . . . . . . . . . . . . . . . 17
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property Statement . . . . . . . . . . . . . . . . . . 18 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 19
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 18 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 19
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 19 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 20
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 (PCEP) 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 (Avici) Alia Atlas (Google, Inc.)
Arthi Ayyangar (Juniper) Arthi Ayyangar (Juniper)
Nabil Bitar (Verizon) Nabil Bitar (Verizon)
Igor Bryskin (Independent Consultant) Igor Bryskin (Independent Consultant)
Dean Cheng (Cisco) Dean Cheng (Cisco)
Durga Gangisetti (MCI) Durga Gangisetti (MCI)
Kenji Kumaki (KDDI) Kenji Kumaki (KDDI)
Jean-Louis Le Roux (France Telecom) Jean-Louis Le Roux (France Telecom)
Eiji Oki (NTT) Eiji Oki (NTT)
Raymond Zhang (BT Infonet) Raymond Zhang (BT Infonet)
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Introduction 3. Introduction
The 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]. The PCE operates on a network graph in order to
compute paths based on the path computation request issued by the compute paths based on the path computation request issued by the
PCC. The path computation request will normally include the source PCC. The path computation request will normally include the source
and destination of the paths to be computed, and a set of constraints and destination of the paths to be computed, and a set of constraints
to be applied during the computation. The PCE response includes the to be applied during the computation. The PCE response includes the
computed paths or the reason for a failed computation. computed paths or the reason for a failed computation.
This document lists a set of generic requirements for the PCEP. This document lists a set of generic requirements for the PCE
Application-specific requirements are beyond the scope of this Communication Protocol (PCECP). Application-specific requirements
document, and will be addressed in separate documents. are beyond the scope of this document, and will be addressed in
separate documents.
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 Multiprotocol Label Switching GMPLS: Generalized Multi-Protocol Label Switching
LSP: MPLS Label Switched Path. LSP: MPLS Label Switched Path.
MPLS: multiprotocol 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 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 (PCEP) 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 the PCC and PCE are not composite, a request/response If the PCC and PCE are not composite, a request/response
communication protocol is required to carry the request and return communication protocol is required to carry the request and return
the response. If the PCC and PCE are composite, a communication the response. If the PCC and PCE are composite, a communication
protocol is not required, but implementations may choose to utilize protocol is not required, but implementations may choose to utilize
a protocol for exchanges between the components. a protocol for 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 PCEP. scope for the PCECP.
A path computation request issued by the PCC includes a specification A path computation request issued by the PCC includes a specification
of the path(s) needed. The information supplied includes, at a of the path(s) needed. The information supplied includes, at a
minimum, the source and destination for the paths, but may also minimum, the source and destination for the paths, but may also
include a set of further requirements (known as constraints) as include a set of further requirements (known as constraints) as
described in Section 6. described in Section 6.
The response from the PCE may be positive in which case it will The response from the PCE may be positive in which case it will
include the paths that have been computed. If the computation fails include the paths that have been computed. If the computation fails
or cannot be performed, a negative response is required with an or cannot be performed, a negative response is required with an
skipping to change at page 5, line 16 skipping to change at page 5, line 17
A request/response protocol is also required for a PCE to communicate A request/response protocol is also required for a PCE to communicate
path computation requests to another PCE and for that PCE to return path computation requests to another PCE and for that PCE to return
the path computation response. As described in [PCE-ARCH], there is the path computation response. As described in [PCE-ARCH], there is
no reason to assume that two different protocols are needed, and this no reason to assume that two different protocols are needed, and this
document assumes that a single protocol will satisfy all requirements document assumes that a single protocol will satisfy all requirements
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 PCEP 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] except the applicable to all models described in the [PCE-ARCH].
composite PCE model.
6. PCE Communication Protocol Generic Requirements 6. PCE Communication Protocol Generic Requirements
[This paragraph to be deleted after successful completion and before
publication as an RFC.]
The designers of a PCEP MUST take the requirements set out in this
document and discuss them widely within the IETF and particularly
within the Applications Area to determine whether a suitable protocol
already exists. The results of this investigation MUST be published
on the PCE mailing list.
The following is a summary of the requirements in Section 6: The following is a summary of the requirements in Section 6:
Requirement Necessity Ref. Requirement Necessity Ref.
------------------------------------------------------------------ ------------------------------------------------------------------
Commonality of PCC-PCE and PCE-PCE Communication MUST 6.1.1 Commonality of PCC-PCE and PCE-PCE communication MUST 6.1.1
Client-Server Communication MUST 6.1.2 Client-server communication MUST 6.1.2
Support PCC/PCE request message to request path Support PCC/PCE request message to request path
computation MUST 6.1.2 computation MUST 6.1.2
Support PCE response message with computed path MUST 6.1.2 Support PCE response message with computed path MUST 6.1.2
Support unsolicited communication PCE-PCC SHOULD 6.1.2 Support unsolicited communication PCE-PCC SHOULD 6.1.2
Maintain PCC-PCE session NON-RQMT 6.1.2 Maintain PCC-PCE session NON-RQMT 6.1.2
Use of Existing Transport Protocol MAY 6.1.3 Use of existing transport protocol MAY 6.1.3
Transport protocol satisfy reliability & security Transport protocol satisfy reliability & security
requirements MAY 6.1.3 requirements MAY 6.1.3
Transport Protocol Limits Size of Message MUST NOT 6.1.3 Transport protocol limits size of message MUST NOT 6.1.3
Support Path Computation Requests MUST 6.1.4 Support path computation requests MUST 6.1.4
Include source & destination include source & destination
Support path constraints (e.g., bandwidth, hops, support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude MUST 6.1.4 affinities) to include/exclude MUST 6.1.4
Support path reoptimization & inclusion of a Support path reoptimization & inclusion of a
previously computed path MUST 6.1.4 previously computed path MUST 6.1.4
Allow to select/prefer from advertised list of Allow to select/prefer from advertised list of
standard objective functions/options MUST 6.1.4 standard objective functions/options MUST 6.1.4
Allow to customize objective function/options MUST 6.1.4 Allow to customize objective function/options MUST 6.1.4
Request a less-constrained path MAY 6.1.4 Support path computation responses MUST 6.1.5
Support request for less-constrained path,
including constraint-relaxation policy's SHOULD 6.1.4
Support Path Computation Responses MUST 6.1.5
Negative response support reasons for failure, Negative response support reasons for failure,
constraints to relax to achieve positive result, constraints to relax to achieve positive result SHOULD 6.1.5
less-constrained path reflecting Cancellation of pending requests MUST 6.1.6
constraint-relaxation policy's SHOULD 6.1.5 Multiple requests and responses MUST 6.1.7
Cancellation of Pending Requests MUST 6.1.6
Multiple Requests and Responses MUST 6.1.7
Limit by configuration number of requests within Limit by configuration number of requests within
a message MUST 6.1.7 a message MUST 6.1.7
Support multiple computed paths in response MUST 6.1.7 Support multiple computed paths in response MUST 6.1.7
Support "continuation correlation" where related Support "continuation correlation" where related
requests or computed paths cannot fit within one requests or computed paths cannot fit within one
message MUST 6.1.7 message MUST 6.1.7
Maximum message size & maximum number of requests Maximum message size & maximum number of requests
per message exchanged through PCE messages to PCC, per message exchanged through PCE messages to PCC,
or indicated in request message MAY 6.1.7 or indicated in request message MAY 6.1.7
Reliable Message Exchange (achieved by PCEP Reliable message exchange (achieved by PCECP
itself or transport protocol MUST 6.1.8 itself or transport protocol MUST 6.1.8
Allow detection & recovery of lost messages to Allow detection & recovery of lost messages to
occur quickly & not impede operation of PCEP MUST 6.1.8 occur quickly & not impede operation of PCECP MUST 6.1.8
Handle overload situations without significant Handle overload situations without significant
decrease in performance, e.g., through throttling decrease in performance, e.g., through throttling
of requests MUST 6.1.8 of requests MUST 6.1.8
Provide acknowledged message delivery with Provide acknowledged message delivery with
retransmission, in order message delivery or retransmission, in order message delivery or
facility to restore order, message corruption facility to restore order, message corruption
detection, flow control & back-pressure to detection, flow control & back-pressure to
throttle requests, rapid partner failure throttle requests, rapid partner failure
detection, informed rapidly of failure of PCE-PCC detection, informed rapidly of failure of PCE-PCC
connection MUST 6.1.8 connection MUST 6.1.8
Functionality added to PCEP if transport protocol Functionality added to PCECP if transport protocol
provides it SHOULD NOT 6.1.8 provides it SHOULD NOT 6.1.8
Secure Message Exchange (provided by PCEP or Secure message exchange (provided by PCECP or
transport protocol MUST 6.1.9 transport protocol MUST 6.1.9
Support mechanisms to prevent spoofing (e.g., Support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption), authentication), snooping (e.g., encryption),
DOS attacks MUST 6.1.9 DOS attacks MUST 6.1.9
Request Prioritization MUST 6.1.10 Request prioritization MUST 6.1.10
Unsolicited Notifications SHOULD 6.1.11 Unsolicited notifications SHOULD 6.1.11
Allow Asynchronous Communication MUST 6.1.12 Allow asynchronous communication MUST 6.1.12
PCC Has to Wait for Response Before Making PCC has to wait for response before making
Another Request MUST NOT 6.1.12 another request MUST NOT 6.1.12
Allow order of responses differ from order of Allow order of responses differ from order of
Requests MUST 6.1.12 requests MUST 6.1.12
Communication Overhead Minimization SHOULD 6.1.13 Communication overhead minimization SHOULD 6.1.13
Give particular attention to message size SHOULD 6.1.13 Give particular attention to message size SHOULD 6.1.13
Extensibility without requiring modifications to Extensibility without requiring modifications to
the protocol MUST 6.1.14 the protocol MUST 6.1.14
Easily extensible to support intra-area, Easily extensible to support intra-area,
inter-area, inter-AS intra provider, inter-AS inter-area, inter-AS intra provider, inter-AS
inter-provider, multi-layer path & virtual network inter-provider, multi-layer path & virtual network
topology path computation MUST 6.1.14 topology path computation MUST 6.1.14
Easily extensible to support future applications Easily extensible to support future applications
not in scope (e.g., P2MP path computations) SHOULD 6.1.14 not in scope (e.g., P2MP path computations) SHOULD 6.1.14
Scalability at least linearly with increase in Scalability at least linearly with increase in
number of PCCs, PCEs, PCCs communicating with a number of PCCs, PCEs, PCCs communicating with a
single PCE, PCEs communicated to by a single PCC, single PCE, PCEs communicated to by a single PCC,
PCEs communicated to by another PCE, domains, path PCEs communicated to by another PCE, domains, path
requests, handling bursts of requests MUST 6.1.15 requests, handling bursts of requests MUST 6.1.15
Support Path Computation Constraints MUST 6.1.16 Support path computation constraints MUST 6.1.16
Support Different Service Provider Environments Support different service provider environments
(e.g., MPLS-TE and GMPLS networks, centralized & (e.g., MPLS-TE and GMPLS networks, centralized &
distributed PCE path computation, single & distributed PCE path computation, single &
multiple PCE path computation) MUST 6.2.1 multiple PCE path computation) MUST 6.2.1
Policy Support for policies to accept/reject Policy support for policies to accept/reject
requests, PCC to determine reason for rejection, requests, PCC to determine reason for rejection,
notification of policy violation MUST 6.2.2 notification of policy violation MUST 6.2.2
Aliveness Detection of PCCs/PCEs, partner failure Aliveness detection of PCCs/PCEs, partner failure
Detection MUST 6.3.1 detection MUST 6.3.1
PCC/PCE Failure Response procedures defined for PCC/PCE failure response procedures defined for
PCE/PCC failures, PCC able to clear pending PCE/PCC failures, PCC able to clear pending
Request MUST 6.3.2 request must 6.3.2
PCC select another PCE upon detection of PCE PCC select another PCE upon detection of PCE
failure MUST 6.3.2 failure MUST 6.3.2
PCE able to clear pending requests from a PCC PCE able to clear pending requests from a PCC
(e.g. when it detects PCC failure or request (e.g. when it detects PCC failure or request
buffer full) MUST 6.3.2 buffer full) must 6.3.2
Protocol Recovery support resynchronization of Protocol recovery support resynchronization of
information & requests between sender & receiver MUST 6.3.3 information & requests between sender & receiver MUST 6.3.3
Minimize repeat data transfer, allow PCE to Minimize repeat data transfer, allow PCE to
respond to computation requests issued before respond to computation requests issued before
failure without requests being re-issued SHOULD 6.3.3 failure without requests being re-issued SHOULD 6.3.3
Stateful PCE able to resynchronize/recover Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD 6.3.3 states (e.g., LSP status, paths) after restart SHOULD 6.3.3
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.
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 and PCE-PCE communication is by nature client-server based.
The PCEP MUST allow for a PCC or a PCE to send a request message to a The PCECP MUST allow for a PCC or a PCE to send a request message to
PCE to request path computation, and for a PCE to reply with a a PCE to request path computation, and for a PCE to reply with a
response message to the requesting PCC or PCE, once the path has been response message to the requesting PCC or PCE, 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 may be cases where
there is unsolicited communication from the PCE to PCC (see there is unsolicited communication from the PCE to PCC (see
Requirement 6.1.6). Requirement 6.1.6).
There is no requirement to maintain a session or association between
communicating PCC and PCE, nor between communicating PCEs. The
request/response exchange defines a limited association between
requester and responder.
6.1.3 Transport 6.1.3 Transport
The PCEP 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).
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 PCEP. message used by the PCECP.
Where requirements expressed in this document match the function of Where requirements expressed in this document match the function of
existing transport protocols, consideration MUST be given to the use existing transport protocols, consideration MUST be given to the use
of those protocols. 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 request message MUST include, at least, a source and a
destination. The message MUST support the inclusion of a set of one destination. However, there is no assumption that the receiving PCE
or more path constraints, such as the requested bandwidth or has the complete source/destination domain topology, particularly in
resources (hops, affinities, etc.) to include/exclude (e.g., a PCC the multiple PCE path computation model [PCE-ARCH]. In the latter
requests the PCE to exclude points of failure in the computation of case, the PCE may have incomplete topological information for
the new path if an LSP setup fails). The actual inclusion of multiple domains.
constraints is a choice for the PCC issuing the request.
A list of core constraints that MUST be supported by the PCEP is The message MUST support the inclusion of a set of one or more path
supplied in Section 6.1.16. Specification of constraints must be constraints, including the requested bandwidth or resources (hops,
future-proofed as described in Section 6.1.14. affinities, etc.) to include/exclude (e.g., a PCC requests the PCE to
exclude points of failure in the computation of the 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 6.1.16.
Specification of constraints must be future-proofed as described in
Section 6.1.14.
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.
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. The requester SHOULD also be able to select a options. An objective function is used by the PCE to compute a path
vendor-specific or experimental objective function or functional metric in order to select the best candidate paths (e.g., minimum hop
option. Furthermore, the requester MUST be allowed to customize the path), and corresponds to the optimization criteria used for the
objective function/options in use. That is, individual objective computation of one path, or the synchronized computation of a set of
functions will often have parameters to be set in the request from paths. In case of unsynchronized path computation, this can be, for
PCC to PCE. Specification of objective functions and objective example, the path cost or the residual bandwidth on the most loaded
function parameters is required in the protocol extensibility path link. In case of synchronized path computation, this can be,
specified in Section 6.1.14. for example, the global bandwidth consumption or the residual
bandwidth on the most loaded network link.
If a PCC selects an objective function that the PCE does not support, The requester SHOULD also be able to select a vendor-specific or
the PCE response MUST be negative. 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. Specification
of objective functions and objective parameters is 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 Note that a PCC MAY send a request that is based on the set of TE
parameters carried by the MPLS/GMPLS LSP setup signaling protocol, parameters carried by the MPLS/GMPLS LSP setup signaling protocol,
and as long as those parameters are satisfied, the PCC MAY not care and as long as those parameters are satisfied, the PCC MAY not care
about which objective function is used. Also, the PCE MAY execute about which objective function is used. Also, the PCE MAY execute
objective functions not advertised to the PCC, for example, policy additional objective functions not explicitly requested by the PCC.
based routing path computation for load balancing instructed by the This might include policy based routing path computation for load
management plane. balancing instructed by the management plane. The PCC MUST NOT be
allowed to request or cause a computation to fail because it does not
As also discussed in Section 6.1.5 (Path Computation Responses), a wish the PCE to apply a specific objective function. Allowing such
PCC MAY request a less-constrained TE LSP path, and the path behavior would constitute a security risk.
computation request MAY include one or more constraint-relaxation
policy's. The Request message SHOULD support the inclusion of a
request for a less-constrained path, including one or more
constraint-relaxation policy's.
6.1.5 Path Computation Responses 6.1.5 Path Computation Responses
The response message MUST allow returning various elements including, The response message MUST allow returning various elements including,
at least, the computed path(s). 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. Note that the 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 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 will include the paths that have
been computed. When a Path satisfying the constraints cannot be been computed. When a path satisfying the constraints cannot be
found, or if the computation fails or cannot be performed, a found, or if the computation fails or cannot be performed, a
negative response MUST be sent. This response MAY include further negative response MUST be sent. This response MAY include further
details of the reason(s) for the failure, and potentially advice details of the reason(s) for the failure, and potentially advice
about which constraints might be relaxed to be more likely to achieve about which constraints might be relaxed to be more likely to achieve
a positive result. Optionally the PCE MAY provide a a positive result.
less-constrained path taking into account one or more relaxation
policy's that could potentially be provided by the PCC in the
request. As discussed in Section 6.1.4, a PCC MAY optionally
request a less-constrained TE LSP path, and the path computation
request MAY also include one or more constraint-relaxation policy's.
Hence the Response message SHOULD support the inclusion of the
reasons for a failure, and the inclusion of less-constrained path.
The Request message SHOULD support the inclusion of a request for a
less-constrained path, including one or more constraint-relaxation
policy's.
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. A PCC or PCE MUST be able to cancel a pending request, using an
appropriate notification between PCECP peers. A PCC that has sent a
request to a PCE and no longer needs a response, for instance,
because it received a satisfactory answer from another PCE, MUST be
able to notify the PCE that it must clear the request (i.e. stop the
computation, if already started, and clear the context). Similarly,
a PCE that received a request from a PCC that it cannot serve, for
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 correlated or not, within the same request message. There are
various motivations for doing so (optimality, path diversity, etc.). various motivations for doing so (optimality, path diversity, etc.).
It MUST be possible to limit by configuration the number of requests It MUST be possible to limit by configuration of both PCCs and PCEs
that can be carried within a single message. 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. load balancing) or to distinct requests, correlated or
not, of the same request message or distinct request messages. 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.
Maximum acceptable message sizes and the maximum number of requests Maximum acceptable message sizes and the maximum number of requests
skipping to change at page 11, line 7 skipping to change at page 10, line 31
Maximum acceptable message sizes and the maximum number of computed Maximum acceptable message sizes and the maximum number of computed
paths per message supported by a PCC MAY be indicated in the request paths per message supported by a PCC MAY be indicated in the request
message. message.
An implementation MAY choose to limit message size to avoid a big An implementation MAY choose to limit message size to avoid a big
message from unduly delaying a small message. message from unduly delaying a small message.
6.1.8 Reliable Message Exchange 6.1.8 Reliable Message Exchange
The PCEP 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 PCEP. 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 PCEP or the transport protocol it uses saturation of the PCEs. The PCECP or the transport protocol it uses
MUST properly handle such overload situations without a significant MUST properly handle such overload situations, such as through
decrease in performance, such as through throttling of such requests. throttling of requests. For example, a PCE MUST be able to limit the
rate of incoming request messages to a manageable rate by notifying
PCCs and/or peering PCEs.
The PCEP or the transport protocol it uses MUST provide: The PCECP or the transport protocol it uses MUST provide:
- Acknowledged message delivery with retransmission. - Acknowledged message delivery with retransmission.
- In order message delivery or the facility (such as message - In order message delivery or the facility (such as message
numbering) to restore the order of received messages. numbering) to restore the order of received messages.
- Message corruption detection. - Message corruption detection.
- Flow control and back-pressure, as specified above with the - Flow control and back-pressure, as specified above with the
throttling of requests. throttling of requests.
- Rapid partner failure detection. The PCC/PCE MUST be informed of - Rapid partner failure detection.
the failure of any PCE/PCC or PCC-PCE connection rapidly after
the failure happens.
Functionality SHOULD NOT be added to the PCEP where the chosen - Rapid PCE/PCC or PCC-PCE connection failure detection after
transport protocol already provides it. failure happens.
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 SHOULD NOT be added
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 MUST be secure. In particular, The PCC-PCE and PCE-PCE communication protocol MUST include
it MUST support mechanisms to prevent spoofing (e.g., provisions to improve the security of the exchanges between the
authentication), snooping (e.g., encryption) and DOS attacks. entities. In particular, it MUST support mechanisms to prevent
spoofing (e.g., authentication), snooping (e.g., encryption) and DOS
attacks (e.g., 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 PCEP. by the PCECP.
See Section 7 for further discussion of security considerations.
6.1.10 Request Prioritization 6.1.10 Request Prioritization
The PCEP 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 is used by a PCE to service high priority request. This priority MAY be used by a PCE to service high priority
requests before lower priority requests considering all requests requests before lower priority requests considering all requests
received and queued by a single PCE from all PCCs. 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 PCEP. 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 PCEP SHOULD support unsolicited notifications from PCE to PCC, The PCECP SHOULD support unsolicited notifications from PCE to PCC,
PCE to PCE, or PCC to PCE. This requirement facilitates the PCE to PCE, or PCC to PCE. This requirement facilitates the
unsolicited communication of information, updated paths, and alerts unsolicited communication of information and alerts between PCCs and
between PCCs and PCEs and between 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 before it can make another
request. 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).
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. Particular attention SHOULD be communication overhead is minimized. In particular, the overhead per
given to the message size. Other considerations in overhead message should be minimized, and the number of bytes exchanged to
minimization include the following: arrive at a computation answer should be minimized. Note that
compression techniques are not required. Other considerations in
overhead minimization include the following:
- the number of messages exchanged to arrive at a computation answer
- the amount of background messages used by the protocol or its - the amount 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 PCEP 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. modifications in the protocol.
The PCEP 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
- 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
The PCEP MUST also allow extensions as more PCE applications will be
The PCECP MUST also allow extensions as more PCE applications will be
introduced in the future. For example, the protocol may be extended introduced in the future. For example, the protocol may be extended
to support PCE-based multi-layer path computation and virtual network to support PCE-based multi-layer path computation and virtual network
topology computation/reconfiguration. topology computation/reconfiguration.
The PCEP SHOULD also be easily extensible to support future The PCECP SHOULD also be easily extensible to support future
applications not currently in the scope of the PCE working group, applications not currently in the scope of the PCE working group,
such as, for instance, P2MP path computations, etc. such as, for instance, P2MP path computations, multi-hop pseudowire
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 PCEP 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: increase of any of the following parameters (note, minimum order of
magnitude estimates of what the PCECP should support are given in
parenthesis):
- number of PCCs - number of PCCs (1000/domain)
- number of PCEs - number of PCEs (100/domain)
- number of PCCs communicating with a single PCE - number of PCCs communicating with a single PCE (1000)
- number of PCEs communicated to by a single PCC - number of PCEs communicated to by a single PCC (100)
- number of PCEs communicated to by another PCE - number of PCEs communicated to by another PCE (100)
- number of domains - number of domains (20)
- number of path requests - number of path request messages (average of 10/second/PCE)
- handling bursts of requests. - 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 path request messages/second may correspond to 100 path
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. It is RECOMMENDED that
the protocol handle the congestion in a graceful way so that it does the protocol handle the congestion in a graceful way so that it does
not unduly impact the rest of the network, and so that it does not not unduly impact the rest of the network, and so that it does not
gate the ability of the PCE to perform computation. gate the ability of 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 PCEP. 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 that 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.
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 delay metrics - Maximum end-to-end delay metrics
- Hop Count - Hop Count
- Maximum end-to-end TE metric (cost)
- Multiple disjoint path computation to allow path protection
o MPLS-TE specific constraints o MPLS-TE specific constraints
- Class-Type - Class-type
- Local protection
- Node protection
- Bandwidth protection
o GMPLS specific constraints o GMPLS specific constraints
- Switching Type, Encoding Type - Switching type, encoding type
- Protection type - Link protection type
o TBD 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.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 PCEP 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, such as environments that utilize an IP-based control plane, including
- MPLS-TE and GMPLS networks - MPLS-TE and GMPLS 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 PCEP MUST allow for policies to accept/reject requests, and The PCECP MUST allow for policies to accept/reject requests, and
include the ability for a PCE to reject requests with sufficient include the ability for a PCE to reject requests with sufficient
detail to allow the PCC to determine the reason for rejection or detail to allow the PCC to determine the reason for rejection or
failure. For example, filtering could be required for intra-AS PCE failure. For example, filtering could be required for intra-AS PCE
path computation such that all requests are rejected that come from path computation such that all requests are rejected that come from
another AS. However, specific policy details are left to another AS. However, specific policy details are left to
application-specific PCEP requirements. Furthermore, the PCEP MUST application-specific PCECP requirements. Furthermore, the PCECP MUST
allow for the notification of a policy violation. Actual policies, allow for the notification of a policy violation. 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
requirements/implications is being undertaken as a separate work item
in the PCE working group.
6.3 Detection & Recovery Requirements 6.3 Detection & Recovery Requirements
6.3.1 Aliveness Detection 6.3.1 Aliveness Detection
The PCEP MUST allow a PCC to check the liveliness of PCEs it is using The PCECP MUST allow a PCC to check the liveliness of PCEs it is
for path computation, and a PCE to check the liveliness of PCCs it is using for path computation, and a PCE to check the liveliness of
serving. The PCEP MUST provide partner failure detection. PCCs it is serving. This includes detection of PCE liveness before a
PCE is used for computation. i.e. during PCE selection. A PCC should
be aware of PCE liveness at all times. The PCECP MUST provide
partner failure detection.
Depending on the solution, this requirement MAY be met by the PCEP The aliveness detection mechanism MUST ensure reciprocal knowledge of
design or the transport protocol design. PCE and PCC liveness.
Note that the PCE or PCC software component can be lost without
losing the connection or the transport end-point, when a transport
protocol is used.
6.3.2 PCC/PCE Failure Response 6.3.2 PCC/PCE Failure Response
Appropriate PCC and PCE procedures MUST be defined to deal with PCE 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 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 a PCE so that it is no longer waiting for a response. Clearing a
pending request does not imply any message exchange; this differs pending request does not imply any message exchange; this differs
from pending request cancellation (Section 6.1.6), which requires from pending request cancellation (Section 6.1.6), which requires
message exchange. It is RECOMMENDED that a PCC select another PCE message exchange. It is RECOMMENDED that a PCC select another PCE
upon detection of PCE failure or unreachability of a PCE but note upon detection of PCE failure or unreachability of a PCE but note
that PCE selection procedure are out of the scope of this document. 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, 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 for instance, when it detects the failure of the requesting PCC or
when its buffer of requests is full. Clearing a pending request does when its buffer of requests is full. Clearing a pending request does
not imply any message exchange. not imply any message exchange.
It is assumed that the aliveness detection mechanism (see Section
6.3.1) ensures reciprocal knowledge of PCE and PCC liveness.
6.3.3 Protocol Recovery 6.3.3 Protocol Recovery
Information distributed in asynchronous/unsolicited messages MAY Information distributed in asynchronous/unsolicited messages MAY
persist at the recipient in the event of the failure of the sender or persist at the recipient in the event of the failure of the sender or
of the communication channel. Upon recovery, the Communication of the communication channel. Upon recovery, the Communication
Protocol MUST support resynchronization of information and requests Protocol MUST support resynchronization of information and requests
between the sender and the receiver, and this SHOULD be arranged so between the sender and the receiver, and this SHOULD be arranged so
as to minimize repeat data transfer. as to minimize repeat data transfer.
For example, the PCEP SHOULD allow a PCE to respond to computation The response to a computation request issued before the PCC is
requests issued before the failure without the requests being restarted will not be helpful and could be a waste of effort. Thus
re-issued. 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.
Similarly, a stateful PCE SHOULD be able to resynchronize and recover The PCECP SHOULD allow a PCE to respond to computation requests
states (e.g., LSP status, paths, etc.) after a restart. issued before the failure without the requests being re-issued.
7. Security Considerations 7. Security Considerations
The impact of the use of a PCEP 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. There signaling protocols and techniques in use within the network.
is unlikely to be any impact on intra-domain security, but an Intra-domain security is impacted since there is a new interface,
increase in inter-domain information flows and the facilitation of protocol and element in the network. Any host in the network could
inter-domain path establishment may increase the vulnerability to impersonate a PCC, and receive detailed information on network paths.
security attacks. Any host could also impersonate a PCE, both gathering information
about the network before passing the request on to a real PCE, and
spoofing responses. Some protection here depends on the PCE
discovery process (if it uses the IGP it relies on IGP security). An
increase in inter-domain information flows may increase the
vulnerability to security attacks, and the facilitation of
inter-domain path may 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 PCEP 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 does introduce
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 - impersonation of PCE or PCC
- falsification of TE information
- denial of service attacks on PCE or PCE communication mechanisms - denial of service attacks on PCE or PCE communication mechanisms
It is expected that the PCEP will address these issues in detail It is expected that the PCECP will address these issues in detail
using authentication and security techniques. See also Section using authentication, encryption and DoS protection techniques. See
6.1.9. also Section 6.1.9.
8. Manageability Considerations 8. Manageability Considerations
Manageability of the PCEP MUST address the following considerations: Manageability of the PCECP MUST address the following considerations:
- need for a MIB module for control and monitoring - need for a MIB module for control and monitoring
- need for built-in diagnostic tools (e.g., partner failure - need for built-in diagnostic tools (e.g., partner failure
detection, OAM, etc.) detection, OAM, etc.)
- configuration implications for the protocol - configuration implications for the protocol
It is expected that PCECP operations will be modeled and controlled
through appropriate MIB modules. Statistics gathering will form an
important part of the operation of the PCECP. The operator must be
able to determine PCECP historical interactions and success rate of
requests. Similarly, it is important for an operator to be able to
determine PCECP load and whether an individual PCC is responsible for
a disproportionate amount of the load. It will also be important to
be able to record and inspect statistics about the PCECP
communications, including issues such as malformed messages,
unauthorized messages and messages discarded owing to congestion.
The new MIB modules should also be used to provide notifications
(traps) when thresholds are crossed or when important events occur.
PCECP techniques must enable a PCC to determine the liveness of a PCE
both before it sends a request and in the period between sending a
request and receiving a response.
It is also important for a PCE to know about the liveness of PCCs to
gain a predictive view of the likely loading of a PCE in the future,
and to allow a PCE to abandon processing of a received request.
It should be possible for an operator to rate limit the requests that
a PCC sends to a PCE, and a PCE should be able to report impending
congestion (according to a configured threshold) both to the operator
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) Adrian Farrel, Thomas Morin, and JP Vasseur for alphabetical order) Lou Berger, Adrian Farrel, Thomas Morin, Dimitri
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 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
skipping to change at page 17, line 22 skipping to change at page 18, line 17
13. Authors' Addresses 13. Authors' Addresses
Jerry Ash Jerry Ash
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: +1-(732)-420-4578
Email: gash@att.com Email: gash@att.com
Alia K. Atlas Alia K. Atlas
Avici Systems, Inc. Google Inc.
101 Billerica Avenue 1600 Amphitheatre Parkway
N. Billerica, MA 01862, USA Mountain View, CA 94043
Phone: +1 978 964 2070 Email: akatlas@alum.mit.edu
Email: aatlas@avici.com
Arthi Ayyangar Arthi Ayyangar
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 USA Sunnyvale, CA 94089 USA
Email: arthi@juniper.net Email: arthi@juniper.net
Nabil Bitar Nabil Bitar
Verizon Verizon
40 Sylvan Road 40 Sylvan Road
 End of changes. 98 change blocks. 
222 lines changed or deleted 280 lines changed or added

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