IETF Internet Draft PCE Working Group Jerry Ash (AT&T)
Proposed Status: Informational Editor
Expires: August 2005
February 2005
draft-ash-pce-comm-protocol-reqs-00.txt
Path Computation Element (PCE) Communiation Protocol Requirements
Status of this Memo
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.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
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.
This document specifies the communication protocol requirements for a
Path Computation Element (PCE)-based model.
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 1]
Internet Draft PCE Communication Protocol Requirements February 2005
Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. PCE Communication Protocol Application Examples . . . . . . . . . 4
5.1. External PCE . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Multiple PCE Path Computation . . . . . . . . . . . . . . . 5
5.3. Multiple PCE Path Computation with Inter-PCE Communication . 5
6. PCE Communication Protocol Requirements . . . . . . . . . . . . . 6
7. Protocol Design Considerations. . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Intellectual Property Considerations . . . . . . . . . . . . . . 9
12. Normative References . . . . . . . . . . . . . . . . . . . . . . 10
13. Informational References . . . . . . . . . . . . . . . . . . . . 10
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12
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)
Igor Bryskin
Dean Cheng (Cisco)
Durga Gangisetti (MCI)
Kenji Kumaki (KDDI)
Jean-Louis Le Roux (France Telecom)
Eiji Oki (NTT)
Raymond Zhang (Infonet)
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
CSPF: Constraint-based Shortest Path First.
LER: Label Edge Router.
LSDB: Link State Database.
LSP: Label Switched Path.
LSR: Label Switching Router.
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 2]
Internet Draft PCE Communication Protocol Requirements February 2005
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 Section 4 and [PCE-ARCH]).
TED: Traffic Engineering Database, which contains the topology and
resource information of the domain. The TED may be fed by IGP extensions
or potentially by other means.
TE LSP: Traffic Engineering MPLS Label Switched Path.
4. Definitions
Path Computation Element (PCE): an entity that is capable of computing a
network path or route based on a network graph, and incorporating
computational constraints. The PCE entity is an application that can be
located within a network node or component, on an out-of-network server,
etc. For example, a PCE would be able to compute the path of a TE LSP by
operating on the TED and considering the bandwidth and other constraints
applicable to the TE LSP service request (see further description in
[PCE-ARCH]).
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. However, domains of computational responsibility may
also exist as sub-domains of areas or ASs.
Inter-domain path computation: may involve the correlation of topology
and routing information between domains.
Inter-layer path computation: refers to the use of PCE where multiple
layers are involved and when the objective is to perform path
computation at one or multiple layers while taking into account topology
and resource information at these layers.
Single PCE path computation: a single PCE is used to compute a given
path in a domain.
Multiple PCE path computation: multiple PCEs are used to compute a given
path in a domain.
Centralized computation model: refers to a model whereby all paths in a
domain are computed by a single, centralized PCE.
Distributed computation model: refers to the computation of paths in a
domain being shared among multiple PCEs.
Explicit PCE path: the full explicit path from start to destination,
made of a list of strict hops
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 3]
Internet Draft PCE Communication Protocol Requirements February 2005
Strict/Loose PCE path: a mix of strict and loose hops comprising of at
least one loose hop representing the destination), where a hop may be
an abstract node such as an AS.
Note, paths that span multiple domains may be computed using the
distributed model with a PCE responsible for each domain, or the
centralized model by defining a domain that encompasses all of the other
domains. From these definitions, a centralized computation model
inherently uses single PCE path computation. However, a distributed
computation model could use either single PCE path computation or
multiple PCE path computations. There would be no such thing as a
centralized model that uses multiple PCE path computations.
5. PCE Communication Protocol Application Examples
Once the 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 requirements, such as source, destination, bandwidth
required, etc., as listed in Section 6.
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.
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. The path computation request may include a
significant set of requirements including those defined above. In case
of a positive response from the PCE, one or more paths would be returned
to the requesting PCE. 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.
The following sections illustrate the applications of the PCE
communication protocol.
5.1. External PCE
Figure 1 shows PCE support that is external from the requesting network
element. A service request is received by the head-end node and before
it can signal to establish the service it uses the PCE communication
protocol to make a request to the external PCE for a path to be
computed. The PCE makes the computation using the TED and returns a
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 4]
Internet Draft PCE Communication Protocol Requirements February 2005
response.
----------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
Figure 1. External PCE Node
5.2. Multiple PCE Path Computation
Figure 2 illustrates how multiple PCE path computations may be performed
along the path of a signaled service. As in the previous example, the
head-end PCC uses the PCE communication protocol to make a request to an
external PCE, but the path that is returned is such that the next
network element finds it necessary to perform further computation. It
consults another PCE using the PCE communication protocol
(request/response) to establish the next hop in the path.
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service ---------- Signaling ------------- Signaling ------------
Request| Head-End | Protocol |Intermediate | Protocol |Intermediate|
---->| Node |<---------->| Node |<--------->| Node |
---------- ------------- ------------
Figure 2. Multiple PCE Path Computation
5.3. Multiple PCE Path Computation with Inter-PCE Communication
The PCE in Section 5.2 was not able to supply a full path for the
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 5]
Internet Draft PCE Communication Protocol Requirements February 2005
requested service and this resulted in the adjacent node needing to make
its own computation request. As illustrated in Figure 3, the same
problem is solved by introducing inter-PCE communication and cooperation
between PCEs so that the PCE consulted by the head-end network node
makes a request of another PCE to help with the computation.
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 3. Multiple PCE Path Computation with Inter-PCE Communication
Multiple PCE path computation with inter-PCE communication involves
coordination between distributed PCEs such that the result of the
computation performed by one PCE depends on information supplied by
other PCEs. Note that a PCC cannot see the difference between
centralized computation, and multiple PCE path computation with
inter-PCE communication. That is, the PCC network node or component that
requests the computation makes a single request and receives a full or
partial path in response, but the response is actually achieved through
the coordinated, cooperative efforts of more than one PCE.
6. PCE Communication Protocol Requirements
PCE communication protocol protocol MUST support:
R1. communication between PCC-PCE & PCE-PCE in (G)MPLS networks
R1.1 one protocol for both cases
R2. reliable message exchange
R2.1 reliable transport
R2.2 request-response message exchange
R3. security of PCC-PCE & PCE-PCE messages
R3.1 encryption for some data fields, prevent snooping
R3.2 authentication, prevent spoofing
R3.2 DoS protection
R4. confidentiality of PCE communication messages, possibly across
multiple domains
R4.1 little coordination of SP internal topology
R4.2 use loose routes
R4.3 replace ERO segment with cookie
- entry point to domain consults local PCE using cookie to
retrieve next ERO segment
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 6]
Internet Draft PCE Communication Protocol Requirements February 2005
R5. protocol recovery procedures
R5.1 graceful restart for stateful PCE
R6. scale well with the following
R6.1 number of PCCs
R6.2 number of PCEs
R6.3 TED size (number of links/nodes)
R6.4 number of domains
R7. minimize communication overhead
R8. PCE communication protocol SHOULD support collection of TE
information
R8.1 LSP traffic volume, LSP route
R9. operation in various SP/networking environments
R9.1 IP-MPLS, GMPLS, & optical networks
R9.2 P2P path computation
R9.3 intra/inter-domain & inter-layer path computation
R9.4 inter-layer reconfiguration & path setup/release
- path computation triggered by higher-layer PCC, PCE, or
lower-layer PCC
o PCE optionally triggers inter-layer path computation based
on traffic/topology change or failure
- lower-layer path established/released if necessary
o use (optional) support setup/release request/reply messages
R9.5 centralized & distributed computation model
R9.6 single & multiple PCE path computation
R9.7 external PCE node
R9.8 stateful & stateless PCEs
R9.9 synchronized & non-synchronized PCE
R10. PCC-PCE & PCE-PCE path request message MUST support carrying
various constraints including (but not limited to):
R10.1 path source/destination
R10.2 bandwidth & QoS parameters (e.g., hop count, delay,
preemption priority, etc.)
R10.3 diversity, SRLGs, optical impairments, wavelengh continuity
R10.4 maximum number of paths acceptable
R10.5 number of disjoint paths required
- if near-disjoint paths acceptable
R10.6 loose path to be expanded
R10.7 minimum bandwidth of returned path
R10.8 path previously returned (useful for stateless PCEs)
R10.9 link/node protection capability
- multiple correlated paths for protection
R10.10 loose path to be expanded
R10.11 resources (links/nodes), resource affinities & SRLGs to
use/avoid
- exclusions
o unsorted list of links/nodes/SRLGs that must not appear
in the resulting path(s)
- inclusions
o sorted list of links/nodes that must appear in resulting
path(s) in specified order
o strict & loose inclusions
- specify if additional links can appear in resulting
path(s)
- sharables
o unsorted list of links that must not be excluded in
resulting path(s) because of insufficient resources
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 7]
Internet Draft PCE Communication Protocol Requirements February 2005
R10.12 switching type, encoding type, GPID
R10.13 switching capabilities to be included/excluded from the path
R10.14 carrying multiple requests, correlated or not
R11. PCC-PCE & PCE-PCE path request message MUST support ability to
prefer/customize various path computation algorithms & policies
R11.1 shortest intra/inter-domain TE paths
- not require full graph to compute shortest/diverse path
- recursive CSPF computation
R11.2 reoptimization for intra/inter-domain TE paths
R11.3 complex routing requiring high CPU & memory
- multiple constraints, e.g. bounded delay minimum cost path
R11.4 backup path computation
R11.5 QoS CAC
R12. PCE-PCC & PCE-PCE path response message MUST support returning
various objects including (but not limited to):
R12.1 primary & alternate P2P paths
R12.2 explicit or strict/loose routing path
R12.3 primary & backup path (for FRR)
R12.4 less-constrained path (if cannot find path satisfying all
constraints)
R12.5 indication of PCE inability to support service/constraint
- specify services/constraints PCE can support
R12.6 a cookie, in case path must be hidden
7. Protocol Design Considerations
The PCE communication protocol SHOULD account for future extensions not
currently in PCE WG scope, such as P2MP paths.
The PCC-PCE communication protocol SHOULD reuse as far as possible
existing objects used by existing signaling protocols to encode path
constraints and routes, in order to avoid costly object conversions. New
objects must be defined only when necessary. For instance the EROs
should be reused to encode the computed path in a Path Response message.
For instance, it would be highly useful to reuse the ERO to encode the
computed path in a Path Response message.
Current PCE communication protocol alternatives include the following:
o RSVP-TE extensions
- http://www.watersprings.org/pub/id/draft-vasseur-mpls-computation
-rsvp-05.txt
o TCP extensions
- http://www.watersprings.org/pub/id/draft-lee-mpls-path-request
-04.txt
o LDP extensions
o BGP extensions
o PCE --><-- GMPLS controller
- draft-oki-ccamp-gtep-01.txt
8. 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
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 8]
Internet Draft PCE Communication Protocol Requirements February 2005
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 effects in this
area.
Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain detailed
security sections.
It should be observed that the use of 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.
9. IANA Considerations
This document makes no requests for IANA action.
10. Acknowledgements
The authors would like to extend their warmest thanks to (in
alphabetical order) Adrian Farrel and JP Vasseur for their review and
suggestions.
11. 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
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 9]
Internet Draft PCE Communication Protocol Requirements February 2005
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
12. Normative References
[PCE-ARCH] Farrel, Vasseur, Ash, "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.
13. Informational References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702, September
1999.
[RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547, March
1999.
[RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Engineering",
draft-ietf-tewg- interarea-mpls-te-req-03.txt, November 2004 (work in
progress).
[INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt,
September 2004 (work in progress).
[MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for
Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt,
February 2004 (work in progress).
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 10]
Internet Draft PCE Communication Protocol Requirements February 2005
14. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Email: gash@att.com
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
Igor Bryskin
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
MCI
Email: durga.gangisetti@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
E-mail: 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
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 11]
Internet Draft PCE Communication Protocol Requirements February 2005
Raymond Zhang
INFONET Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90245 USA
Email: Raymond_zhang@infonet.com
15. 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PCE Design Team <draft-ash-pce-comm-protocol-reqs-00.txt> [Page 12]