[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-pce-comm-protocol-gen-reqs

IETF Internet Draft PCE Working Group                 Jerry Ash (AT&T)
Proposed Status: Informational                                  Editor
Expires: October 2005                    J.L. Le Roux (France Telecom)

                                                            April 2005


         PCE Communication Protocol Generic Requirements

Status of this Memo

This document is an Internet-Draft and is subject to all provisions of
Section 3 of RFC 3667.

By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.

Internet Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at


Constraint-based path computation is a fundamental building block for
traffic engineering systems such as MPLS and GMPLS networks. Path
computation in large, multi-domain or multi-layer networks is highly
complex and may require special computational components and cooperation
between the different network domains.

There are multiple components in the Path Computation Element (PCE)-
based path computation model, including PCE discovery and the PCE
communication protocol.  This document specifies generic requirements
for a PCE communication protocol.  Subsequent documents will specify
application-specific requirements for the PCE communication protocol.

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 1]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

Table of Contents

1. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . . 3
3. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Overview of PCE Communication Protocol  . . . . . . . . . . . . . 4
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5
   6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5
       6.1.1 Client-Server Communication . . . . . . . . . . . . . . 6
       6.1.2 PCC-PCE and PCE-PCE Communication . . . . . . . . . . . 6
       6.1.3 Reliable Message Exchange . . . . . . . . . . . . . . . 6
       6.1.4 Secure Message Exchange . . . . . . . . . . . . . . . . 6
       6.1.5 Request Prioritization  . . . . . . . . . . . . . . . . 6
       6.1.6 Unsolicited Notifications . . . . . . . . . . . . . . . 6
       6.1.7 Asynchronous Communication  . . . . . . . . . . . . . . 6
       6.1.8 Communication Overhead Minimization . . . . . . . . . . 7
       6.1.9 Extensibility . . . . . . . . . . . . . . . . . . . . . 7
       6.1.10 Scalability  . . . . . . . . . . . . . . . . . . . . . 7
   6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 7
       6.2.1 Support for Various Service Provider Environments and
             Applications  . . . . . . . . . . . . . . . . . . . . . 7
       6.2.2 Confidentiality . . . . . . . . . . . . . . . . . . . . 8
   6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 8
       6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 8
       6.3.2 PCC/PCE Failure Response  . . . . . . . . . . . . . . . 8
       6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Intellectual Property Considerations . . . . . . . . . . . . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 10
12. Informational References . . . . . . . . . . . . . . . . . . . . 10
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 2]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

1. Contributors

This document is the result of the PCE Working Group PCE communication
protocol requirements design team joint effort. The following are the
design team member authors that contributed to the present document:

Jerry Ash (AT&T)
Alia Atlas (Avici)
Arthi Ayyangar (Juniper)
Nabil Bitar (Verizon)
Igor Bryskin (Independent Consultant)
Dean Cheng (Cisco)
Durga Gangisetti (MCI)
Kenji Kumaki (KDDI)
Jean-Louis Le Roux (France Telecom)
Eiji Oki (NTT)
Raymond Zhang (BT Infonet)

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document are to be interpreted as described in RFC 2119 [RFC2119].

3. Introduction

[PCE-ARCH] defines an architecture where Path Computation Elements (PCE)
service path computation requests sent by Path Computation Clients
(PCCs).  This requires a communication protocol in order for PCCs to
send path computation requests to PCEs and for PCEs to reply with the
computed paths.  This document lists a set of generic requirements for
the PCE communication protocol. It is intended that protocol solutions
will satisfy these requirements.  Application-specific requirements are
beyond the scope of this document, and will be addressed in separate

4. Terminology

CSPF: Constraint-based Shortest Path First.

Domain: any collection of network elements within a common sphere of
address management or path computational responsibility.  Examples of
domains include IGP areas, Autonomous Systems (ASs), multiple ASs within
a service provider network, or multiple ASs across multiple service
provider networks.

LER: Label Edge Router.

LSDB: Link State Database.

LSP: Label Switched Path.

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 3]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

LSR: Label Switching Router.

PCC: Path Computation Client : any client application requesting a path
computation to be performed by the Path Computation Element.

PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route based
on a network graph and applying computational constraints (see further
description in [PCE-ARCH]).

TED: Traffic Engineering Database, which contains the topology and
resource information of the network or network segment used by a PCE.

TE LSP: Traffic Engineering MPLS Label Switched Path.

See [PCE-ARCH] for further definitions of terms.

5. Overview of PCE Communication Protocol

A PCE might co-locate with a PCC or reside elsewhere.  In the latter
case, a PCC would discover and select a PCE using a PCE discovery
mechanism, which is out of the scope of this document.  Requirements for
PCE discovery are documented in [PCE-DISC-REQ].  Population of the TED
used by the PCE is also out of scope of the PCE communication protocol.
Once a PCC has selected a PCE, and provided that the PCE is not local to
the PCC, a request/response protocol is required for the PCC to
communicate the path computation requests to the PCE and for the PCE to
return the path computation response.  The path computation request may
include a set of constraints, such as source, destination, bandwidth
required, etc.

In case of a positive response from the PCE, one or more paths would be
returned to the requesting node. In the event of a failure to compute
the desired path(s), an error is returned together with as much
information as possible about the reasons for the failure, and
potentially advice about which constraints might be relaxed to be more
likely to achieve a positive result.

Note that the resultant path(s) may be made up of a set of strict or
loose hops, or any combination of strict and loose hops. Moreover, a
hop may have the form of a non-explicit abstract node.  See RFC 3209 for
the definition of strict hop, loose hop, and abstract node.

A request/response protocol is also required for a PCE to communicate
path computation requests to another PCE and for the PCE to return the
path computation response.

[PCE-ARCH] describes four models of PCE: composite, external, multiple
PCE path computation and multiple PCE path computation with inter-PCE
communication.  In all cases except the composite PCE model, a

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 4]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

communication protocol is required.  The requirements defined in this
document therefore are applicable to all models described in the
[PCE-ARCH] except the composite PCE model.

6. PCE Communication Protocol Generic Requirements

6.1 Basic Protocol Requirements

6.1.1 Client-Server Communication

PCC-PCE and PCE-PCE communication is by nature client-server based.  The
communication protocol MUST allow for a PCC or a PCE to send a path
request message to a PCE, and for a PCE to reply with a path response
message to the requesting PCC or PCE, once the path has been computed.
In addition to this request-response model, there may be cases where
there is unsolicited communication from the PCE to PCC (see Requirement

The protocol MUST be capable of returning any explicit path that would
be acceptable for use in RSVP-TE for MPLS and GMPLS LSPs when suitably
encoded in an Explicit Route Object.

It MUST be possible to send multiple path computation requests,
correlated or not, within the same path request message.  There are
various motivations for doing so (optimality, path diversity, etc.).

The path request message MUST include a set of path constraints,
including, at least, a source, a destination, and one or more
constraints, such as the requested bandwidth or resources (hops,
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 path request message MUST support the ability to
prefer/customize various path computation algorithms, policies and
optimization criteria.  For example, a PCC may be aware of and would
like to choose from among various algorithms that a PCE may offer, and
the PCE communication protocol should allow this to be specified per
path computation request.  This capability to prefer certain
algorithms depends on the fact that the PCE advertises this to a PCC.
A PCC or PCE MUST be able to cancel a pending request.

The path response message MUST allow returning various elements
including, at least, the computed path.  It MUST be possible to return
multiple paths within the same path response message, corresponding
either to the same request (e.g. load balancing) or to distinct requests
of the same path request message or distinct path request messages.  It
MUST be possible to return multiple paths within the same path response
message, or to respond either to the same request or distinct requests
of a given path request message.

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 5]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

6.1.2 PCC-PCE and PCE-PCE Communication

A single protocol MUST be defined for PCC-PCE and PCE-PCE communication.
A PCE requesting a path from another PCE can be considered as a PCC.

6.1.3 Reliable Message Exchange

The PCE communication protocol MUST run on top of a reliable transport
protocol.  In particular, it MUST allow for the detection and recovery
of lost messages to occur quickly and not impede the operation of the
communication protocol.

In some particular cases (e.g. link failure), a large number of PCCs
may simultaneously send a request to a PCE, leading potentially to a
saturation of request buffers on PCEs.  The PCE communication protocol
MUST properly handle such overload situations without a significant
decrease in performance, such as through throttling of such requests.

6.1.4 Secure Message Exchange

The PCC-PCE and PCE-PCE communication MUST be secure. In particular, it
MUST support mechanisms to prevent spoofing (e.g., authentication),
Snooping (e.g., encryption) and DOS attacks.

6.1.5 Request Prioritization

The communication protocol MUST support the notion of request priority,
allowing a PCC to specify the degree of urgency of a particular request.
This is used to serve some requests before others, and would require
global prioritization.  That is, a request from one PCC can have a
higher priority than a request from another PCC to the same PCE.
However, there is no intention or need for a PCE to preempt (i.e.,
discard) a given request from one PCC if it receives a higher-priority
request from another PCC; the PCE just delays the lower-priority

6.1.6 Unsolicited Notifications

The PCE communication protocol SHOULD support unsolicited notifications
from PCE to PCC or from PCE to PCE.

6.1.7 Asynchronous Communication

The PCC-PCE protocol MUST allow for asynchronous communication.  A
client MUST NOT have to wait for a response to make another request.
Also it MUST be possible to have the order of some responses differ from
the order of their corresponding requests.  This may occur, for
instance, when path request messages have distinct priorities (see
Requirement 6.1.5).

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 6]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

6.1.8 Communication Overhead Minimization

The request and response messages SHOULD be designed so that the
communication overhead is minimized.  Particular attention SHOULD be
given to the message size.

6.1.9 Extensibility

The PCE communication protocol SHOULD provide a way for introduction of
new path computation constraints, diversity types, objective functions,
etc., without requiring modifications in the protocol.  In particular,
the PCE communication protocol SHOULD allow supporting future
applications not currently in the scope of the PCE working group, such
as, for instance, P2MP path computations.

6.1.10 Scalability

The PCE communication protocol MUST scale well with an increase of any
of the following parameters:

   - number of PCCs
   - number of PCEs
   - TED size (number of links/nodes)
   - number of domains
   - number of path requests

6.2 Deployment Support Requirements

6.2.1 Support for Various Service Provider Environments and Applications

The communication protocol MUST operate in various service provider
network environments, such as

   - MPLS-TE and GMPLS networks
   - centralized and distributed PCE path computation
   - single and multiple PCE path computation

Definitions of centralized, distributed, single, and multiple PCE path
computation can be found in [PCE-ARCH].

The communication protocol MUST allow supporting various PCE based
applications that have been currently identified, such as:

   - intra-area path computation
   - inter-area path computation
   - inter-AS intra provider and inter-AS inter-provider path
   - multi-layer and virtual network topology computation

Note that application specific requirements are out of the scope of this
document and will be addressed in separate requirements documents.

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 7]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

6.2.2 Confidentiality

The communication protocol MUST allow minimizing the amount of
topological information exchanged between a PCC and PCE, and between
PCEs.  This is of particular importance in inter-PCE communication,
where the PCEs are located in distinct service-provider domains.

6.2.3 Policy Support

The communication protocol MUST allow for policies to accept/reject
requests, and include the ability for a PCE to reject requests with
sufficient detail to allow the PCC to determine the reason for rejection
or failure.  For example, filtering could be required for intra-AS PCE
path computation such that all requests are rejected that come from
another AS.  A PCC may be aware of and would like to choose from among
various policies that a PCE may offer, and the PCE communication
protocol should allow this to be specified per path computation request.
This capability to prefer certain policies depends on the fact that the
PCE advertises this to a PCC.  Similarly, the PCE communication protocol
MUST be able to convey parameters, constraints, etc. that would control
policies in the PCE or PCC.  However, specific policy parameter details
are left to application-specific communication protocol requirements.
Furthermore, the communication protocol MUST allow for the notification
of a policy violation.  Actual policies, configuration of policies, and
applicability of policies are out of scope.

6.3 Detection & Recovery Requirements

6.3.1 Aliveness Detection

The PCE communication protocol MUST allow a PCC to check the liveliness
of PCEs it is using for path computation and a PCE to check the
liveliness of PCCs it is serving.

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.
Similarly, a PCE MUST be able to clear pending requests from a PCC when
it detects the failure of the requesting PCC.  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.

6.3.3 Protocol Recovery

The communication protocol SHOULD allow a stateful PCE to resynchronize
and recover states (e.g., LSP status, paths, etc.) after a restart.
Recovery would entail some PCC-PCE cooperation to recover state
information in the PCE, and hence communication protocol needs to

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 8]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

support that.  This would be of particular importance when local PCE
recovery is not supported or fails.

7. Security Considerations

The impact of the use of a PCE-based architecture MUST be considered in
the light of the impact that it has on the security of the existing
routing and signaling protocols and techniques in use within the
network. There is unlikely to be any impact on intra-domain security,
but an increase in inter-domain information flows and the facilitation
of inter-domain path establishment may increase the vulnerability to
security attacks.

Of particular relevance are the implications for confidentiality
inherent in a PCE-based architecture for multi-domain networks. It is
not necessarily the case that a multi-domain PCE solution will
compromise security, but solutions MUST examine their impacts in this

Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain detailed
security sections.

It should be observed that the use of a non-local PCE (that is, not
co-resident with the PCC) does introduce additional security issues.
Most notable amongst these are:

- interception of PCE requests or responses
- impersonation of PCE
- falsification of TE information
- denial of service attacks on PCE or PCE communication mechanisms

It is expected that PCE solutions will address these issues in detail
using authentication and security techniques.

8. IANA Considerations

This document makes no requests for IANA action.

9. Acknowledgements

The authors would like to extend their warmest thanks to (in
alphabetical order) Adrian Farrel, Thomas Morin, and JP Vasseur for
their review and suggestions.

10. Intellectual Property Considerations

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt>  [Page 9]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at

11. Normative References

[PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation Element
(PCE) Architecture", work in progress.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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

[PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path Computation
Element (PCE) Discovery," work in progress.

[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001.

13. Authors' Addresses

Jerry Ash
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Email: gash@att.com

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt> [Page 10]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

Alia K. Atlas
Avici Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862, USA
Phone: +1 978 964 2070
Email: aatlas@avici.com

Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089 USA
Email: arthi@juniper.net

Nabil Bitar
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com

Igor Bryskin
Independent Consultant
Email: i_bryskin@yahoo.com

Dean Cheng
Cisco Systems Inc.
3700 Cisco Way
San Jose CA 95134 USA
Phone: +1 408 527 0677
Email: dcheng@cisco.com

Durga Gangisetti
Email: durga.gangisetti@mci.com

Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com

Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
Email: jeanlouis.leroux@francetelecom.com

Eiji Oki
Midori-cho 3-9-11

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt> [Page 11]

Internet Draft  PCE Communication Protocol Generic Reqmnts   April 2005

Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp

Raymond Zhang
BT INFONET Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com

14. Full Copyright Statement

Copyright (C) The Internet Society (2005).  This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an

PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-00.txt> [Page 12]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/