Network Working Group JP. Vasseur, Ed.
`Request for Comments: 5440 Cisco Systems
`Category: Standards Track JL. Le Roux, Ed.
` France Telecom
` March 2009
`
` Path Computation Element (PCE) Communication Protocol (PCEP)
`
`Status of This Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (c) 2009 IETF Trust and the persons identified as the
` document authors. All rights reserved.
`
` This document is subject to BCP 78 and the IETF Trust’s Legal
` Provisions Relating to IETF Documents in effect on the date of
` publication of this document (http://trustee.ietf.org/license-info).
` Please review these documents carefully, as they describe your rights
` and restrictions with respect to this document.
`
` This document may contain material from IETF Documents or IETF
` Contributions published or made publicly available before November
` 10, 2008. The person(s) controlling the copyright in some of this
` material may not have granted the IETF Trust the right to allow
` modifications of such material outside the IETF Standards Process.
` Without obtaining an adequate license from the person(s) controlling
` the copyright in such materials, this document may not be modified
` outside the IETF Standards Process, and derivative works of it may
` not be created outside the IETF Standards Process, except to format
` it for publication as an RFC or to translate it into languages other
` than English.
`
`Vasseur & Le Roux Standards Track [Page 1]
`
`Page 1 of 87
`
`GOOGLE EXHIBIT 1015
`
`

`

`
`RFC 5440 PCEP March 2009
`
`Abstract
`
` This document specifies the Path Computation Element (PCE)
` Communication Protocol (PCEP) for communications between a Path
` Computation Client (PCC) and a PCE, or between two PCEs. Such
` interactions include path computation requests and path computation
` replies as well as notifications of specific states related to the
` use of a PCE in the context of Multiprotocol Label Switching (MPLS)
` and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed
` to be flexible and extensible so as to easily allow for the addition
` of further messages and objects, should further requirements be
` expressed in the future.
`
`Vasseur & Le Roux Standards Track [Page 2]
`
`Page 2 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
`Table of Contents
`
` 1. Introduction ....................................................5
` 1.1. Requirements Language ......................................5
` 2. Terminology .....................................................5
` 3. Assumptions .....................................................6
` 4. Architectural Protocol Overview (Model) .........................7
` 4.1. Problem ....................................................7
` 4.2. Architectural Protocol Overview ............................7
` 4.2.1. Initialization Phase ................................8
` 4.2.2. Session Keepalive ...................................9
` 4.2.3. Path Computation Request Sent by a PCC to a PCE ....10
` 4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11
` 4.2.5. Notification .......................................12
` 4.2.6. Error ..............................................14
` 4.2.7. Termination of the PCEP Session ....................14
` 4.2.8. Intermittent versus Permanent PCEP Session .........15
` 5. Transport Protocol .............................................15
` 6. PCEP Messages ..................................................15
` 6.1. Common Header .............................................16
` 6.2. Open Message ..............................................16
` 6.3. Keepalive Message .........................................18
` 6.4. Path Computation Request (PCReq) Message ..................19
` 6.5. Path Computation Reply (PCRep) Message ....................20
` 6.6. Notification (PCNtf) Message ..............................21
` 6.7. Error (PCErr) Message .....................................22
` 6.8. Close Message .............................................23
` 6.9. Reception of Unknown Messages .............................23
` 7. Object Formats .................................................23
` 7.1. PCEP TLV Format ...........................................24
` 7.2. Common Object Header ......................................24
` 7.3. OPEN Object ...............................................25
` 7.4. RP Object .................................................27
` 7.4.1. Object Definition ..................................27
` 7.4.2. Handling of the RP Object ..........................30
` 7.5. NO-PATH Object ............................................31
` 7.6. END-POINTS Object .........................................34
` 7.7. BANDWIDTH Object ..........................................35
` 7.8. METRIC Object .............................................36
` 7.9. Explicit Route Object .....................................39
` 7.10. Reported Route Object ....................................39
` 7.11. LSPA Object ..............................................40
` 7.12. Include Route Object .....................................42
` 7.13. SVEC Object ..............................................42
` 7.13.1. Notion of Dependent and Synchronized Path
` Computation Requests ..............................42
` 7.13.2. SVEC Object .......................................44
` 7.13.3. Handling of the SVEC Object .......................45
`
`Vasseur & Le Roux Standards Track [Page 3]
`
`Page 3 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` 7.14. NOTIFICATION Object ......................................46
` 7.15. PCEP-ERROR Object ........................................49
` 7.16. LOAD-BALANCING Object ....................................54
` 7.17. CLOSE Object .............................................55
` 8. Manageability Considerations ...................................56
` 8.1. Control of Function and Policy ............................56
` 8.2. Information and Data Models ...............................57
` 8.3. Liveness Detection and Monitoring .........................57
` 8.4. Verifying Correct Operation ...............................58
` 8.5. Requirements on Other Protocols and Functional
` Components ................................................58
` 8.6. Impact on Network Operation ...............................58
` 9. IANA Considerations ............................................59
` 9.1. TCP Port ..................................................59
` 9.2. PCEP Messages .............................................59
` 9.3. PCEP Object ...............................................59
` 9.4. PCEP Message Common Header ................................61
` 9.5. Open Object Flag Field ....................................61
` 9.6. RP Object .................................................61
` 9.7. NO-PATH Object Flag Field .................................62
` 9.8. METRIC Object .............................................63
` 9.9. LSPA Object Flag Field ....................................63
` 9.10. SVEC Object Flag Field ...................................64
` 9.11. NOTIFICATION Object ......................................64
` 9.12. PCEP-ERROR Object ........................................65
` 9.13. LOAD-BALANCING Object Flag Field .........................67
` 9.14. CLOSE Object .............................................67
` 9.15. PCEP TLV Type Indicators .................................68
` 9.16. NO-PATH-VECTOR TLV .......................................68
` 10. Security Considerations .......................................69
` 10.1. Vulnerability ............................................69
` 10.2. TCP Security Techniques ..................................70
` 10.3. PCEP Authentication and Integrity ........................70
` 10.4. PCEP Privacy .............................................71
` 10.5. Key Configuration and Exchange ...........................71
` 10.6. Access Policy ............................................73
` 10.7. Protection against Denial-of-Service Attacks .............73
` 10.7.1. Protection against TCP DoS Attacks ................73
` 10.7.2. Request Input Shaping/Policing ....................74
` 11. Acknowledgments ...............................................75
` 12. References ....................................................75
` 12.1. Normative References .....................................75
` 12.2. Informative References ...................................76
` Appendix A. PCEP Finite State Machine (FSM) ......................79
` Appendix B. PCEP Variables .......................................85
` Appendix C. Contributors .........................................86
`
`Vasseur & Le Roux Standards Track [Page 4]
`
`Page 4 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
`1. Introduction
`
` [RFC4655] describes the motivations and architecture for a Path
` Computation Element (PCE) based model for the computation of
` Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
` Traffic Engineering Label Switched Paths (TE LSPs). The model allows
` for the separation of PCE from Path Computation Client (PCC), and
` allows for the cooperation between PCEs. This necessitates a
` communication protocol between PCC and PCE, and between PCEs.
` [RFC4657] states the generic requirements for such a protocol
` including that the same protocol be used between PCC and PCE, and
` between PCEs. Additional application-specific requirements (for
` scenarios such as inter-area, inter-AS, etc.) are not included in
` [RFC4657], but there is a requirement that any solution protocol must
` be easily extensible to handle other requirements as they are
` introduced in application-specific requirements documents. Examples
` of such application-specific requirements are [RFC4927], [RFC5376],
` and [INTER-LAYER].
`
` This document specifies the Path Computation Element Protocol (PCEP)
` for communications between a PCC and a PCE, or between two PCEs, in
` compliance with [RFC4657]. Such interactions include path
` computation requests and path computation replies as well as
` notifications of specific states related to the use of a PCE in the
` context of MPLS and GMPLS Traffic Engineering.
`
` PCEP is designed to be flexible and extensible so as to easily allow
` for the addition of further messages and objects, should further
` requirements be expressed in the future.
`
`1.1. Requirements Language
`
` 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].
`
`2. Terminology
`
` The following terminology is used in this document.
`
` AS: Autonomous System.
`
` Explicit path: Full explicit path from start to destination; made of
` a list of strict hops where a hop may be an abstract node such as
` an AS.
`
` IGP area: OSPF area or IS-IS level.
`
`Vasseur & Le Roux Standards Track [Page 5]
`
`Page 5 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` Inter-domain TE LSP: A TE LSP whose path transits at least two
` different domains where a domain can be an IGP area, an Autonomous
` System, or a sub-AS (BGP confederation).
`
` PCC: Path Computation Client; any client application requesting a
` path computation to be performed by a 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.
`
` PCEP Peer: An element involved in a PCEP session (i.e., a PCC or a
` PCE).
`
` TED: Traffic Engineering Database that 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 Label Switched Path.
`
` Strict/loose path: A mix of strict and loose hops comprising at
` least one loose hop representing the destination where a hop may
` be an abstract node such as an AS.
`
` Within this document, when describing PCE-PCE communications, the
` requesting PCE fills the role of a PCC. This provides a saving in
` documentation without loss of function.
`
` The message formats in this document are specified using Backus-Naur
` Format (BNF) encoding as specified in [RBNF].
`
`3. Assumptions
`
` [RFC4655] describes various types of PCE. PCEP does not make any
` assumption about, and thus does not impose any constraint on, the
` nature of the PCE.
`
` Moreover, it is assumed that the PCE has the required information
` (usually including network topology and resource information) so as
` to perform the computation of a path for a TE LSP. Such information
` can be gathered by routing protocols or by some other means. The way
` in which the information is gathered is out of the scope of this
` document.
`
` Similarly, no assumption is made about the discovery method used by a
` PCC to discover a set of PCEs (e.g., via static configuration or
` dynamic discovery) and on the algorithm used to select a PCE. For
`
`Vasseur & Le Roux Standards Track [Page 6]
`
`Page 6 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` reference, [RFC4674] defines a list of requirements for dynamic PCE
` discovery and IGP-based solutions for such PCE discovery are
` specified in [RFC5088] and [RFC5089].
`
`4. Architectural Protocol Overview (Model)
`
` The aim of this section is to describe the PCEP model in the spirit
` of [RFC4101]. An architectural protocol overview (the big picture of
` the protocol) is provided in this section. Protocol details can be
` found in further sections.
`
`4.1. Problem
`
` The PCE-based architecture used for the computation of paths for MPLS
` and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the
` PCE are not collocated, a communication protocol between the PCC and
` the PCE is needed. PCEP is such a protocol designed specifically for
` communications between a PCC and a PCE or between two PCEs in
` compliance with [RFC4657]: a PCC may use PCEP to send a path
` computation request for one or more TE LSPs to a PCE, and the PCE may
` reply with a set of computed paths if one or more paths can be found
` that satisfies the set of constraints.
`
`4.2. Architectural Protocol Overview
`
` PCEP operates over TCP, which fulfills the requirements for reliable
` messaging and flow control without further protocol work.
`
` Several PCEP messages are defined:
`
` o Open and Keepalive messages are used to initiate and maintain a
` PCEP session, respectively.
`
` o PCReq: a PCEP message sent by a PCC to a PCE to request a path
` computation.
`
` o PCRep: a PCEP message sent by a PCE to a PCC in reply to a path
` computation request. A PCRep message can contain either a set of
` computed paths if the request can be satisfied, or a negative
` reply if not. The negative reply may indicate the reason why no
` path could be found.
`
` o PCNtf: a PCEP notification message either sent by a PCC to a PCE
` or sent by a PCE to a PCC to notify of a specific event.
`
` o PCErr: a PCEP message sent upon the occurrence of a protocol error
` condition.
`
`Vasseur & Le Roux Standards Track [Page 7]
`
`Page 7 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` o Close message: a message used to close a PCEP session.
`
` The set of available PCEs may be either statically configured on a
` PCC or dynamically discovered. The mechanisms used to discover one
` or more PCEs and to select a PCE are out of the scope of this
` document.
`
` A PCC may have PCEP sessions with more than one PCE, and similarly a
` PCE may have PCEP sessions with multiple PCCs.
`
` Each PCEP message is regarded as a single transmission unit and parts
` of messages MUST NOT be interleaved. So, for example, a PCC sending
` a PCReq and wishing to close the session, must complete sending the
` request message before starting to send a Close message.
`
`4.2.1. Initialization Phase
`
` The initialization phase consists of two successive steps (described
` in a schematic form in Figure 1):
`
` 1) Establishment of a TCP connection (3-way handshake) between the
` PCC and the PCE.
`
` 2) Establishment of a PCEP session over the TCP connection.
`
` Once the TCP connection is established, the PCC and the PCE (also
` referred to as "PCEP peers") initiate PCEP session establishment
` during which various session parameters are negotiated. These
` parameters are carried within Open messages and include the Keepalive
` timer, the DeadTimer, and potentially other detailed capabilities and
` policy rules that specify the conditions under which path computation
` requests may be sent to the PCE. If the PCEP session establishment
` phase fails because the PCEP peers disagree on the session parameters
` or one of the PCEP peers does not answer after the expiration of the
` establishment timer, the TCP connection is immediately closed.
` Successive retries are permitted but an implementation should make
` use of an exponential back-off session establishment retry procedure.
`
` Keepalive messages are used to acknowledge Open messages, and are
` used once the PCEP session has been successfully established.
`
` Only one PCEP session can exist between a pair of PCEP peers at any
` one time. Only one TCP connection on the PCEP port can exist between
` a pair of PCEP peers at any one time.
`
` Details about the Open message and the Keepalive message can be found
` in Sections 6.2 and 6.3, respectively.
`
`Vasseur & Le Roux Standards Track [Page 8]
`
`Page 8 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` | |
` | Open msg |
` |-------- |
` | \ Open msg |
` | \ ---------|
` | \/ |
` | /\ |
` | / -------->|
` | / |
` |<------ Keepalive|
` | --------|
` |Keepalive / |
` |-------- / |
` | \/ |
` | /\ |
` |<------ ---------->|
` | |
`
` Figure 1: PCEP Initialization Phase (Initiated by a PCC)
`
` (Note that once the PCEP session is established, the exchange of
` Keepalive messages is optional.)
`
`4.2.2. Session Keepalive
`
` Once a session has been established, a PCE or PCC may want to know
` that its PCEP peer is still available for use.
`
` It can rely on TCP for this information, but it is possible that the
` remote PCEP function has failed without disturbing the TCP
` connection. It is also possible to rely on the mechanisms built into
` the TCP implementations, but these might not provide failure
` notifications that are sufficiently timely. Lastly, a PCC could wait
` until it has a path computation request to send and could use its
` failed transmission or the failure to receive a response as evidence
` that the session has failed, but this is clearly inefficient.
`
` In order to handle this situation, PCEP includes a keepalive
` mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive
` message.
`
` Each end of a PCEP session runs a Keepalive timer. It restarts the
` timer every time it sends a message on the session. When the timer
` expires, it sends a Keepalive message. Other traffic may serve as
` Keepalive (see Section 6.3).
`
`Vasseur & Le Roux Standards Track [Page 9]
`
`Page 9 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` The ends of the PCEP session also run DeadTimers, and they restart
` the timers whenever a message is received on the session. If one end
` of the session receives no message before the DeadTimer expires, it
` declares the session dead.
`
` Note that this means that the Keepalive message is unresponded and
` does not form part of a two-way keepalive handshake as used in some
` protocols. Also note that the mechanism is designed to reduce to a
` minimum the amount of keepalive traffic on the session.
`
` The keepalive traffic on the session may be unbalanced according to
` the requirements of the session ends. Each end of the session can
` specify (on an Open message) the Keepalive timer that it will use
` (i.e., how often it will transmit a Keepalive message if there is no
` other traffic) and a DeadTimer that it recommends its peer to use
` (i.e., how long the peer should wait before declaring the session
` dead if it receives no traffic). The session ends may use different
` Keepalive timer values.
`
` The minimum value of the Keepalive timer is 1 second, and it is
` specified in units of 1 second. The recommended default value is 30
` seconds. The timer may be disabled by setting it to zero.
`
` The recommended default for the DeadTimer is 4 times the value of the
` Keepalive timer used by the remote peer. This means that there is
` never any risk of congesting TCP with excessive Keepalive messages.
`
`4.2.3. Path Computation Request Sent by a PCC to a PCE
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` 1) Path computation | |
` event | |
` 2) PCE Selection | |
` 3) Path computation |---- PCReq message--->|
` request sent to | |
` the selected PCE | |
`
` Figure 2: Path Computation Request
`
` Once a PCC has successfully established a PCEP session with one or
` more PCEs, if an event is triggered that requires the computation of
` a set of paths, the PCC first selects one or more PCEs. Note that
` the PCE selection decision process may have taken place prior to the
` PCEP session establishment.
`
`Vasseur & Le Roux Standards Track [Page 10]
`
`Page 10 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` Once the PCC has selected a PCE, it sends a path computation request
` to the PCE (PCReq message) that contains a variety of objects that
` specify the set of constraints and attributes for the path to be
` computed. For example, "Compute a TE LSP path with source IP
` address=x.y.z.t, destination IP address=x’.y’.z’.t’, bandwidth=B
` Mbit/s, Setup/Holding priority=P, ...". Additionally, the PCC may
` desire to specify the urgency of such request by assigning a request
` priority. Each request is uniquely identified by a request-id number
` and the PCC-PCE address pair. The process is shown in a schematic
` form in Figure 2.
`
` Note that multiple path computation requests may be outstanding from
` a PCC to a PCE at any time.
`
` Details about the PCReq message can be found in Section 6.4.
`
`4.2.4. Path Computation Reply Sent by The PCE to a PCC
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` | |
` |---- PCReq message--->|
` | |1) Path computation
` | | request received
` | |
` | |2) Path successfully
` | | computed
` | |
` | |3) Computed paths
` | | sent to the PCC
` | |
` |<--- PCRep message ---|
` | (Positive reply) |
`
` Figure 3a: Path Computation Request With Successful
` Path Computation
`
`Vasseur & Le Roux Standards Track [Page 11]
`
`Page 11 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` | |
` | |
` |---- PCReq message--->|
` | |1) Path computation
` | | request received
` | |
` | |2) No Path found that
` | | satisfies the request
` | |
` | |3) Negative reply sent to
` | | the PCC (optionally with
` | | various additional
` | | information)
` |<--- PCRep message ---|
` | (Negative reply) |
`
` Figure 3b: Path Computation Request With Unsuccessful
` Path Computation
`
` Upon receiving a path computation request from a PCC, the PCE
` triggers a path computation, the result of which can be either:
`
` o Positive (Figure 3a): the PCE manages to compute a path that
` satisfies the set of required constraints. In this case, the PCE
` returns the set of computed paths to the requesting PCC. Note
` that PCEP supports the capability to send a single request that
` requires the computation of more than one path (e.g., computation
` of a set of link-diverse paths).
`
` o Negative (Figure 3b): no path could be found that satisfies the
` set of constraints. In this case, a PCE may provide the set of
` constraints that led to the path computation failure. Upon
` receiving a negative reply, a PCC may decide to resend a modified
` request or take any other appropriate action.
`
` Details about the PCRep message can be found in Section 6.5.
`
`4.2.5. Notification
`
` There are several circumstances in which a PCE may want to notify a
` PCC of a specific event. For example, suppose that the PCE suddenly
` gets overloaded, potentially leading to unacceptable response times.
` The PCE may want to notify one or more PCCs that some of their
` requests (listed in the notification) will not be satisfied or may
` experience unacceptable delays. Upon receiving such notification,
`
`Vasseur & Le Roux Standards Track [Page 12]
`
`Page 12 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
` the PCC may decide to redirect its path computation requests to
` another PCE should an alternate PCE be available. Similarly, a PCC
` may desire to notify a PCE of a particular event such as the
` cancellation of pending requests.
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` 1) Path computation | |
` event | |
` 2) PCE Selection | |
` 3) Path computation |---- PCReq message--->|
` request X sent to | |4) Path computation
` the selected PCE | | request queued
` | |
` | |
` 5) Path computation | |
` request X cancelled| |
` |---- PCNtf message -->|
` | |6) Path computation
` | | request X cancelled
`
` Figure 4: Example of PCC Notification (Cancellation Notification)
` Sent to a PCE
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` 1) Path computation | |
` event | |
` 2) PCE Selection | |
` 3) Path computation |---- PCReq message--->|
` request X sent to | |4) Path computation
` the selected PCE | | request queued
` | |
` | |
` | |5) PCE gets overloaded
` | |
` | |
` | |6) Path computation
` | | request X cancelled
` | |
` |<--- PCNtf message----|
`
` Figure 5: Example of PCE Notification (Cancellation Notification)
` Sent to a PCC
`
` Details about the PCNtf message can be found in Section 6.6.
`
`Vasseur & Le Roux Standards Track [Page 13]
`
`Page 13 of 87
`
`

`

`
`RFC 5440 PCEP March 2009
`
`4.2.6. Error
`
` The PCEP Error message (also referred to as a PCErr message) is sent
` in several situations: when a protocol error condition is met or when
` the request is not compliant with the PCEP specification (e.g.,
` capability not supported, reception of a message with a mandatory
` missing object, policy violation, unexpected message, unknown request
` reference).
`
` +-+-+ +-+-+
` |PCC| |PCE|
` +-+-+ +-+-+
` 1) Path computation | |
` event | |
` 2) PCE Selection | |
` 3) Path computation |---- PCReq message--->|
` request X sent to | |4) Reception of a
` the selected PCE | | malformed object
` | |
` | |5) Request discarded
` | |
` |<-- PCErr message ---|
` | |
`
` Figure 6: Example of Error Message Sent by a PCE to a PCC
` in Reply to the Reception of a Malformed Object
`
` Details about the PCErr message can be found in Section 6.7.
`
`4.2.7. Termination of the PCEP Session
`
` When one of the PCEP peers desires to terminate a PCEP session it
` first sends a PCEP Close message and then closes the TCP connection.
` If the PCEP session is terminated by the PCE, the PCC cl