doc: Add RFC documents

1 files changed, 4875 insertions, 0 deletions

diff --git a/doc/rfc/rfc5440.txt b/doc/rfc/rfc5440.txt
new file mode 100644
index 0000000..3cdb209
--- /dev/null
+++ b/doc/rfc/rfc5440.txt
@@ -0,0 +1,4875 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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 clears all the
+   states related to pending requests previously sent to the PCE.
+   Similarly, if the PCC terminates a PCEP session, the PCE clears all
+   pending path computation requests sent by the PCC in question as well
+   as the related states.  A Close message can only be sent to terminate
+   a PCEP session if the PCEP session has previously been established.
+
+   In case of TCP connection failure, the PCEP session is immediately
+   terminated.
+
+   Details about the Close message can be found in Section 6.8.
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 14]
+
+RFC 5440                          PCEP                        March 2009
+
+
+4.2.8.  Intermittent versus Permanent PCEP Session
+
+   An implementation may decide to keep the PCEP session alive (and thus
+   the corresponding TCP connection) for an unlimited time.  (For
+   instance, this may be appropriate when path computation requests are
+   sent on a frequent basis so as to avoid opening a TCP connection each
+   time a path computation request is needed, which would incur
+   additional processing delays.)  Conversely, in some other
+   circumstances, it may be desirable to systematically open and close a
+   PCEP session for each PCEP request (for instance, when sending a path
+   computation request is a rare event).
+
+5.  Transport Protocol
+
+   PCEP operates over TCP using a registered TCP port (4189).  This
+   allows the requirements of reliable messaging and flow control to be
+   met without further protocol work.  All PCEP messages MUST be sent
+   using the registered TCP port for the source and destination TCP
+   port.
+
+6.  PCEP Messages
+
+   A PCEP message consists of a common header followed by a variable-
+   length body made of a set of objects that can either be mandatory or
+   optional.  In the context of this document, an object is said to be
+   mandatory in a PCEP message when the object MUST be included for the
+   message to be considered valid.  A PCEP message with a missing
+   mandatory object MUST trigger an Error message (see Section 7.15).
+   Conversely, if an object is optional, the object may or may not be
+   present.
+
+   A flag referred to as the P flag is defined in the common header of
+   each PCEP object (see Section 7.2).  When this flag is set in an
+   object in a PCReq, the PCE MUST take the information carried in the
+   object into account during the path computation.  For example, the
+   METRIC object defined in Section 7.8 allows a PCC to specify a
+   bounded acceptable path cost.  The METRIC object is optional, but a
+   PCC may set a flag to ensure that the constraint is taken into
+   account.  In this case, if the constraint cannot be taken into
+   account by the PCE, the PCE MUST trigger an Error message.
+
+   For each PCEP message type, rules are defined that specify the set of
+   objects that the message can carry.  We use the Backus-Naur Form
+   (BNF) (see [RBNF]) to specify such rules.  Square brackets refer to
+   optional sub-sequences.  An implementation MUST form the PCEP
+   messages using the object ordering specified in this document.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 15]
+
+RFC 5440                          PCEP                        March 2009
+
+
+6.1.  Common Header
+
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Ver |  Flags  |  Message-Type |       Message-Length          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 7: PCEP Message Common Header
+
+   Ver (Version - 3 bits):  PCEP version number.  Current version is
+      version 1.
+
+   Flags (5 bits):  No flags are currently defined.  Unassigned bits are
+      considered as reserved.  They MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Message-Type (8 bits):  The following message types are currently
+      defined:
+
+         Value    Meaning
+           1        Open
+           2        Keepalive
+           3        Path Computation Request
+           4        Path Computation Reply
+           5        Notification
+           6        Error
+           7        Close
+
+   Message-Length (16 bits):  total length of the PCEP message including
+      the common header, expressed in bytes.
+
+6.2.  Open Message
+
+   The Open message is a PCEP message sent by a PCC to a PCE and by a
+   PCE to a PCC in order to establish a PCEP session.  The Message-Type
+   field of the PCEP common header for the Open message is set to 1.
+
+   Once the TCP connection has been successfully established, the first
+   message sent by the PCC to the PCE or by the PCE to the PCC MUST be
+   an Open message as specified in Appendix A.
+
+   Any message received prior to an Open message MUST trigger a protocol
+   error condition causing a PCErr message to be sent with Error-Type
+   "PCEP session establishment failure" and Error-value "reception of an
+   invalid Open message or a non Open message" and the PCEP session
+   establishment attempt MUST be terminated by closing the TCP
+   connection.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 16]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The Open message is used to establish a PCEP session between the PCEP
+   peers.  During the establishment phase, the PCEP peers exchange
+   several session characteristics.  If both parties agree on such
+   characteristics, the PCEP session is successfully established.
+
+   The format of an Open message is as follows:
+
+   <Open Message>::= <Common Header>
+                     <OPEN>
+
+   The Open message MUST contain exactly one OPEN object (see
+   Section 7.3).
+
+   Various session characteristics are specified within the OPEN object.
+   Once the TCP connection has been successfully established, the sender
+   MUST start an initialization timer called OpenWait after the
+   expiration of which, if no Open message has been received, it sends a
+   PCErr message and releases the TCP connection (see Appendix A for
+   details).
+
+   Once an Open message has been sent to a PCEP peer, the sender MUST
+   start an initialization timer called KeepWait after the expiration of
+   which, if neither a Keepalive message has been received nor a PCErr
+   message in case of disagreement of the session characteristics, a
+   PCErr message MUST be sent and the TCP connection MUST be released
+   (see Appendix A for details).
+
+   The OpenWait and KeepWait timers have a fixed value of 1 minute.
+
+   Upon the receipt of an Open message, the receiving PCEP peer MUST
+   determine whether the suggested PCEP session characteristics are
+   acceptable.  If at least one of the characteristics is not acceptable
+   to the receiving peer, it MUST send an Error message.  The Error
+   message SHOULD also contain the related OPEN object and, for each
+   unacceptable session parameter, an acceptable parameter value SHOULD
+   be proposed in the appropriate field of the OPEN object in place of
+   the originally proposed value.  The PCEP peer MAY decide to resend an
+   Open message with different session characteristics.  If a second
+   Open message is received with the same set of parameters or with
+   parameters that are still unacceptable, the receiving peer MUST send
+   an Error message and it MUST immediately close the TCP connection.
+   Details about error messages can be found in Section 7.15.
+   Successive retries are permitted, but an implementation SHOULD make
+   use of an exponential back-off session establishment retry procedure.
+
+   If the PCEP session characteristics are acceptable, the receiving
+   PCEP peer MUST send a Keepalive message (defined in Section 6.3) that
+   serves as an acknowledgment.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 17]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The PCEP session is considered as established once both PCEP peers
+   have received a Keepalive message from their peer.
+
+6.3.  Keepalive Message
+
+   A Keepalive message is a PCEP message sent by a PCC or a PCE in order
+   to keep the session in active state.  The Keepalive message is also
+   used in response to an Open message to acknowledge that an Open
+   message has been received and that the PCEP session characteristics
+   are acceptable.  The Message-Type field of the PCEP common header for
+   the Keepalive message is set to 2.  The Keepalive message does not
+   contain any object.
+
+   PCEP has its own keepalive mechanism used to ensure the liveness of
+   the PCEP session.  This requires the determination of the frequency
+   at which each PCEP peer sends Keepalive messages.  Asymmetric values
+   may be chosen; thus, there is no constraint mandating the use of
+   identical keepalive frequencies by both PCEP peers.  The DeadTimer is
+   defined as the period of time after the expiration of which a PCEP
+   peer declares the session down if no PCEP message has been received
+   (Keepalive or any other PCEP message); thus, any PCEP message acts as
+   a Keepalive message.  Similarly, there are no constraints mandating
+   the use of identical DeadTimers by both PCEP peers.  The minimum
+   Keepalive timer value is 1 second.  Deployments SHOULD consider
+   carefully the impact of using low values for the Keepalive timer as
+   these might not give rise to the expected results in periods of
+   temporary network instability.
+
+   Keepalive messages are sent at the frequency specified in the OPEN
+   object carried within an Open message according to the rules
+   specified in Section 7.3.  Because any PCEP message may serve as
+   Keepalive, an implementation may either decide to send Keepalive
+   messages at fixed intervals regardless of whether other PCEP messages
+   might have been sent since the last sent Keepalive message, or may
+   decide to differ the sending of the next Keepalive message based on
+   the time at which the last PCEP message (other than Keepalive) was
+   sent.
+
+   Note that sending Keepalive messages to keep the session alive is
+   optional, and PCEP peers may decide not to send Keepalive messages
+   once the PCEP session is established; in which case, the peer that
+   does not receive Keepalive messages does not expect to receive them
+   and MUST NOT declare the session as inactive.
+
+   The format of a Keepalive message is as follows:
+
+   <Keepalive Message>::= <Common Header>
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 18]
+
+RFC 5440                          PCEP                        March 2009
+
+
+6.4.  Path Computation Request (PCReq) Message
+
+   A Path Computation Request message (also referred to as a PCReq
+   message) is a PCEP message sent by a PCC to a PCE to request a path
+   computation.  A PCReq message may carry more than one path
+   computation request.  The Message-Type field of the PCEP common
+   header for the PCReq message is set to 3.
+
+   There are two mandatory objects that MUST be included within a PCReq
+   message: the RP and the END-POINTS objects (see Section 7).  If one
+   or both of these objects is missing, the receiving PCE MUST send an
+   error message to the requesting PCC.  Other objects are optional.
+
+   The format of a PCReq message is as follows:
+
+   <PCReq Message>::= <Common Header>
+                      [<svec-list>]
+                      <request-list>
+
+   where:
+
+      <svec-list>::=<SVEC>[<svec-list>]
+      <request-list>::=<request>[<request-list>]
+
+      <request>::= <RP>
+                   <END-POINTS>
+                   [<LSPA>]
+                   [<BANDWIDTH>]
+                   [<metric-list>]
+                   [<RRO>[<BANDWIDTH>]]
+                   [<IRO>]
+                   [<LOAD-BALANCING>]
+
+   where:
+
+   <metric-list>::=<METRIC>[<metric-list>]
+
+   The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and
+   LOAD-BALANCING objects are defined in Section 7.  The special case of
+   two BANDWIDTH objects is discussed in detail in Section 7.7.
+
+   A PCEP implementation is free to process received requests in any
+   order.  For example, the requests may be processed in the order they
+   are received, reordered and assigned priority according to local
+   policy, reordered according to the priority encoded in the RP object
+   (Section 7.4.1), or processed in parallel.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 19]
+
+RFC 5440                          PCEP                        March 2009
+
+
+6.5.  Path Computation Reply (PCRep) Message
+
+   The PCEP Path Computation Reply message (also referred to as a PCRep
+   message) is a PCEP message sent by a PCE to a requesting PCC in
+   response to a previously received PCReq message.  The Message-Type
+   field of the PCEP common header for the PCRep message is set to 4.
+
+   The bundling of multiple replies to a set of path computation
+   requests within a single PCRep message is supported by PCEP.  If a
+   PCE receives non-synchronized path computation requests by means of
+   one or more PCReq messages from a requesting PCC, it MAY decide to
+   bundle the computed paths within a single PCRep message so as to
+   reduce the control plane load.  Note that the counter side of such an
+   approach is the introduction of additional delays for some path
+   computation requests of the set.  Conversely, a PCE that receives
+   multiple requests within the same PCReq message MAY decide to provide
+   each computed path in separate PCRep messages or within the same
+   PCRep message.  A PCRep message may contain positive and negative
+   replies.
+
+   A PCRep message may contain a set of computed paths corresponding to
+   either a single path computation request with load-balancing (see
+   Section 7.16) or multiple path computation requests originated by a
+   requesting PCC.  The PCRep message may also contain multiple
+   acceptable paths corresponding to the same request.
+
+   The PCRep message MUST contain at least one RP object.  For each
+   reply that is bundled into a single PCReq message, an RP object MUST
+   be included that contains a Request-ID-number identical to the one
+   specified in the RP object carried in the corresponding PCReq message
+   (see Section 7.4 for the definition of the RP object).
+
+   If the path computation request can be satisfied (i.e., the PCE finds
+   a set of paths that satisfy the set of constraints), the set of
+   computed paths specified by means of Explicit Route Objects (EROs) is
+   inserted in the PCRep message.  The ERO is defined in Section 7.9.
+   The situation where multiple computed paths are provided in a PCRep
+   message is discussed in detail in Section 7.13.  Furthermore, when a
+   PCC requests the computation of a set of paths for a total amount of
+   bandwidth by means of a LOAD-BALANCING object carried within a PCReq
+   message, the ERO of each computed path may be followed by a BANDWIDTH
+   object as discussed in section Section 7.16.
+
+   If the path computation request cannot be satisfied, the PCRep
+   message MUST include a NO-PATH object.  The NO-PATH object (described
+   in Section 7.5) may also contain other information (e.g, reasons for
+   the path computation failure).
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 20]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of a PCRep message is as follows:
+
+
+   <PCRep Message> ::= <Common Header>
+                       <response-list>
+
+   where:
+
+      <response-list>::=<response>[<response-list>]
+
+      <response>::=<RP>
+                  [<NO-PATH>]
+                  [<attribute-list>]
+                  [<path-list>]
+
+      <path-list>::=<path>[<path-list>]
+
+      <path>::= <ERO><attribute-list>
+
+   where:
+
+    <attribute-list>::=[<LSPA>]
+                       [<BANDWIDTH>]
+                       [<metric-list>]
+                       [<IRO>]
+
+    <metric-list>::=<METRIC>[<metric-list>]
+
+6.6.  Notification (PCNtf) Message
+
+   The PCEP Notification message (also referred to as the PCNtf message)
+   can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify
+   of a specific event.  The Message-Type field of the PCEP common
+   header for the PCNtf message is set to 5.
+
+   The PCNtf message MUST carry at least one NOTIFICATION object and MAY
+   contain several NOTIFICATION objects should the PCE or the PCC intend
+   to notify of multiple events.  The NOTIFICATION object is defined in
+   Section 7.14.  The PCNtf message MAY also contain RP objects (see
+   Section 7.4) when the notification refers to particular path
+   computation requests.
+
+   The PCNtf message may be sent by a PCC or a PCE in response to a
+   request or in an unsolicited manner.
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 21]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of a PCNtf message is as follows:
+
+   <PCNtf Message>::=<Common Header>
+                     <notify-list>
+
+   <notify-list>::=<notify> [<notify-list>]
+
+   <notify>::= [<request-id-list>]
+                <notification-list>
+
+   <request-id-list>::=<RP>[<request-id-list>]
+
+   <notification-list>::=<NOTIFICATION>[<notification-list>]
+
+6.7.  Error (PCErr) Message
+
+   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.,
+   reception of a malformed message, reception of a message with a
+   mandatory missing object, policy violation, unexpected message,
+   unknown request reference).  The Message-Type field of the PCEP
+   common header for the PCErr message is set to 6.
+
+   The PCErr message is sent by a PCC or a PCE in response to a request
+   or in an unsolicited manner.  If the PCErr message is sent in
+   response to a request, the PCErr message MUST include the set of RP
+   objects related to the pending path computation requests that
+   triggered the error condition.  In the latter case (unsolicited), no
+   RP object is inserted in the PCErr message.  For example, no RP
+   object is inserted in a PCErr when the error condition occurred
+   during the initialization phase.  A PCErr message MUST contain a
+   PCEP-ERROR object specifying the PCEP error condition.  The PCEP-
+   ERROR object is defined in Section 7.15.
+
+   The format of a PCErr message is as follows:
+
+   <PCErr Message> ::= <Common Header>
+                       ( <error-obj-list> [<Open>] ) | <error>
+                       [<error-list>]
+
+   <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
+
+   <error>::=[<request-id-list>]
+              <error-obj-list>
+
+   <request-id-list>::=<RP>[<request-id-list>]
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 22]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   <error-list>::=<error>[<error-list>]
+
+   The procedure upon the receipt of a PCErr message is defined in
+   Section 7.15.
+
+6.8.  Close Message
+
+   The Close message is a PCEP message that is either sent by a PCC to a
+   PCE or by a PCE to a PCC in order to close an established PCEP
+   session.  The Message-Type field of the PCEP common header for the
+   Close message is set to 7.
+
+   The format of a Close message is as follows:
+
+   <Close Message>::= <Common Header>
+                      <CLOSE>
+
+   The Close message MUST contain exactly one CLOSE object (see
+   Section 6.8).  If more than one CLOSE object is present, the first
+   MUST be processed and subsequent objects ignored.
+
+   Upon the receipt of a valid Close message, the receiving PCEP peer
+   MUST cancel all pending requests, it MUST close the TCP connection
+   and MUST NOT send any further PCEP messages on the PCEP session.
+
+6.9.  Reception of Unknown Messages
+
+   A PCEP implementation that receives an unrecognized PCEP message MUST
+   send a PCErr message with Error-value=2 (capability not supported).
+
+   If a PCC/PCE receives unrecognized messages at a rate equal or
+   greater than MAX-UNKNOWN-MESSAGES unknown message requests per
+   minute, the PCC/PCE MUST send a PCEP CLOSE message with close
+   value="Reception of an unacceptable number of unknown PCEP message".
+   A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5.  The PCC/PCE MUST
+   close the TCP session and MUST NOT send any further PCEP messages on
+   the PCEP session.
+
+7.  Object Formats
+
+   PCEP objects have a common format.  They begin with a common object
+   header (see Section 7.2).  This is followed by object-specific fields
+   defined for each different object.  The object may also include one
+   or more type-length-value (TLV) encoded data sets.  Each TLV has the
+   same structure as described in Section 7.1.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 23]
+
+RFC 5440                          PCEP                        March 2009
+
+
+7.1.  PCEP TLV Format
+
+   A PCEP object may include a set of one or more optional TLVs.
+
+   All PCEP TLVs have the following format:
+
+   Type:   2 bytes
+   Length: 2 bytes
+   Value:  variable
+
+   A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes
+   specifying the TLV length, and a value field.
+
+   The Length field defines the length of the value portion in bytes.
+   The TLV is padded to 4-bytes alignment; padding is not included in
+   the Length field (so a 3-byte value would have a length of 3, but the
+   total size of the TLV would be 8 bytes).
+
+   Unrecognized TLVs MUST be ignored.
+
+   IANA management of the PCEP Object TLV type identifier codespace is
+   described in Section 9.
+
+7.2.  Common Object Header
+
+   A PCEP object carried within a PCEP message consists of one or more
+   32-bit words with a common header that has the following format:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                        (Object body)                        //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 8: PCEP Common Object Header
+
+   Object-Class (8 bits):  identifies the PCEP object class.
+
+   OT (Object-Type - 4 bits):  identifies the PCEP object type.
+
+      The Object-Class and Object-Type fields are managed by IANA.
+
+      The Object-Class and Object-Type fields uniquely identify each
+      PCEP object.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 24]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Res flags (2 bits):  Reserved field.  This field MUST be set to zero
+      on transmission and MUST be ignored on receipt.
+
+   P flag (Processing-Rule - 1-bit):  the P flag allows a PCC to specify
+      in a PCReq message sent to a PCE whether the object must be taken
+      into account by the PCE during path computation or is just
+      optional.  When the P flag is set, the object MUST be taken into
+      account by the PCE.  Conversely, when the P flag is cleared, the
+      object is optional and the PCE is free to ignore it.
+
+   I flag (Ignore - 1 bit):  the I flag is used by a PCE in a PCRep
+      message to indicate to a PCC whether or not an optional object was
+      processed.  The PCE MAY include the ignored optional object in its
+      reply and set the I flag to indicate that the optional object was
+      ignored during path computation.  When the I flag is cleared, the
+      PCE indicates that the optional object was processed during the
+      path computation.  The setting of the I flag for optional objects
+      is purely indicative and optional.  The I flag has no meaning in a
+      PCRep message when the P flag has been set in the corresponding
+      PCReq message.
+
+   If the PCE does not understand an object with the P flag set or
+   understands the object but decides to ignore the object, the entire
+   PCEP message MUST be rejected and the PCE MUST send a PCErr message
+   with Error-Type="Unknown Object" or "Not supported Object" along with
+   the corresponding RP object.  Note that if a PCReq includes multiple
+   requests, only requests for which an object with the P flag set is
+   unknown/unrecognized MUST be rejected.
+
+   Object Length (16 bits):  Specifies the total object length including
+      the header, in bytes.  The Object Length field MUST always be a
+      multiple of 4, and at least 4.  The maximum object content length
+      is 65528 bytes.
+
+7.3.  OPEN Object
+
+   The OPEN object MUST be present in each Open message and MAY be
+   present in a PCErr message.  There MUST be only one OPEN object per
+   Open or PCErr message.
+
+   The OPEN object contains a set of fields used to specify the PCEP
+   version, Keepalive frequency, DeadTimer, and PCEP session ID, along
+   with various flags.  The OPEN object may also contain a set of TLVs
+   used to convey various session characteristics such as the detailed
+   PCE capabilities, policy rules, and so on.  No TLVs are currently
+   defined.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 25]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   OPEN Object-Class is 1.
+
+   OPEN Object-Type is 1.
+
+   The format of the OPEN object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Ver |   Flags |   Keepalive   |  DeadTimer    |      SID      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                       Optional TLVs                         //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 9: OPEN Object Format
+
+   Ver (3 bits):  PCEP version.  Current version is 1.
+
+   Flags (5 bits):  No flags are currently defined.  Unassigned bits are
+      considered as reserved.  They MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Keepalive (8 bits):  maximum period of time (in seconds) between two
+      consecutive PCEP messages sent by the sender of this message.  The
+      minimum value for the Keepalive is 1 second.  When set to 0, once
+      the session is established, no further Keepalive messages are sent
+      to the remote peer.  A RECOMMENDED value for the keepalive
+      frequency is 30 seconds.
+
+   DeadTimer (8 bits):  specifies the amount of time after the
+      expiration of which the PCEP peer can declare the session with the
+      sender of the Open message to be down if no PCEP message has been
+      received.  The DeadTimer SHOULD be set to 0 and MUST be ignored if
+      the Keepalive is set to 0.  A RECOMMENDED value for the DeadTimer
+      is 4 times the value of the Keepalive.
+
+   Example:
+
+   A sends an Open message to B with Keepalive=10 seconds and
+   DeadTimer=40 seconds.  This means that A sends Keepalive messages (or
+   any other PCEP message) to B every 10 seconds and B can declare the
+   PCEP session with A down if no PCEP message has been received from A
+   within any 40-second period.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 26]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   SID (PCEP session ID - 8 bits):  unsigned PCEP session number that
+      identifies the current session.  The SID MUST be incremented each
+      time a new PCEP session is established.  It is used for logging
+      and troubleshooting purposes.  Each increment SHOULD have a value
+      of 1 and may cause a wrap back to zero.
+
+      The SID is used to disambiguate instances of sessions to the same
+      peer.  A PCEP implementation could use a single source of SIDs
+      across all peers, or one source for each peer.  The former might
+      constrain the implementation to only 256 concurrent sessions.  The
+      latter potentially requires more states.  There is one SID number
+      in each direction.
+
+   Optional TLVs may be included within the OPEN object body to specify
+   PCC or PCE characteristics.  The specification of such TLVs is
+   outside the scope of this document.
+
+   When present in an Open message, the OPEN object specifies the
+   proposed PCEP session characteristics.  Upon receiving unacceptable
+   PCEP session characteristics during the PCEP session initialization
+   phase, the receiving PCEP peer (PCE) MAY include an OPEN object
+   within the PCErr message so as to propose alternative acceptable
+   session characteristic values.
+
+7.4.  RP Object
+
+   The RP (Request Parameters) object MUST be carried within each PCReq
+   and PCRep messages and MAY be carried within PCNtf and PCErr
+   messages.  The RP object is used to specify various characteristics
+   of the path computation request.
+
+   The P flag of the RP object MUST be set in PCReq and PCRep messages
+   and MUST be cleared in PCNtf and PCErr messages.  If the RP object is
+   received with the P flag set incorrectly according to the rules
+   stated above, the receiving peer MUST send a PCErr message with
+   Error-Type=10 and Error-value=1.  The corresponding path computation
+   request MUST be cancelled by the PCE without further notification.
+
+7.4.1.  Object Definition
+
+   RP Object-Class is 2.
+
+   RP Object-Type is 1.
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 27]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of the RP object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Flags                    |O|B|R| Pri |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Request-ID-number                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                      Optional TLVs                          //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 10: RP Object Body Format
+
+   The RP object body has a variable length and may contain additional
+   TLVs.  No TLVs are currently defined.
+
+   Flags (32 bits)
+
+   The following flags are currently defined:
+
+   o  Pri (Priority - 3 bits): the Priority field may be used by the
+      requesting PCC to specify to the PCE the request's priority from 1
+      to 7.  The decision of which priority should be used for a
+      specific request is a local matter; it MUST be set to 0 when
+      unused.  Furthermore, the use of the path computation request
+      priority by the PCE's scheduler is implementation specific and out
+      of the scope of this document.  Note that it is not required for a
+      PCE to support the priority field: in this case, it is RECOMMENDED
+      that the PCC set the priority field to 0 in the RP object.  If the
+      PCE does not take into account the request priority, it is
+      RECOMMENDED to set the priority field to 0 in the RP object
+      carried within the corresponding PCRep message, regardless of the
+      priority value contained in the RP object carried within the
+      corresponding PCReq message.  A higher numerical value of the
+      priority field reflects a higher priority.  Note that it is the
+      responsibility of the network administrator to make use of the
+      priority values in a consistent manner across the various PCCs.
+      The ability of a PCE to support request prioritization MAY be
+      dynamically discovered by the PCCs by means of PCE capability
+      discovery.  If not advertised by the PCE, a PCC may decide to set
+      the request priority and will learn the ability of the PCE to
+      support request prioritization by observing the Priority field of
+      the RP object received in the PCRep message.  If the value of the
+      Pri field is set to 0, this means that the PCE does not support
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 28]
+
+RFC 5440                          PCEP                        March 2009
+
+
+      the handling of request priorities: in other words, the path
+      computation request has been honored but without taking the
+      request priority into account.
+
+   o  R (Reoptimization - 1 bit): when set, the requesting PCC specifies
+      that the PCReq message relates to the reoptimization of an
+      existing TE LSP.  For all TE LSPs except zero-bandwidth LSPs, when
+      the R bit is set, an RRO (see Section 7.10) MUST be included in
+      the PCReq message to show the path of the existing TE LSP.  Also,
+      for all TE LSPs except zero-bandwidth LSPs, when the R bit is set,
+      the existing bandwidth of the TE LSP to be reoptimized MUST be
+      supplied in a BANDWIDTH object (see Section 7.7).  This BANDWIDTH
+      object is in addition to the instance of that object used to
+      describe the desired bandwidth of the reoptimized LSP.  For zero-
+      bandwidth LSPs, the RRO and BANDWIDTH objects that report the
+      characteristics of the existing TE LSP are optional.
+
+   o  B (Bi-directional - 1 bit): when set, the PCC specifies that the
+      path computation request relates to a bi-directional TE LSP that
+      has the same traffic engineering requirements including fate
+      sharing, protection and restoration, LSRs, TE links, and resource
+      requirements (e.g., latency and jitter) in each direction.  When
+      cleared, the TE LSP is unidirectional.
+
+   o  O (strict/loose - 1 bit): when set, in a PCReq message, this
+      indicates that a loose path is acceptable.  Otherwise, when
+      cleared, this indicates to the PCE that a path exclusively made of
+      strict hops is required.  In a PCRep message, when the O bit is
+      set this indicates that the returned path is a loose path;
+      otherwise (when the O bit is cleared), the returned path is made
+      of strict hops.
+
+   Unassigned bits are considered reserved.  They MUST be set to zero on
+   transmission and MUST be ignored on receipt.
+
+   Request-ID-number (32 bits):  The Request-ID-number value combined
+      with the source IP address of the PCC and the PCE address uniquely
+      identify the path computation request context.  The Request-ID-
+      number is used for disambiguation between pending requests, and
+      thus it MUST be changed (such as by incrementing it) each time a
+      new request is sent to the PCE, and may wrap.
+
+      The value 0x00000000 is considered invalid.
+
+      If no path computation reply is received from the PCE (e.g., the
+      request is dropped by the PCE because of memory overflow), and the
+      PCC wishes to resend its request, the same Request-ID-number MUST
+      be used.  Upon receiving a path computation request from a PCC
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 29]
+
+RFC 5440                          PCEP                        March 2009
+
+
+      with the same Request-ID-number, the PCE SHOULD treat the request
+      as a new request.  An implementation MAY choose to cache path
+      computation replies in order to quickly handle retransmission
+      without having to process a path computation request twice (in the
+      case that the first request was dropped or lost).  Upon receiving
+      a path computation reply from a PCE with the same Request-ID-
+      number, the PCC SHOULD silently discard the path computation
+      reply.
+
+      Conversely, different Request-ID-numbers MUST be used for
+      different requests sent to a PCE.
+
+      The same Request-ID-number MAY be used for path computation
+      requests sent to different PCEs.  The path computation reply is
+      unambiguously identified by the IP source address of the replying
+      PCE.
+
+7.4.2.  Handling of the RP Object
+
+   If a PCReq message is received that does not contain an RP object,
+   the PCE MUST send a PCErr message to the requesting PCC with Error-
+   Type="Required Object missing" and Error-value="RP Object missing".
+
+   If the O bit of the RP message carried within a PCReq message is
+   cleared and local policy has been configured on the PCE to not
+   provide explicit paths (for instance, for confidentiality reasons), a
+   PCErr message MUST be sent by the PCE to the requesting PCC and the
+   pending path computation request MUST be discarded.  The Error-Type
+   is "Policy Violation" and Error-value is "O bit cleared".
+
+   When the R bit of the RP object is set in a PCReq message, this
+   indicates that the path computation request relates to the
+   reoptimization of an existing TE LSP.  In this case, the PCC MUST
+   also provide the strict/loose path by including an RRO object in the
+   PCReq message so as to avoid/limit double-bandwidth counting if and
+   only if the TE LSP is a non-zero-bandwidth TE LSP.  If the PCC has
+   not requested a strict path (O bit set), a reoptimization can still
+   be requested by the PCC, but this requires that the PCE either be
+   stateful (keep track of the previously computed path with the
+   associated list of strict hops), or have the ability to retrieve the
+   complete required path segment.  Alternatively, the PCC MUST inform
+   the PCE about the working path and the associated list of strict hops
+   in PCReq.  The absence of an RRO in the PCReq message for a non-zero-
+   bandwidth TE LSP (when the R bit of the RP object is set) MUST
+   trigger the sending of a PCErr message with Error-Type="Required
+   Object Missing" and Error-value="RRO Object missing for
+   reoptimization".
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 30]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   If a PCC/PCE receives a PCRep/PCReq message that contains an RP
+   object referring to an unknown Request-ID-number, the PCC/PCE MUST
+   send a PCErr message with Error-Type="Unknown request reference".
+   This is used for debugging purposes.  If a PCC/PCE receives PCRep/
+   PCReq messages with unknown requests at a rate equal or greater than
+   MAX-UNKNOWN-REQUESTS unknown requests per minute, the PCC/PCE MUST
+   send a PCEP CLOSE message with close value="Reception of an
+   unacceptable number of unknown requests/replies".  A RECOMMENDED
+   value for MAX-UNKNOWN-REQUESTS is 5.  The PCC/PCE MUST close the TCP
+   session and MUST NOT send any further PCEP messages on the PCEP
+   session.
+
+   The reception of a PCEP message that contains an RP object referring
+   to a Request-ID-number=0x00000000 MUST be treated in similar manner
+   as an unknown request.
+
+7.5.  NO-PATH Object
+
+   The NO-PATH object is used in PCRep messages in response to an
+   unsuccessful path computation request (the PCE could not find a path
+   satisfying the set of constraints).  When a PCE cannot find a path
+   satisfying a set of constraints, it MUST include a NO-PATH object in
+   the PCRep message.
+
+   There are several categories of issue that can lead to a negative
+   reply.  For example, the PCE chain might be broken (should there be
+   more than one PCE involved in the path computation) or no path
+   obeying the set constraints could be found.  The "NI (Nature of
+   Issue)" field in the NO-PATH object is used to report the error
+   category.
+
+   Optionally, if the PCE supports such capability, the NO-PATH object
+   MAY contain an optional NO-PATH-VECTOR TLV defined below and used to
+   provide more information on the reasons that led to a negative reply.
+   The PCRep message MAY also contain a list of objects that specify the
+   set of constraints that could not be satisfied.  The PCE MAY just
+   replicate the set of objects that was received that was the cause of
+   the unsuccessful computation or MAY optionally report a suggested
+   value for which a path could have been found (in which case, the
+   value differs from the value in the original request).
+
+   NO-PATH Object-Class is 3.
+
+   NO-PATH Object-Type is 1.
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 31]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of the NO-PATH object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |Nature of Issue|C|          Flags              |   Reserved    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                      Optional TLVs                          //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 11: NO-PATH Object Format
+
+   NI - Nature of Issue (8 bits):  The NI field is used to report the
+      nature of the issue that led to a negative reply.  Two values are
+      currently defined:
+
+         0: No path satisfying the set of constraints could be found
+
+         1: PCE chain broken
+
+      The Nature of Issue field value can be used by the PCC for various
+      purposes:
+
+      *  Constraint adjustment before reissuing a new path computation
+         request,
+
+      *  Explicit selection of a new PCE chain,
+
+      *  Logging of the error type for further action by the network
+         administrator.
+
+      IANA management of the NI field codespace is described in
+      Section 9.
+
+   Flags (16 bits).
+
+   The following flag is currently defined:
+
+   o  C flag (1 bit): when set, the PCE indicates the set of unsatisfied
+      constraints (reasons why a path could not be found) in the PCRep
+      message by including the relevant PCEP objects.  When cleared, no
+      failing constraints are specified.  The C flag has no meaning and
+      is ignored unless the NI field is set to 0x00.
+
+   Unassigned bits are considered as reserved.  They MUST be set to zero
+   on transmission and MUST be ignored on receipt.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 32]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Reserved (8 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   The NO-PATH object body has a variable length and may contain
+   additional TLVs.  The only TLV currently defined is the NO-PATH-
+   VECTOR TLV defined below.
+
+   Example: consider the case of a PCC that sends a path computation
+   request to a PCE for a TE LSP of X Mbit/s.  Suppose that PCE cannot
+   find a path for X Mbit/s.  In this case, the PCE must include in the
+   PCRep message a NO-PATH object.  Optionally, the PCE may also include
+   the original BANDWIDTH object so as to indicate that the reason for
+   the unsuccessful computation is the bandwidth constraint (in this
+   case, the NI field value is 0x00 and C flag is set).  If the PCE
+   supports such capability, it may alternatively include the BANDWIDTH
+   object and report a value of Y in the bandwidth field of the
+   BANDWIDTH object (in this case, the C flag is set) where Y refers to
+   the bandwidth for which a TE LSP with the same other characteristics
+   (such as Setup/Holding priorities, TE LSP attribute, local
+   protection, etc.) could have been computed.
+
+   When the NO-PATH object is absent from a PCRep message, the path
+   computation request has been fully satisfied and the corresponding
+   paths are provided in the PCRep message.
+
+   An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH
+   object in order to provide more information on the reasons that led
+   to a negative reply.
+
+   The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined
+   in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes
+   specifying the TLV length (length of the value portion in bytes)
+   followed by a fixed-length 32-bit flags field.
+
+   Type:   1
+   Length: 4 bytes
+   Value:  32-bit flags field
+
+   IANA manages the space of flags carried in the NO-PATH-VECTOR TLV
+   (see Section 9).
+
+   The following flags are currently defined:
+
+   o  Bit number: 31 - PCE currently unavailable
+
+   o  Bit number: 30 - Unknown destination
+
+   o  Bit number: 29 - Unknown source
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 33]
+
+RFC 5440                          PCEP                        March 2009
+
+
+7.6.  END-POINTS Object
+
+   The END-POINTS object is used in a PCReq message to specify the
+   source IP address and the destination IP address of the path for
+   which a path computation is requested.  The P flag of the END-POINTS
+   object MUST be set.  If the END-POINTS object is received with the P
+   flag cleared, the receiving peer MUST send a PCErr message with
+   Error-Type=10 and Error-value=1.  The corresponding path computation
+   request MUST be cancelled by the PCE without further notification.
+
+   Note that the source and destination addresses specified in the END-
+   POINTS object may correspond to the source and destination IP address
+   of the TE LSP or to those of a path segment.  Two END-POINTS objects
+   (for IPv4 and IPv6) are defined.
+
+   END-POINTS Object-Class is 4.
+
+   END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6.
+
+   The format of the END-POINTS object body for IPv4 (Object-Type=1) is
+   as follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Source IPv4 address                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                  Destination IPv4 address                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 12: END-POINTS Object Body Format for IPv4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 34]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of the END-POINTS object for IPv6 (Object-Type=2) is as
+   follows:
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                Source IPv6 address (16 bytes)                 |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |              Destination IPv6 address (16 bytes)              |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 13: END-POINTS Object Body Format for IPv6
+
+   The END-POINTS object body has a fixed length of 8 bytes for IPv4 and
+   32 bytes for IPv6.
+
+   If more than one END-POINTS object is present, the first MUST be
+   processed and subsequent objects ignored.
+
+7.7.  BANDWIDTH Object
+
+   The BANDWIDTH object is used to specify the requested bandwidth for a
+   TE LSP.  The notion of bandwidth is similar to the one used for RSVP
+   signaling in [RFC2205], [RFC3209], and [RFC3473].
+
+   If the requested bandwidth is equal to 0, the BANDWIDTH object is
+   optional.  Conversely, if the requested bandwidth is not equal to 0,
+   the PCReq message MUST contain a BANDWIDTH object.
+
+   In the case of the reoptimization of a TE LSP, the bandwidth of the
+   existing TE LSP MUST also be included in addition to the requested
+   bandwidth if and only if the two values differ.  Consequently, two
+   Object-Type values are defined that refer to the requested bandwidth
+   and the bandwidth of the TE LSP for which a reoptimization is being
+   performed.
+
+   The BANDWIDTH object may be carried within PCReq and PCRep messages.
+
+   BANDWIDTH Object-Class is 5.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 35]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Two Object-Type values are defined for the BANDWIDTH object:
+
+   o  Requested bandwidth: BANDWIDTH Object-Type is 1.
+
+   o  Bandwidth of an existing TE LSP for which a reoptimization is
+      requested.  BANDWIDTH Object-Type is 2.
+
+   The format of the BANDWIDTH object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Bandwidth                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 14: BANDWIDTH Object Body Format
+
+   Bandwidth (32 bits):  The requested bandwidth is encoded in 32 bits
+      in IEEE floating point format (see [IEEE.754.1985]), expressed in
+      bytes per second.  Refer to Section 3.1.2 of [RFC3471] for a table
+      of commonly used values.
+
+   The BANDWIDTH object body has a fixed length of 4 bytes.
+
+7.8.  METRIC Object
+
+   The METRIC object is optional and can be used for several purposes.
+
+   In a PCReq message, a PCC MAY insert one or more METRIC objects:
+
+   o  To indicate the metric that MUST be optimized by the path
+      computation algorithm (IGP metric, TE metric, hop counts).
+      Currently, three metrics are defined: the IGP cost, the TE metric
+      (see [RFC3785]), and the number of hops traversed by a TE LSP.
+
+   o  To indicate a bound on the path cost that MUST NOT be exceeded for
+      the path to be considered as acceptable by the PCC.
+
+   In a PCRep message, the METRIC object MAY be inserted so as to
+   provide the cost for the computed path.  It MAY also be inserted
+   within a PCRep with the NO-PATH object to indicate that the metric
+   constraint could not be satisfied.
+
+   The path computation algorithmic aspects used by the PCE to optimize
+   a path with respect to a specific metric are outside the scope of
+   this document.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 36]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   It must be understood that such path metrics are only meaningful if
+   used consistently: for instance, if the delay of a computed path
+   segment is exchanged between two PCEs residing in different domains,
+   consistent ways of defining the delay must be used.
+
+   The absence of the METRIC object MUST be interpreted by the PCE as a
+   path computation request for which no constraints need be applied to
+   any of the metrics.
+
+   METRIC Object-Class is 6.
+
+   METRIC Object-Type is 1.
+
+   The format of the METRIC object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Reserved             |    Flags  |C|B|       T       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          metric-value                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 15: METRIC Object Body Format
+
+   The METRIC object body has a fixed length of 8 bytes.
+
+   Reserved (16 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   T (Type - 8 bits):  Specifies the metric type.
+
+      Three values are currently defined:
+      *  T=1: IGP metric
+      *  T=2: TE metric
+      *  T=3: Hop Counts
+
+   Flags (8 bits):  Two flags are currently defined:
+
+      *  B (Bound - 1 bit): When set in a PCReq message, the metric-
+         value indicates a bound (a maximum) for the path metric that
+         must not be exceeded for the PCC to consider the computed path
+         as acceptable.  The path metric must be less than or equal to
+         the value specified in the metric-value field.  When the B flag
+         is cleared, the metric-value field is not used to reflect a
+         bound constraint.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 37]
+
+RFC 5440                          PCEP                        March 2009
+
+
+      *  C (Computed Metric - 1 bit): When set in a PCReq message, this
+         indicates that the PCE MUST provide the computed path metric
+         value (should a path satisfying the constraints be found) in
+         the PCRep message for the corresponding metric.
+
+      Unassigned flags MUST be set to zero on transmission and MUST be
+      ignored on receipt.
+
+   Metric-value (32 bits):  metric value encoded in 32 bits in IEEE
+      floating point format (see [IEEE.754.1985]).
+
+   Multiple METRIC objects MAY be inserted in a PCRep or a PCReq message
+   for a given request (i.e., for a given RP).  For a given request,
+   there MUST be at most one instance of the METRIC object for each
+   metric type with the same B flag value.  If, for a given request, two
+   or more instances of a METRIC object with the same B flag value are
+   present for a metric type, only the first instance MUST be considered
+   and other instances MUST be ignored.
+
+   For a given request, the presence of two METRIC objects of the same
+   type with a different value of the B flag is allowed.  Furthermore,
+   it is also allowed to insert, for a given request, two METRIC objects
+   with different types that have both their B flag cleared: in this
+   case, an objective function must be used by the PCE to solve a multi-
+   parameter optimization problem.
+
+   A METRIC object used to indicate the metric to optimize during the
+   path computation MUST have the B flag cleared and the C flag set to
+   the appropriate value.  When the path computation relates to the
+   reoptimization of an exiting TE LSP (in which case, the R flag of the
+   RP object is set), an implementation MAY decide to set the metric-
+   value field to the computed value of the metric of the TE LSP to be
+   reoptimized with regards to a specific metric type.
+
+   A METRIC object used to reflect a bound MUST have the B flag set, and
+   the C flag and metric-value field set to the appropriate values.
+
+   In a PCRep message, unless not allowed by PCE policy, at least one
+   METRIC object MUST be present that reports the computed path metric
+   if the C flag of the METRIC object was set in the corresponding path
+   computation request (the B flag MUST be cleared).  The C flag has no
+   meaning in a PCRep message.  Optionally, the PCRep message MAY
+   contain additional METRIC objects that correspond to bound
+   constraints; in which case, the metric-value MUST be equal to the
+   corresponding computed path metric (the B flag MUST be set).  If no
+   path satisfying the constraints could be found by the PCE, the METRIC
+   objects MAY also be present in the PCRep message with the NO-PATH
+   object to indicate the constraint metric that could be satisfied.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 38]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Example: if a PCC sends a path computation request to a PCE where the
+   metric to optimize is the IGP metric and the TE metric must not
+   exceed the value of M, two METRIC objects are inserted in the PCReq
+   message:
+
+   o  First METRIC object with B=0, T=1, C=1, metric-value=0x0000
+
+   o  Second METRIC object with B=1, T=2, metric-value=M
+
+   If a path satisfying the set of constraints can be found by the PCE
+   and there is no policy that prevents the return of the computed
+   metric, the PCE inserts one METRIC object with B=0, T=1, metric-
+   value= computed IGP path cost.  Additionally, the PCE may insert a
+   second METRIC object with B=1, T=2, metric-value= computed TE path
+   cost.
+
+7.9.  Explicit Route Object
+
+   The ERO is used to encode the path of a TE LSP through the network.
+   The ERO is carried within a PCRep message to provide the computed TE
+   LSP if the path computation was successful.
+
+   The contents of this object are identical in encoding to the contents
+   of the Resource Reservation Protocol Traffic Engineering Extensions
+   (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209],
+   [RFC3473], and [RFC3477].  That is, the object is constructed from a
+   series of sub-objects.  Any RSVP-TE ERO sub-object already defined or
+   that could be defined in the future for use in the RSVP-TE ERO is
+   acceptable in this object.
+
+   PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types.
+
+   Since the explicit path is available for immediate signaling by the
+   MPLS or GMPLS control plane, the meanings of all of the sub-objects
+   and fields in this object are identical to those defined for the ERO.
+
+   ERO Object-Class is 7.
+
+   ERO Object-Type is 1.
+
+7.10.  Reported Route Object
+
+   The RRO is exclusively carried within a PCReq message so as to report
+   the route followed by a TE LSP for which a reoptimization is desired.
+
+   The contents of this object are identical in encoding to the contents
+   of the Route Record Object defined in [RFC3209], [RFC3473], and
+   [RFC3477].  That is, the object is constructed from a series of sub-
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 39]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   objects.  Any RSVP-TE RRO sub-object already defined or that could be
+   defined in the future for use in the RSVP-TE RRO is acceptable in
+   this object.
+
+   The meanings of all of the sub-objects and fields in this object are
+   identical to those defined for the RSVP-TE RRO.
+
+   PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types.
+
+   RRO Object-Class is 8.
+
+   RRO Object-Type is 1.
+
+7.11.  LSPA Object
+
+   The LSPA (LSP Attributes) object is optional and specifies various TE
+   LSP attributes to be taken into account by the PCE during path
+   computation.  The LSPA object can be carried within a PCReq message,
+   or a PCRep message in case of unsuccessful path computation (in this
+   case, the PCRep message also contains a NO-PATH object, and the LSPA
+   object is used to indicate the set of constraints that could not be
+   satisfied).  Most of the fields of the LSPA object are identical to
+   the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in
+   [RFC3209] and [RFC4090].  When absent from the PCReq message, this
+   means that the Setup and Holding priorities are equal to 0, and there
+   are no affinity constraints.  See Section 4.7.4 of [RFC3209] for a
+   detailed description of the use of resource affinities.
+
+   LSPA Object-Class is 9.
+
+   LSPA Object-Types is 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 40]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of the LSPA object body is:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Exclude-any                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Include-any                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Include-all                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  Setup Prio   |  Holding Prio |     Flags   |L|   Reserved    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                     Optional TLVs                           //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 16: LSPA Object Body Format
+
+   Setup Prio (Setup Priority - 8 bits):  The priority of the TE LSP
+      with respect to taking resources, in the range of 0 to 7.  The
+      value 0 is the highest priority.  The Setup Priority is used in
+      deciding whether this session can preempt another session.
+
+   Holding Prio (Holding Priority - 8 bits):  The priority of the TE LSP
+      with respect to holding resources, in the range of 0 to 7.  The
+      value 0 is the highest priority.  Holding Priority is used in
+      deciding whether this session can be preempted by another session.
+
+   Flags (8 bits)
+
+      L flag:  Corresponds to the "Local Protection Desired" bit
+         ([RFC3209]) of the SESSION-ATTRIBUTE Object.  When set, this
+         means that the computed path must include links protected with
+         Fast Reroute as defined in [RFC4090].
+
+      Unassigned flags MUST be set to zero on transmission and MUST be
+      ignored on receipt.
+
+   Reserved (8 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Note that optional TLVs may be defined in the future to carry
+   additional TE LSP attributes such as those defined in [RFC5420].
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 41]
+
+RFC 5440                          PCEP                        March 2009
+
+
+7.12.  Include Route Object
+
+   The IRO (Include Route Object) is optional and can be used to specify
+   that the computed path MUST traverse a set of specified network
+   elements.  The IRO MAY be carried within PCReq and PCRep messages.
+   When carried within a PCRep message with the NO-PATH object, the IRO
+   indicates the set of elements that cause the PCE to fail to find a
+   path.
+
+   IRO Object-Class is 10.
+
+   IRO Object-Type is 1.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                        (Sub-objects)                        //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 17: IRO Body Format
+
+   Sub-objects:  The IRO is made of sub-objects identical to the ones
+      defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub-
+      object type is identical to the sub-object type defined in the
+      related documents.
+
+      The following sub-object types are supported.
+
+          Type   Sub-object
+           1     IPv4 prefix
+           2     IPv6 prefix
+           4     Unnumbered Interface ID
+           32    Autonomous system number
+
+   The L bit of such sub-object has no meaning within an IRO.
+
+7.13.  SVEC Object
+
+7.13.1.  Notion of Dependent and Synchronized Path Computation Requests
+
+   Independent versus dependent path computation requests: path
+   computation requests are said to be independent if they are not
+   related to each other.  Conversely, a set of dependent path
+   computation requests is such that their computations cannot be
+   performed independently of each other (a typical example of dependent
+   requests is the computation of a set of diverse paths).
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 42]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Synchronized versus non-synchronized path computation requests: a set
+   of path computation requests is said to be non-synchronized if their
+   respective treatment (path computations) can be performed by a PCE in
+   a serialized and independent fashion.
+
+   There are various circumstances where the synchronization of a set of
+   path computations may be beneficial or required.
+
+   Consider the case of a set of N TE LSPs for which a PCC needs to send
+   path computation requests to a PCE.  The first solution consists of
+   sending N separate PCReq messages to the selected PCE.  In this case,
+   the path computation requests are non-synchronized.  Note that the
+   PCC may chose to distribute the set of N requests across K PCEs for
+   load balancing purposes.  Considering that M (with M<N) requests are
+   sent to a particular PCEi, as described above, such M requests can be
+   sent in the form of successive PCReq messages destined to PCEi or
+   bundled within a single PCReq message (since PCEP allows for the
+   bundling of multiple path computation requests within a single PCReq
+   message).  That said, even in the case of independent requests, it
+   can be desirable to request from the PCE the computation of their
+   paths in a synchronized fashion that is likely to lead to more
+   optimal path computations and/or reduced blocking probability if the
+   PCE is a stateless PCE.  In other words, the PCE should not compute
+   the corresponding paths in a serialized and independent manner, but
+   it should rather "simultaneously" compute their paths.  For example,
+   trying to "simultaneously" compute the paths of M TE LSPs may allow
+   the PCE to improve the likelihood to meet multiple constraints.
+
+   Consider the case of two TE LSPs requesting N1 Mbit/s and N2 Mbit/s,
+   respectively, and a maximum tolerable end-to-end delay for each TE
+   LSP of X ms.  There may be circumstances where the computation of the
+   first TE LSP, irrespectively of the second TE LSP, may lead to the
+   impossibility to meet the delay constraint for the second TE LSP.
+
+   A second example is related to the bandwidth constraint.  It is quite
+   straightforward to provide examples where a serialized independent
+   path computation approach would lead to the impossibility to satisfy
+   both requests (due to bandwidth fragmentation), while a synchronized
+   path computation would successfully satisfy both requests.
+
+   A last example relates to the ability to avoid the allocation of the
+   same resource to multiple requests, thus helping to reduce the call
+   setup failure probability compared to the serialized computation of
+   independent requests.
+
+   Dependent path computations are usually synchronized.  For example,
+   in the case of the computation of M diverse paths, if such paths are
+   computed in a non-synchronized fashion, this seriously increases the
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 43]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   probability of not being able to satisfy all requests (sometimes also
+   referred to as the well-known "trapping problem").
+
+   Furthermore, this would not allow a PCE to implement objective
+   functions such as trying to minimize the sum of the TE LSP costs.  In
+   such a case, the path computation requests must be synchronized: they
+   cannot be computed independently of each other.
+
+   Conversely, a set of independent path computation requests may or may
+   not be synchronized.
+
+   The synchronization of a set of path computation requests is achieved
+   by using the SVEC object that specifies the list of synchronized
+   requests that can either be dependent or independent.
+
+   PCEP supports the following three modes:
+
+   o  Bundle of a set of independent and non-synchronized path
+      computation requests,
+
+   o  Bundle of a set of independent and synchronized path computation
+      requests (requires the SVEC object defined below),
+
+   o  Bundle of a set of dependent and synchronized path computation
+      requests (requires the SVEC object defined below).
+
+7.13.2.  SVEC Object
+
+   Section 7.13.1 details the circumstances under which it may be
+   desirable and/or required to synchronize a set of path computation
+   requests.  The SVEC (Synchronization VECtor) object allows a PCC to
+   request the synchronization of a set of dependent or independent path
+   computation requests.  The SVEC object is optional and may be carried
+   within a PCReq message.
+
+   The aim of the SVEC object carried within a PCReq message is to
+   request the synchronization of M path computation requests.  The SVEC
+   object is a variable-length object that lists the set of M path
+   computation requests that must be synchronized.  Each path
+   computation request is uniquely identified by the Request-ID-number
+   carried within the respective RP object.  The SVEC object also
+   contains a set of flags that specify the synchronization type.
+
+   SVEC Object-Class is 11.
+
+   SVEC Object-Type is 1.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 44]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The format of the SVEC object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Reserved    |                   Flags                 |S|N|L|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     Request-ID-number #1                      |
+   //                                                             //
+   |                     Request-ID-number #M                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 18: SVEC Body Object Format
+
+   Reserved (8 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Flags (24 bits):  Defines the potential dependency between the set of
+      path computation requests.
+
+      *  L (Link diverse) bit: when set, this indicates that the
+         computed paths corresponding to the requests specified by the
+         following RP objects MUST NOT have any link in common.
+
+      *  N (Node diverse) bit: when set, this indicates that the
+         computed paths corresponding to the requests specified by the
+         following RP objects MUST NOT have any node in common.
+
+      *  S (SRLG diverse) bit: when set, this indicates that the
+         computed paths corresponding to the requests specified by the
+         following RP objects MUST NOT share any SRLG (Shared Risk Link
+         Group).
+
+      In case of a set of M synchronized independent path computation
+      requests, the bits L, N, and S are cleared.
+
+   Unassigned flags MUST be set to zero on transmission and MUST be
+   ignored on receipt.
+
+   The flags defined above are not exclusive.
+
+7.13.3.  Handling of the SVEC Object
+
+   The SVEC object allows a PCC to specify a list of M path computation
+   requests that MUST be synchronized along with a potential dependency.
+   The set of M path computation requests may be sent within a single
+   PCReq message or multiple PCReq messages.  In the latter case, it is
+   RECOMMENDED for the PCE to implement a local timer (called the
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 45]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   SyncTimer) activated upon the receipt of the first PCReq message that
+   contains the SVEC object after the expiration of which, if all the M
+   path computation requests have not been received, a protocol error is
+   triggered.  When a PCE receives a path computation request that
+   cannot be satisfied (for example, because the PCReq message contains
+   an object with the P bit set that is not supported), the PCE sends a
+   PCErr message for this request (see Section 7.2), the PCE MUST cancel
+   the whole set of related path computation requests and MUST send a
+   PCErr message with Error-Type="Synchronized path computation request
+   missing".
+
+   Note that such PCReq messages may also contain non-synchronized path
+   computation requests.  For example, the PCReq message may comprise N
+   synchronized path computation requests that are related to RP 1, ...,
+   RP N and are listed in the SVEC object along with any other path
+   computation requests that are processed as normal.
+
+7.14.  NOTIFICATION Object
+
+   The NOTIFICATION object is exclusively carried within a PCNtf message
+   and can either be used in a message sent by a PCC to a PCE or by a
+   PCE to a PCC so as to notify of an event.
+
+   NOTIFICATION Object-Class is 12.
+
+   NOTIFICATION Object-Type is 1.
+
+   The format of the NOTIFICATION body object is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Reserved    |     Flags     |      NT       |     NV        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                      Optional TLVs                          //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               Figure 19: NOTIFICATION Body Object Format
+
+   Reserved (8 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Flags (8 bits):  No flags are currently defined.  Unassigned flags
+      MUST be set to zero on transmission and MUST be ignored on
+      receipt.
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 46]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   NT (Notification Type - 8 bits):  The Notification-type specifies the
+      class of notification.
+
+   NV (Notification Value - 8 bits):  The Notification-value provides
+      addition information related to the nature of the notification.
+
+   Both the Notification-type and Notification-value are managed by
+   IANA.
+
+   The following Notification-type and Notification-value values are
+   currently defined:
+
+   o  Notification-type=1: Pending Request cancelled
+
+      *  Notification-value=1: PCC cancels a set of pending requests.  A
+         Notification-type=1, Notification-value=1 indicates that the
+         PCC wants to inform a PCE of the cancellation of a set of
+         pending requests.  Such an event could be triggered because of
+         external conditions such as the receipt of a positive reply
+         from another PCE (should the PCC have sent multiple requests to
+         a set of PCEs for the same path computation request), a network
+         event such as a network failure rendering the request obsolete,
+         or any other events local to the PCC.  A NOTIFICATION object
+         with Notification-type=1, Notification-value=1 is carried
+         within a PCNtf message sent by the PCC to the PCE.  The RP
+         object corresponding to the cancelled request MUST also be
+         present in the PCNtf message.  Multiple RP objects may be
+         carried within the PCNtf message; in which case, the
+         notification applies to all of them.  If such a notification is
+         received by a PCC from a PCE, the PCC MUST silently ignore the
+         notification and no errors should be generated.
+
+      *  Notification-value=2: PCE cancels a set of pending requests.  A
+         Notification-type=1, Notification-value=2 indicates that the
+         PCE wants to inform a PCC of the cancellation of a set of
+         pending requests.  A NOTIFICATION object with Notification-
+         type=1, Notification-value=2 is carried within a PCNtf message
+         sent by a PCE to a PCC.  The RP object corresponding to the
+         cancelled request MUST also be present in the PCNtf message.
+         Multiple RP objects may be carried within the PCNtf message; in
+         which case, the notification applies to all of them.  If such
+         notification is received by a PCE from a PCC, the PCE MUST
+         silently ignore the notification and no errors should be
+         generated.
+
+   o  Notification-type=2: Overloaded PCE
+
+      *  Notification-value=1: A Notification-type=2, Notification-
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 47]
+
+RFC 5440                          PCEP                        March 2009
+
+
+         value=1 indicates to the PCC that the PCE is currently in an
+         overloaded state.  If no RP objects are included in the PCNtf
+         message, this indicates that no other requests SHOULD be sent
+         to that PCE until the overloaded state is cleared: the pending
+         requests are not affected and will be served.  If some pending
+         requests cannot be served due to the overloaded state, the PCE
+         MUST also include a set of RP objects that identifies the set
+         of pending requests that are cancelled by the PCE and will not
+         be honored.  In this case, the PCE does not have to send an
+         additional PCNtf message with Notification-type=1 and
+         Notification-value=2 since the list of cancelled requests is
+         specified by including the corresponding set of RP objects.  If
+         such notification is received by a PCE from a PCC, the PCE MUST
+         silently ignore the notification and no errors should be
+         generated.
+
+      *  A PCE implementation SHOULD use a dual-threshold mechanism used
+         to determine whether it is in a congestion state with regards
+         to specific resource monitoring (e.g.  CPU, memory).  The use
+         of such thresholds is to avoid oscillations between overloaded/
+         non-overloaded state that may result in oscillations of request
+         targets by the PCCs.
+
+      *  Optionally, a TLV named OVERLOADED-DURATION may be included in
+         the NOTIFICATION object that specifies the period of time
+         during which no further request should be sent to the PCE.
+         Once this period of time has elapsed, the PCE should no longer
+         be considered in a congested state.
+
+         The OVERLOADED-DURATION TLV is compliant with the PCEP TLV
+         format defined in Section 7.1 and is comprised of 2 bytes for
+         the type, 2 bytes specifying the TLV length (length of the
+         value portion in bytes), followed by a fixed-length value field
+         of a 32-bit flags field.
+
+         Type:   2
+         Length: 4 bytes
+         Value:  32-bit flags field indicates the estimated PCE
+                 congestion duration in seconds.
+
+      *  Notification-value=2: A Notification-type=2, Notification-
+         value=2 indicates that the PCE is no longer in an overloaded
+         state and is available to process new path computation
+         requests.  An implementation SHOULD make sure that a PCE sends
+         such notification to every PCC to which a Notification message
+         (with Notification-type=2, Notification-value=1) has been sent
+         unless an OVERLOADED-DURATION TLV has been included in the
+         corresponding message and the PCE wishes to wait for the
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 48]
+
+RFC 5440                          PCEP                        March 2009
+
+
+         expiration of that period of time before receiving new
+         requests.  If such notification is received by a PCE from a
+         PCC, the PCE MUST silently ignore the notification and no
+         errors should be generated.  It is RECOMMENDED to support some
+         dampening notification procedure on the PCE so as to avoid too
+         frequent congestion state and congestion state release
+         notifications.  For example, an implementation could make use
+         of an hysteresis approach using a dual-threshold mechanism that
+         triggers the sending of congestion state notifications.
+         Furthermore, in case of high instabilities of the PCE
+         resources, an additional dampening mechanism SHOULD be used
+         (linear or exponential) to pace the notification frequency and
+         avoid oscillation of path computation requests.
+
+   When a PCC receives an overload indication from a PCE, it should
+   consider the impact on the entire network.  It must be remembered
+   that other PCCs may also receive the notification, and so many path
+   computation requests could be redirected to other PCEs.  This may, in
+   turn, cause further overloading at PCEs in the network.  Therefore,
+   an application at a PCC receiving an overload notification should
+   consider applying some form of back-off (e.g., exponential) to the
+   rate at which it generates path computation requests into the
+   network.  This is especially the case as the number of PCEs reporting
+   overload grows.
+
+7.15.  PCEP-ERROR Object
+
+   The PCEP-ERROR object is exclusively carried within a PCErr message
+   to notify of a PCEP error.
+
+   PCEP-ERROR Object-Class is 13.
+
+   PCEP-ERROR Object-Type is 1.
+
+   The format of the PCEP-ERROR object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   Reserved    |      Flags    |   Error-Type  |  Error-value  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                     Optional TLVs                           //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               Figure 20: PCEP-ERROR Object Body Format
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 49]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   A PCEP-ERROR object is used to report a PCEP error and is
+   characterized by an Error-Type that specifies the type of error and
+   an Error-value that provides additional information about the error
+   type.  Both the Error-Type and the Error-value are managed by IANA
+   (see the IANA section).
+
+   Reserved (8 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Flags (8 bits):  no flag is currently defined.  This flag MUST be set
+      to zero on transmission and MUST be ignored on receipt.
+
+   Error-Type (8 bits):  defines the class of error.
+
+   Error-value (8 bits):  provides additional details about the error.
+
+   Optionally, the PCEP-ERROR object may contain additional TLVs so as
+   to provide further information about the encountered error.
+
+   A single PCErr message may contain multiple PCEP-ERROR objects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 50]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   For each PCEP error, an Error-Type and an Error-value are defined.
+
+   Error-Type    Meaning
+      1          PCEP session establishment failure
+                 Error-value=1: reception of an invalid Open message or
+                                a non Open message.
+                 Error-value=2: no Open message received before the
+                                expiration of the OpenWait timer
+                 Error-value=3: unacceptable and non-negotiable session
+                                characteristics
+                 Error-value=4: unacceptable but negotiable session
+                                characteristics
+                 Error-value=5: reception of a second Open message with
+                                still unacceptable session
+                                characteristics
+                 Error-value=6: reception of a PCErr message proposing
+                                unacceptable session characteristics
+                 Error-value=7: No Keepalive or PCErr message received
+                                before the expiration of the KeepWait
+                                timer
+      2          Capability not supported
+      3          Unknown Object
+                  Error-value=1: Unrecognized object class
+                  Error-value=2: Unrecognized object Type
+      4          Not supported object
+                  Error-value=1: Not supported object class
+                  Error-value=2: Not supported object Type
+      5          Policy violation
+                  Error-value=1: C bit of the METRIC object set
+                                 (request rejected)
+                  Error-value=2: O bit of the RP object set
+                                 (request rejected)
+      6          Mandatory Object missing
+                  Error-value=1: RP object missing
+                  Error-value=2: RRO object missing for a reoptimization
+                                 request (R bit of the RP object set)
+                                 when bandwidth is not equal to 0.
+                  Error-value=3: END-POINTS object missing
+      7          Synchronized path computation request missing
+      8          Unknown request reference
+      9          Attempt to establish a second PCEP session
+      10         Reception of an invalid object
+                  Error-value=1: reception of an object with P flag not
+                  set although the P flag must be set according to this
+                  specification.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 51]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The error types listed above are described below.
+
+   Error-Type=1: PCEP session establishment failure.
+
+      If a malformed message is received, the receiving PCEP peer MUST
+      send a PCErr message with Error-Type=1, Error-value=1.
+
+      If no Open message is received before the expiration of the
+      OpenWait timer, the receiving PCEP peer MUST send a PCErr message
+      with Error-Type=1, Error-value=2 (see Appendix A for details).
+
+      If one or more PCEP session characteristics are unacceptable by
+      the receiving peer and are not negotiable, it MUST send a PCErr
+      message with Error-Type=1, Error-value=3.
+
+      If an Open message is received with unacceptable session
+      characteristics but these characteristics are negotiable, the
+      receiving PCEP peer MUST send a PCErr message with Error-Type-1,
+      Error-value=4 (see Section 6.2 for details).
+
+      If a second Open message is received during the PCEP session
+      establishment phase and the session characteristics are still
+      unacceptable, the receiving PCEP peer MUST send a PCErr message
+      with Error-Type-1, Error-value=5 (see Section 6.2 for details).
+
+      If a PCErr message is received during the PCEP session
+      establishment phase that contains an Open message proposing
+      unacceptable session characteristics, the receiving PCEP peer MUST
+      send a PCErr message with Error-Type=1, Error-value=6.
+
+      If neither a Keepalive message nor a PCErr message is received
+      before the expiration of the KeepWait timer during the PCEP
+      session establishment phase, the receiving PCEP peer MUST send a
+      PCErr message with Error-Type=1, Error-value=7.
+
+   Error-Type=2:  the PCE indicates that the path computation request
+      cannot be honored because it does not support one or more required
+      capability.  The corresponding path computation request MUST be
+      cancelled.
+
+   Error-Type=3 or Error-Type=4:  if a PCEP message is received that
+      carries a PCEP object (with the P flag set) not recognized by the
+      PCE or recognized but not supported, then the PCE MUST send a
+      PCErr message with a PCEP-ERROR object (Error-Type=3 and 4,
+      respectively).  In addition, the PCE MAY include in the PCErr
+      message the unknown or not supported object.  The corresponding
+      path computation request MUST be cancelled by the PCE without
+      further notification.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 52]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Error-Type=5:  if a path computation request is received that is not
+      compliant with an agreed policy between the PCC and the PCE, the
+      PCE MUST send a PCErr message with a PCEP-ERROR object (Error-
+      Type=5).  The corresponding path computation MUST be cancelled.
+      Policy-specific TLVs carried within the PCEP-ERROR object may be
+      defined in other documents to specify the nature of the policy
+      violation.
+
+   Error-Type=6:  if a path computation request is received that does
+      not contain a mandatory object, the PCE MUST send a PCErr message
+      with a PCEP-ERROR object (Error-Type=6).  If there are multiple
+      mandatory objects missing, the PCErr message MUST contain one
+      PCEP-ERROR object per missing object.  The corresponding path
+      computation MUST be cancelled.
+
+   Error-Type=7:  if a PCC sends a synchronized path computation request
+      to a PCE and the PCE does not receive all the synchronized path
+      computation requests listed within the corresponding SVEC object
+      after the expiration of the timer SyncTimer defined in
+      Section 7.13.3, the PCE MUST send a PCErr message with a PCEP-
+      ERROR object (Error-Type=7).  The corresponding synchronized path
+      computation MUST be cancelled.  It is RECOMMENDED for the PCE to
+      include the REQ-MISSING TLVs (defined below) that identify the
+      missing requests.
+
+      The REQ-MISSING TLV is compliant with the PCEP TLV format defined
+      in section 7.1 and is comprised of 2 bytes for the type, 2 bytes
+      specifying the TLV length (length of the value portion in bytes),
+      followed by a fixed-length value field of 4 bytes.
+
+         Type:   3
+         Length: 4 bytes
+         Value:  4 bytes that indicate the Request-ID-number that
+                 corresponds to the missing request.
+
+   Error-Type=8:  if a PCC receives a PCRep message related to an
+      unknown path computation request, the PCC MUST send a PCErr
+      message with a PCEP-ERROR object (Error-Type=8).  In addition, the
+      PCC MUST include in the PCErr message the unknown RP object.
+
+   Error-Type=9:  if a PCEP peer detects an attempt from another PCEP
+      peer to establish a second PCEP session, it MUST send a PCErr
+      message with Error-Type=9, Error-value=1.  The existing PCEP
+      session MUST be preserved and all subsequent messages related to
+      the tentative establishment of the second PCEP session MUST be
+      silently ignored.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 53]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Error-Type=10:  if a PCEP peers receives an object with the P flag
+      not set although the P flag must be set according to this
+      specification, it MUST send a PCErr message with Error-Type=10,
+      Error-value=1.
+
+7.16.  LOAD-BALANCING Object
+
+   There are situations where no TE LSP with a bandwidth of X could be
+   found by a PCE although such a bandwidth requirement could be
+   satisfied by a set of TE LSPs such that the sum of their bandwidths
+   is equal to X.  Thus, it might be useful for a PCC to request a set
+   of TE LSPs so that the sum of their bandwidth is equal to X Mbit/s,
+   with potentially some constraints on the number of TE LSPs and the
+   minimum bandwidth of each of these TE LSPs.  Such a request is made
+   by inserting a LOAD-BALANCING object in a PCReq message sent to a
+   PCE.
+
+   The LOAD-BALANCING object is optional.
+
+   LOAD-BALANCING Object-Class is 14.
+
+   LOAD-BALANCING Object-Type is 1.
+
+   The format of the LOAD-BALANCING object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Reserved            |     Flags     |     Max-LSP   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Min-Bandwidth                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 21: LOAD-BALANCING Object Body Format
+
+   Reserved (16 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Flags (8 bits):  No flag is currently defined.  The Flags field MUST
+      be set to zero on transmission and MUST be ignored on receipt.
+
+   Max-LSP (8 bits):  maximum number of TE LSPs in the set.
+
+   Min-Bandwidth (32 bits):  Specifies the minimum bandwidth of each
+      element of the set of TE LSPs.  The bandwidth is encoded in 32
+      bits in IEEE floating point format (see [IEEE.754.1985]),
+      expressed in bytes per second.
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 54]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The LOAD-BALANCING object body has a fixed length of 8 bytes.
+
+   If a PCC requests the computation of a set of TE LSPs so that the sum
+   of their bandwidth is X, the maximum number of TE LSPs is N, and each
+   TE LSP must at least have a bandwidth of B, it inserts a BANDWIDTH
+   object specifying X as the required bandwidth and a LOAD-BALANCING
+   object with the Max-LSP and Min-Bandwidth fields set to N and B,
+   respectively.
+
+7.17.  CLOSE Object
+
+   The CLOSE object MUST be present in each Close message.  There MUST
+   be only one CLOSE object per Close message.  If a Close message is
+   received that contains more than one CLOSE object, the first CLOSE
+   object is the one that must be processed.  Other CLOSE objects MUST
+   be silently ignored.
+
+   CLOSE Object-Class is 15.
+
+   CLOSE Object-Type is 1.
+
+   The format of the CLOSE object body is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Reserved             |      Flags    |    Reason     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                         Optional TLVs                       //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                    Figure 22: CLOSE Object Format
+
+   Reserved (16 bits):  This field MUST be set to zero on transmission
+      and MUST be ignored on receipt.
+
+   Flags (8 bits):  No flags are currently defined.  The Flag field MUST
+      be set to zero on transmission and MUST be ignored on receipt.
+
+   Reason (8 bits):  specifies the reason for closing the PCEP session.
+      The setting of this field is optional.  IANA manages the codespace
+      of the Reason field.  The following values are currently defined:
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 55]
+
+RFC 5440                          PCEP                        March 2009
+
+
+       Reasons
+        Value        Meaning
+          1          No explanation provided
+          2          DeadTimer expired
+          3          Reception of a malformed PCEP message
+          4          Reception of an unacceptable number of unknown
+                     requests/replies
+          5          Reception of an unacceptable number of unrecognized
+                     PCEP messages
+
+   Optional TLVs may be included within the CLOSE object body.  The
+   specification of such TLVs is outside the scope of this document.
+
+8.  Manageability Considerations
+
+   This section follows the guidance of [PCE-MANAGE].
+
+8.1.  Control of Function and Policy
+
+   A PCEP implementation SHOULD allow configuring the following PCEP
+   session parameters on the implementation:
+
+   o  The local Keepalive and DeadTimer (i.e., parameters sent by the
+      PCEP peer in an Open message),
+
+   o  The maximum acceptable remote Keepalive and DeadTimer (i.e.,
+      parameters received from a peer in an Open message),
+
+   o  Whether negotiation is enabled or disabled,
+
+   o  If negotiation is allowed, the minimum acceptable Keepalive and
+      DeadTimer timers received from a PCEP peer,
+
+   o  The SyncTimer,
+
+   o  The maximum number of sessions that can be set up,
+
+   o  The request timer, the amount of time a PCC waits for a reply
+      before resending its path computation requests (potentially to an
+      alternate PCE),
+
+   o  The MAX-UNKNOWN-REQUESTS,
+
+   o  The MAX-UNKNOWN-MESSAGES.
+
+   These parameters may be configured as default parameters for any PCEP
+   session the PCEP speaker participates in, or may apply to a specific
+   session with a given PCEP peer or to a specific group of sessions
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 56]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   with a specific group of PCEP peers.  A PCEP implementation SHOULD
+   allow configuring the initiation of a PCEP session with a selected
+   subset of discovered PCEs.  Note that PCE selection is a local
+   implementation issue.  A PCEP implementation SHOULD allow configuring
+   a specific PCEP session with a given PCEP peer.  This includes the
+   configuration of the following parameters:
+
+   o  The IP address of the PCEP peer,
+
+   o  The PCEP speaker role: PCC, PCE, or both,
+
+   o  Whether the PCEP speaker should initiate the PCEP session or wait
+      for initiation by the peer,
+
+   o  The PCEP session parameters, as listed above, if they differ from
+      the default parameters,
+
+   o  A set of PCEP policies including the type of operations allowed
+      for the PCEP peer (e.g., diverse path computation,
+      synchronization, etc.).
+
+   A PCEP implementation MUST allow restricting the set of PCEP peers
+   that can initiate a PCEP session with the PCEP speaker (e.g., list of
+   authorized PCEP peers, all PCEP peers in the area, all PCEP peers in
+   the AS).
+
+8.2.  Information and Data Models
+
+   A PCEP MIB module is defined in [PCEP-MIB] that describes managed
+   objects for modeling of PCEP communication including:
+
+   o  PCEP client configuration and status,
+
+   o  PCEP peer configuration and information,
+
+   o  PCEP session configuration and information,
+
+   o  Notifications to indicate PCEP session changes.
+
+8.3.  Liveness Detection and Monitoring
+
+   PCEP includes a keepalive mechanism to check the liveliness of a PCEP
+   peer and a notification procedure allowing a PCE to advertise its
+   overloaded state to a PCC.  Also, procedures in order to monitor the
+   liveliness and performances of a given PCE chain (in case of
+   multiple-PCE path computation) are defined in [PCE-MONITOR].
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 57]
+
+RFC 5440                          PCEP                        March 2009
+
+
+8.4.  Verifying Correct Operation
+
+   Verifying the correct operation of a PCEP communication can be
+   performed by monitoring various parameters.  A PCEP implementation
+   SHOULD provide the following parameters:
+
+   o  Response time (minimum, average, and maximum), on a per-PCE-peer
+      basis,
+
+   o  PCEP session failures,
+
+   o  Amount of time the session has been in active state,
+
+   o  Number of corrupted messages,
+
+   o  Number of failed computations,
+
+   o  Number of requests for which no reply has been received after the
+      expiration of a configurable timer and by verifying that at least
+      one path exists that satisfies the set of constraints.
+
+   A PCEP implementation SHOULD log error events (e.g., corrupted
+   messages, unrecognized objects).
+
+8.5.  Requirements on Other Protocols and Functional Components
+
+   PCEP does not put any new requirements on other protocols.  As PCEP
+   relies on the TCP transport protocol, PCEP management can make use of
+   TCP management mechanisms (such as the TCP MIB defined in [RFC4022]).
+
+   The PCE Discovery mechanisms ([RFC5088], [RFC5089]) may have an
+   impact on PCEP.  To avoid that a high frequency of PCE Discoveries/
+   Disappearances triggers a high frequency of PCEP session setups/
+   deletions, it is RECOMMENDED to introduce some dampening for
+   establishment of PCEP sessions.
+
+8.6.  Impact on Network Operation
+
+   In order to avoid any unacceptable impact on network operations, an
+   implementation SHOULD allow a limit to be placed on the number of
+   sessions that can be set up on a PCEP speaker, and MAY allow a limit
+   to be placed on the rate of messages sent by a PCEP speaker and
+   received from a peer.  It MAY also allow sending a notification when
+   a rate threshold is reached.
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 58]
+
+RFC 5440                          PCEP                        March 2009
+
+
+9.  IANA Considerations
+
+   IANA assigns values to the PCEP protocol parameters (messages,
+   objects, TLVs).
+
+   IANA established a new top-level registry to contain all PCEP
+   codepoints and sub-registries.
+
+   The allocation policy for each new registry is by IETF Consensus: new
+   values are assigned through the IETF consensus process (see
+   [RFC5226]).  Specifically, new assignments are made via RFCs approved
+   by the IESG.  Typically, the IESG will seek input on prospective
+   assignments from appropriate persons (e.g., a relevant Working Group
+   if one exists).
+
+9.1.  TCP Port
+
+   PCEP has been registered as TCP port 4189.
+
+9.2.  PCEP Messages
+
+   IANA created a registry for PCEP messages.  Each PCEP message has a
+   message type value.
+
+
+   Value     Meaning                          Reference
+     1        Open                          This document
+     2        Keepalive                     This document
+     3        Path Computation Request      This document
+     4        Path Computation Reply        This document
+     5        Notification                  This document
+     6        Error                         This document
+     7        Close                         This document
+
+9.3.  PCEP Object
+
+   IANA created a registry for PCEP objects.  Each PCEP object has an
+   Object-Class and an Object-Type.
+
+   Object-Class Value   Name                               Reference
+
+          1             OPEN                               This document
+                        Object-Type
+                            1
+
+          2             RP                                 This document
+                        Object-Type
+                            1
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 59]
+
+RFC 5440                          PCEP                        March 2009
+
+
+          3             NO-PATH                            This document
+                        Object-Type
+                            1
+
+          4             END-POINTS                         This document
+                        Object-Type
+                            1: IPv4 addresses
+                            2: IPv6 addresses
+
+          5             BANDWIDTH                          This document
+                        Object-Type
+                          1: Requested bandwidth
+                          2: Bandwidth of an existing TE LSP
+                             for which a reoptimization is performed.
+
+          6             METRIC                             This document
+                        Object-Type
+                            1
+
+          7             ERO                                This document
+                        Object-Type
+                            1
+
+          8             RRO                                This document
+                        Object-Type
+                            1
+
+          9             LSPA                               This document
+                        Object-Type
+                            1
+
+         10             IRO                                This document
+                        Object-Type
+                            1
+
+         11             SVEC                               This document
+                        Object-Type
+                            1
+
+         12             NOTIFICATION                       This document
+                        Object-Type
+                            1
+
+         13             PCEP-ERROR                         This document
+                        Object-Type
+                            1
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 60]
+
+RFC 5440                          PCEP                        March 2009
+
+
+         14             LOAD-BALANCING                     This document
+                        Object-Type
+                            1
+
+         15             CLOSE                              This document
+                        Object-Type
+                            1
+
+9.4.  PCEP Message Common Header
+
+   IANA created a registry to manage the Flag field of the PCEP Message
+   Common Header.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   No bits are currently defined for the PCEP message common header.
+
+9.5.  Open Object Flag Field
+
+   IANA created a registry to manage the Flag field of the OPEN object.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   No bits are currently for the OPEN Object flag field.
+
+9.6.  RP Object
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 61]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   o  Defining RFC
+
+   Several bits are defined for the RP Object flag field in this
+   document.  The following values have been assigned:
+
+   Codespace of the Flag field (RP Object)
+
+     Bit      Description              Reference
+
+      26      Strict/Loose          This document
+      27      Bi-directional        This document
+      28      Reoptimization        This document
+     29-31    Priority              This document
+
+
+9.7.  NO-PATH Object Flag Field
+
+   IANA created a registry to manage the codespace of the NI field and
+   the Flag field of the NO-PATH object.
+
+
+    Value       Meaning                        Reference
+
+      0    No path satisfying the set        This document
+           of constraints could be found
+      1    PCE chain broken                  This document
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   One bit is defined for the NO-PATH Object flag field in this
+   document:
+
+   Codespace of the Flag field (NO-PATH Object)
+
+     Bit      Description                      Reference
+
+      0    Unsatisfied constraint indicated    This document
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 62]
+
+RFC 5440                          PCEP                        March 2009
+
+
+9.8.  METRIC Object
+
+   IANA created a registry to manage the codespace of the T field and
+   the Flag field of the METRIC Object.
+
+   Codespace of the T field (Metric Object)
+
+    Value      Meaning          Reference
+
+      1        IGP metric      This document
+      2        TE metric       This document
+      3        Hop Counts      This document
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   Several bits are defined in this document.  The following values have
+   been assigned:
+
+   Codespace of the Flag field (Metric Object)
+
+     Bit      Description         Reference
+
+      6       Computed metric    This document
+      7       Bound              This document
+
+9.9.  LSPA Object Flag Field
+
+   IANA created a registry to manage the Flag field of the LSPA object.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   One bit is defined for the LSPA Object flag field in this document:
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 63]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Codespace of the Flag field (LSPA Object)
+
+     Bit      Description             Reference
+
+      7    Local Protection Desired   This document
+
+
+9.10.  SVEC Object Flag Field
+
+   IANA created a registry to manage the Flag field of the SVEC object.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   Three bits are defined for the SVEC Object flag field in this
+   document:
+
+   Codespace of the Flag field (SVEC Object)
+
+     Bit      Description      Reference
+
+      21      SRLG Diverse     This document
+      22      Node Diverse     This document
+      23      Link Diverse     This document
+
+9.11.  NOTIFICATION Object
+
+   IANA created a registry for the Notification-type and Notification-
+   value of the NOTIFICATION object and manages the code space.
+
+   Notification-type  Name                                 Reference
+         1            Pending Request cancelled            This document
+                      Notification-value
+                        1: PCC cancels a set of pending requests
+                        2: PCE cancels a set of pending requests
+
+         2            Overloaded PCE                       This document
+                      Notification-value
+                        1: PCE in congested state
+                        2: PCE no longer in congested state
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 64]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   IANA created a registry to manage the Flag field of the NOTIFICATION
+   object.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   No bits are currently for the Flag Field of the NOTIFICATION object.
+
+9.12.  PCEP-ERROR Object
+
+   IANA created a registry for the Error-Type and Error-value of the
+   PCEP Error Object and manages the code space.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 65]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   For each PCEP error, an Error-Type and an Error-value are defined.
+
+Error-  Meaning                                           Reference
+Type
+  1     PCEP session establishment failure                This document
+        Error-value=1: reception of an invalid Open message or
+                       a non Open message.
+        Error-value=2: no Open message received before the expiration
+                       of the OpenWait timer
+        Error-value=3: unacceptable and non-negotiable session
+                       characteristics
+        Error-value=4: unacceptable but negotiable session
+                       characteristics
+        Error-value=5: reception of a second Open message with
+                       still unacceptable session characteristics
+        Error-value=6: reception of a PCErr message proposing
+                       unacceptable session characteristics
+        Error-value=7: No Keepalive or PCErr message received
+                       before the expiration of the KeepWait timer
+        Error-value=8: PCEP version not supported
+  2     Capability not supported                          This document
+  3     Unknown Object                                    This document
+         Error-value=1: Unrecognized object class
+         Error-value=2: Unrecognized object Type
+  4     Not supported object                              This document
+         Error-value=1: Not supported object class
+         Error-value=2: Not supported object Type
+  5     Policy violation                                  This document
+         Error-value=1: C bit of the METRIC object set
+                        (request rejected)
+         Error-value=2: O bit of the RP object cleared
+                        (request rejected)
+  6     Mandatory Object missing                          This document
+         Error-value=1: RP object missing
+         Error-value=2: RRO missing for a reoptimization
+                        request (R bit of the RP object set)
+         Error-value=3: END-POINTS object missing
+  7     Synchronized path computation request missing     This document
+  8     Unknown request reference                         This document
+  9     Attempt to establish a second PCEP session        This document
+ 10     Reception of an invalid object                    This document
+         Error-value=1: reception of an object with P flag
+                        not set although the P flag must be
+                        set according to this specification.
+
+   IANA created a registry to manage the Flag field of the PCEP-ERROR
+   object.
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 66]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   No bits are currently for the Flag Field of the PCEP-ERROR Object.
+
+9.13.  LOAD-BALANCING Object Flag Field
+
+   IANA created a registry to manage the Flag field of the LOAD-
+   BALANCING object.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   No bits are currently for the Flag Field of the LOAD-BALANCING
+   Object.
+
+9.14.  CLOSE Object
+
+   The CLOSE object MUST be present in each Close message in order to
+   close a PCEP session.  The reason field of the CLOSE object specifies
+   the reason for closing the PCEP session.  The reason field of the
+   CLOSE object is managed by IANA.
+
+   Reasons
+
+    Value        Meaning
+      1          No explanation provided
+      2          DeadTimer expired
+      3          Reception of a malformed PCEP message
+      4          Reception of an unacceptable number of unknown
+                 requests/replies
+      5          Reception of an unacceptable number of unrecognized
+                 PCEP messages
+
+   IANA created a registry to manage the flag field of the CLOSE object.
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 67]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Capability description
+
+   o  Defining RFC
+
+   No bits are currently for the Flag Field of the CLOSE Object.
+
+9.15.  PCEP TLV Type Indicators
+
+   IANA created a registry for the PCEP TLVs.
+
+    Value         Meaning                    Reference
+
+      1          NO-PATH-VECTOR TLV         This document
+      2          OVERLOAD-DURATION TLV      This document
+      3          REQ-MISSING TLV            This document
+
+9.16.  NO-PATH-VECTOR TLV
+
+   IANA manages the space of flags carried in the NO-PATH-VECTOR TLV
+   defined in this document, numbering them from 0 as the least
+   significant bit.
+
+   New bit numbers may be allocated only by an IETF Consensus action.
+
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit)
+
+   o  Name flag
+
+   o  Reference
+
+   Bit Number       Name                         Reference
+     31             PCE currently unavailable    This document
+     30             Unknown destination          This document
+     29             Unknown source               This document
+
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 68]
+
+RFC 5440                          PCEP                        March 2009
+
+
+10.  Security Considerations
+
+10.1.  Vulnerability
+
+   Attacks on PCEP may result in damage to active networks.  If path
+   computation responses are changed, the PCC may be encouraged to set
+   up inappropriate LSPs.  Such LSPs might deviate to parts of the
+   network susceptible to snooping, or might transit congested or
+   reserved links.  Path computation responses may be attacked by
+   modification of the PCRep message, by impersonation of the PCE, or by
+   modification of the PCReq to cause the PCE to perform a different
+   computation from that which was originally requested.
+
+   It is also possible to damage the operation of a PCE through a
+   variety of denial-of-service attacks.  Such attacks can cause the PCE
+   to become congested with the result that path computations are
+   supplied too slowly to be of value for PCCs.  This could lead to
+   slower-than-acceptable recovery times or delayed LSP establishment.
+   In extreme cases, it may be that service requests are not satisfied.
+
+   PCEP could be the target of the following attacks:
+
+   o  Spoofing (PCC or PCE impersonation)
+
+   o  Snooping (message interception)
+
+   o  Falsification
+
+   o  Denial of Service
+
+   In inter-AS scenarios when PCE-to-PCE communication is required,
+   attacks may be particularly significant with commercial as well as
+   service-level implications.
+
+   Additionally, snooping of PCEP requests and responses may give an
+   attacker information about the operation of the network.  Simply by
+   viewing the PCEP messages someone can determine the pattern of
+   service establishment in the network and can know where traffic is
+   being routed, thereby making the network susceptible to targeted
+   attacks and the data within specific LSPs vulnerable.
+
+   The following sections identify mechanisms to protect PCEP against
+   security attacks.
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 69]
+
+RFC 5440                          PCEP                        March 2009
+
+
+10.2.  TCP Security Techniques
+
+   At the time of writing, TCP-MD5 [RFC2385] is the only available
+   security mechanism for securing the TCP connections that underly PCEP
+   sessions.
+
+   As explained in [RFC2385], the use of MD5 faces some limitations and
+   does not provide as high a level of security as was once believed.  A
+   PCEP implementation supporting TCP-MD5 SHOULD be designed so that
+   stronger security keying techniques or algorithms that may be
+   specified for TCP can be easily integrated in future releases.
+
+   The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
+   security procedures for TCP, but is not yet complete.  Since it is
+   believed that [TCP-AUTH] will offer significantly improved security
+   for applications using TCP, implementers should expect to update
+   their implementation as soon as the TCP Authentication Option is
+   published as an RFC.
+
+   Implementations MUST support TCP-MD5 and should make the security
+   function available as a configuration option.
+
+   Operators will need to observe that some deployed PCEP
+   implementations may pre-date the completion of [TCP-AUTH], and it
+   will be necessary to configure policy for secure communication
+   between PCEP speakers that support the TCP Authentication Option, and
+   those that don't.
+
+   An alternative approach for security over TCP transport is to use the
+   Transport Layer Security (TLS) protocol [RFC5246].  This provides
+   protection against eavesdropping, tampering, and message forgery.
+   But TLS doesn't protect the TCP connection itself, because it does
+   not authenticate the TCP header.  Thus, it is vulnerable to attacks
+   such as TCP reset attacks (something against which TCP-MD5 does
+   protect).  The use of TLS would, however, require the specification
+   of how PCEP initiates TLS handshaking and how it interprets the
+   certificates exchanged in TLS.  That specification is out of the
+   scope of this document, but could be the subject of future work.
+
+10.3.  PCEP Authentication and Integrity
+
+   Authentication and integrity checks allow the receiver of a PCEP
+   message to know that the message genuinely comes from the node that
+   purports to have sent it and to know whether the message has been
+   modified.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 70]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   The TCP-MD5 mechanism [RFC2385] described in the previous section
+   provides such a mechanism subject to the concerns listed in [RFC2385]
+   and [RFC4278].  These issues will be addressed and resolved by
+   [TCP-AUTH].
+
+10.4.  PCEP Privacy
+
+   Ensuring PCEP communication privacy is of key importance, especially
+   in an inter-AS context, where PCEP communication end-points do not
+   reside in the same AS, as an attacker that intercepts a PCE message
+   could obtain sensitive information related to computed paths and
+   resources.
+
+   PCEP privacy can be ensured by encryption.  TCP MAY be run over IPsec
+   [RFC4303] tunnels to provide the required encryption.  Note that
+   IPsec can also ensure authentication and integrity; in which case,
+   TCP-MD5 or TCP-AO would not be required.  However, there is some
+   concern that IPsec on this scale would be hard to configure and
+   operate.  Use of IPSec with PCEP is out of the scope of this document
+   and may be addressed in a separate document.
+
+10.5.  Key Configuration and Exchange
+
+   Authentication, tamper protection, and encryption all require the use
+   of keys by sender and receiver.
+
+   Although key configuration per session is possible, it may be
+   particularly onerous to operators (in the same way as for the Border
+   Gateway Protocol (BGP) as discussed in [BGP-SEC]).  If there is a
+   relatively small number of PCCs and PCEs in the network, manual key
+   configuration MAY be considered a valid choice by the operator,
+   although it is important to be aware of the vulnerabilities
+   introduced by such mechanisms (i.e., configuration errors, social
+   engineering, and carelessness could all give rise to security
+   breaches).  Furthermore, manually configured keys are less likely to
+   be regularly updated which also increases the security risk.  Where
+   there is a large number of PCCs and PCEs, the operator could find
+   that key configuration and maintenance is a significant burden as
+   each PCC needs to be configured to the PCE.
+
+   An alternative to individual keys is the use of a group key.  A group
+   key is common knowledge among all members of a trust domain.  Thus,
+   since the routers in an IGP area or an AS are part of a common trust
+   domain [MPLS-SEC], a PCEP group key MAY be shared among all PCCs and
+   PCEs in an IGP area or AS.  The use of a group key will considerably
+   simplify the operator's configuration task while continuing to secure
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 71]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   PCEP against attack from outside the network.  However, it must be
+   noted that the more entities that have access to a key, the greater
+   the risk of that key becoming public.
+
+   With the use of a group key, separate keys would need to be
+   configured for the PCE-to-PCE communications that cross trust domain
+   (e.g., AS) boundaries, but the number of these relationships is
+   likely to be very small.
+
+   PCE discovery ([RFC5088] and [RFC5089]) is a significant feature for
+   the successful deployment of PCEP in large networks.  This mechanism
+   allows a PCC to discover the existence of suitable PCEs within the
+   network without the necessity of configuration.  It should be obvious
+   that, where PCEs are discovered and not configured, the PCC cannot
+   know the correct key to use.  There are three possible approaches to
+   this problem that retain some aspect of security:
+
+   o  The PCCs may use a group key as previously discussed.
+
+   o  The PCCs may use some form of secure key exchange protocol with
+      the PCE (such as the Internet Key Exchange protocol v2 (IKE)
+      [RFC4306]).  The drawback to this is that IKE implementations on
+      routers are not common and this may be a barrier to the deployment
+      of PCEP.  Details are out of the scope of this document and may be
+      addressed in a separate document.
+
+   o  The PCCs may make use of a key server to determine the key to use
+      when talking to the PCE.  To some extent, this is just moving the
+      problem, since the PCC's communications with the key server must
+      also be secure (for example, using Kerberos [RFC4120]), but there
+      may some (minor) benefit in scaling if the PCC is to learn about
+      several PCEs and only needs to know one key server.  Note that key
+      servers currently have very limited implementation.  Details are
+      out of the scope of this document and may be addressed in a
+      separate document.
+
+   PCEP relationships are likely to be long-lived even if the PCEP
+   sessions are repeatedly closed and re-established.  Where protocol
+   relationships persist for a large number of protocol interactions or
+   over a long period of time, changes in the keys used by the protocol
+   peers is RECOMMENDED [RFC4107].  Note that TCP-MD5 does not allow the
+   key to be changed without closing and reopening the TCP connection
+   which would result in the PCEP session being terminated and needing
+   to be restarted.  That might not be a significant issue for PCEP.
+   Note also that the plans for the TCP Authentication Option [TCP-AUTH]
+   will allow dynamic key change (roll-over) for an active TCP
+   connection.
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 72]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   If key exchange is used (for example, through IKE), then it is
+   relatively simple to support dynamic key updates and apply these to
+   PCEP.
+
+   Note that in-band key management for the TCP Authentication Option
+   [TCP-AUTH] is currently unresolved.
+
+   [RFC3562] sets out some of the issues for the key management of
+   secure TCP connections.
+
+10.6.  Access Policy
+
+   Unauthorized access to PCE function represents a variety of potential
+   attacks.  Not only may this be a simple denial-of-service attack (see
+   Section 10.7), but it would be a mechanism for an intruder to
+   determine important information about the network and operational
+   network policies simply by inserting bogus computation requests.
+   Furthermore, false computation requests could be used to predict
+   where traffic will be placed in the network when real requests are
+   made, allowing the attacker to target specific network resources.
+
+   PCEs SHOULD be configurable for access policy.  Where authentication
+   is used, access policy can be achieved through the exchange or
+   configuration of keys as described in Section 10.5.  More simple
+   policies MAY be configured on PCEs in the form of access lists where
+   the IP addresses of the legitimate PCCs are listed.  Policies SHOULD
+   also be configurable to limit the type of computation requests that
+   are supported from different PCCs.
+
+   It is RECOMMENDED that access policy violations are logged by the PCE
+   and are available for inspection by the operator to determine whether
+   attempts have been made to attack the PCE.  Such mechanisms MUST be
+   lightweight to prevent them from being used to support denial-of-
+   service attacks (see Section 10.7).
+
+10.7.  Protection against Denial-of-Service Attacks
+
+   Denial-of-service (DoS) attacks could be mounted at the TCP level or
+   at the PCEP level.  That is, the PCE could be attacked through
+   attacks on TCP or through attacks within established PCEP sessions.
+
+10.7.1.  Protection against TCP DoS Attacks
+
+   PCEP can be the target of TCP DoS attacks, such as for instance SYN
+   attacks, as is the case for all protocols that run over TCP.  Other
+   protocol specifications have investigated this problem and PCEP can
+   share their experience.  The reader is referred to the specification
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 73]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   of the Label Distribution Protocol (LDP) [RFC5036] for example.  In
+   order to protect against TCP DoS attacks, PCEP implementations can
+   support the following techniques.
+
+   o  PCEP uses a single registered port for all communications.  The
+      PCE SHOULD listen for TCP connections only on ports where
+      communication is expected.
+
+   o  The PCE MAY implement an access list to immediately reject (or
+      discard) TCP connection attempts from unauthorized PCCs.
+
+   o  The PCE SHOULD NOT allow parallel TCP connections from the same
+      PCC on the PCEP-registered port.
+
+   o  The PCE MAY require the use of the MD5 option on all TCP
+      connections, and MAY reject (or discard) any connection setup
+      attempt that does not use MD5.  A PCE MUST NOT accept any SYN
+      packet for which the MD5 segment checksum is invalid.  Note,
+      however, that the use of MD5 requires that the receiver use CPU
+      resources to compute the checksum before it can decide to discard
+      an otherwise acceptable SYN segment.
+
+10.7.2.  Request Input Shaping/Policing
+
+   A PCEP implementation may be subject to DoS attacks within a
+   legitimate PCEP session.  For example, a PCC might send a very large
+   number of PCReq messages causing the PCE to become congested or
+   causing requests from other PCCs to be queued.
+
+   Note that the direct use of the Priority field on the RP object to
+   prioritize received requests does not provide any protection since
+   the attacker could set all requests to be of the highest priority.
+
+   Therefore, it is RECOMMENDED that PCE implementations include input
+   shaping/policing mechanisms that either throttle the requests
+   received from any one PCC, or apply queuing or priority-degradation
+   techniques to over-communicative PCCs.
+
+   Such mechanisms MAY be set by default, but SHOULD be available for
+   configuration.  Such techniques may be considered particularly
+   important in multi-service-provider environments to protect the
+   resources of one service provider from unwarranted, over-zealous, or
+   malicious use by PCEs in another service provider.
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 74]
+
+RFC 5440                          PCEP                        March 2009
+
+
+11.  Acknowledgments
+
+   The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash,
+   Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard
+   Douville, Jon Parker, Martin German, and Dennis Aristow for their
+   very valuable input.  The authors would also like to thank Fabien
+   Verhaeghe for the very fruitful discussions and useful suggestions.
+   David McGrew and Brian Weis provided valuable input to the Security
+   Considerations section.
+
+   Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk,
+   Chris Newman, and Russ Housley provided important input during IESG
+   review.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
+                    Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2205]        Braden, B., Zhang, L., Berson, S., Herzog, S., and
+                    S. Jamin, "Resource ReSerVation Protocol (RSVP) --
+                    Version 1 Functional Specification", RFC 2205,
+                    September 1997.
+
+   [RFC2385]        Heffernan, A., "Protection of BGP Sessions via the
+                    TCP MD5 Signature Option", RFC 2385, August 1998.
+
+   [RFC3209]        Awduche, D., Berger, L., Gan, D., Li, T.,
+                    Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
+                    to RSVP for LSP Tunnels", RFC 3209, December 2001.
+
+   [RFC3473]        Berger, L., "Generalized Multi-Protocol Label
+                    Switching (GMPLS) Signaling Resource ReserVation
+                    Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                    RFC 3473, January 2003.
+
+   [RFC3477]        Kompella, K. and Y. Rekhter, "Signalling Unnumbered
+                    Links in Resource ReSerVation Protocol - Traffic
+                    Engineering (RSVP-TE)", RFC 3477, January 2003.
+
+   [RFC4090]        Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+                    Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+                    May 2005.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 75]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   [RFC5226]        Narten, T. and H. Alvestrand, "Guidelines for
+                    Writing an IANA Considerations Section in RFCs",
+                    BCP 26, RFC 5226, May 2008.
+
+12.2.  Informative References
+
+   [BGP-SEC]        Christian, B. and T. Tauber, "BGP Security
+                    Requirements", Work in Progress, November 2008.
+
+   [IEEE.754.1985]  IEEE Standard 754, "Standard for Binary Floating-
+                    Point Arithmetic", August 1985.
+
+   [INTER-LAYER]    Oki, E., Roux, J., Kumaki, K., Farrel, A., and T.
+                    Takeda, "PCC-PCE Communication and PCE Discovery
+                    Requirements for Inter-Layer Traffic Engineering",
+                    Work in Progress, January 2009.
+
+   [MPLS-SEC]       Fang, L. and M. Behringer, "Security Framework for
+                    MPLS and GMPLS Networks", Work in Progress,
+                    November 2008.
+
+   [PCE-MANAGE]     Farrel, A., "Inclusion of Manageability Sections in
+                    PCE Working Group Drafts", Work in Progress,
+                    January 2009.
+
+   [PCE-MONITOR]    Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
+                    monitoring tools for Path Computation Element based
+                    Architecture", Work in Progress, November 2008.
+
+   [PCEP-MIB]       Stephan, E. and K. Koushik, "PCE communication
+                    protocol (PCEP) Management Information Base",
+                    Work in Progress, November 2008.
+
+   [RBNF]           Farrel, A., "Reduced Backus-Naur Form (RBNF) A
+                    Syntax Used in Various Protocol Specifications",
+                    Work in Progress, November 2008.
+
+   [RFC1321]        Rivest, R., "The MD5 Message-Digest Algorithm",
+                    RFC 1321, April 1992.
+
+   [RFC3471]        Berger, L., "Generalized Multi-Protocol Label
+                    Switching (GMPLS) Signaling Functional Description",
+                    RFC 3471, January 2003.
+
+   [RFC3562]        Leech, M., "Key Management Considerations for the
+                    TCP MD5 Signature Option", RFC 3562, July 2003.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 76]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   [RFC3785]        Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx,
+                    P., and T. Telkamp, "Use of Interior Gateway
+                    Protocol (IGP) Metric as a second MPLS Traffic
+                    Engineering (TE) Metric", BCP 87, RFC 3785,
+                    May 2004.
+
+   [RFC4022]        Raghunarayan, R., "Management Information Base for
+                    the Transmission Control Protocol (TCP)", RFC 4022,
+                    March 2005.
+
+   [RFC4101]        Rescorla, E. and IAB, "Writing Protocol Models",
+                    RFC 4101, June 2005.
+
+   [RFC4107]        Bellovin, S. and R. Housley, "Guidelines for
+                    Cryptographic Key Management", BCP 107, RFC 4107,
+                    June 2005.
+
+   [RFC4120]        Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
+                    "The Kerberos Network Authentication Service (V5)",
+                    RFC 4120, July 2005.
+
+   [RFC4278]        Bellovin, S. and A. Zinin, "Standards Maturity
+                    Variance Regarding the TCP MD5 Signature Option (RFC
+                    2385) and the BGP-4 Specification", RFC 4278,
+                    January 2006.
+
+   [RFC4303]        Kent, S., "IP Encapsulating Security Payload (ESP)",
+                    RFC 4303, December 2005.
+
+   [RFC4306]        Kaufman, C., "Internet Key Exchange (IKEv2)
+                    Protocol", RFC 4306, December 2005.
+
+   [RFC5420]        Farrel, A., Ed., Papadimitriou, D., Vasseur, JP.,
+                    and A. Ayyangarps, "Encoding of Attributes for MPLS
+                    LSP Establishment Using Resource Reservation
+                    Protocol Traffic Engineering (RSVP-TE)", RFC 5420,
+                    February 2009.
+
+   [RFC4655]        Farrel, A., Vasseur, J., and J. Ash, "A Path
+                    Computation Element (PCE)-Based Architecture",
+                    RFC 4655, August 2006.
+
+   [RFC4657]        Ash, J. and J. Le Roux, "Path Computation Element
+                    (PCE) Communication Protocol Generic Requirements",
+                    RFC 4657, September 2006.
+
+   [RFC4674]        Le Roux, J., "Requirements for Path Computation
+                    Element (PCE) Discovery", RFC 4674, October 2006.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 77]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   [RFC4927]        Le Roux, J., "Path Computation Element Communication
+                    Protocol (PCECP) Specific Requirements for Inter-
+                    Area MPLS and GMPLS Traffic Engineering", RFC 4927,
+                    June 2007.
+
+   [RFC5036]        Andersson, L., Minei, I., and B. Thomas, "LDP
+                    Specification", RFC 5036, October 2007.
+
+   [RFC5088]        Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R.
+                    Zhang, "OSPF Protocol Extensions for Path
+                    Computation Element (PCE) Discovery", RFC 5088,
+                    January 2008.
+
+   [RFC5089]        Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R.
+                    Zhang, "IS-IS Protocol Extensions for Path
+                    Computation Element (PCE) Discovery", RFC 5089,
+                    January 2008.
+
+   [RFC5246]        Dierks, T. and E. Rescorla, "The Transport Layer
+                    Security (TLS) Protocol Version 1.2", RFC 5246,
+                    August 2008.
+
+   [RFC5376]        Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
+                    Requirements for the Path Computation Element
+                    Communication Protocol (PCECP)", RFC 5376,
+                    November 2008.
+
+   [TCP-AUTH]       Touch, J., Mankin, A., and R. Bonica, "The TCP
+                    Authentication Option", Work in Progress,
+                    November 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 78]
+
+RFC 5440                          PCEP                        March 2009
+
+
+Appendix A.  PCEP Finite State Machine (FSM)
+
+   The section describes the PCEP finite state machine (FSM).  PCEP
+   Finite State Machine
+
+                          +-+-+-+-+-+-+<------+
+                   +------| SessionUP |<---+  |
+                   |      +-+-+-+-+-+-+    |  |
+                   |                       |  |
+                   |   +->+-+-+-+-+-+-+    |  |
+                   |   |  | KeepWait  |----+  |
+                   |   +--|           |<---+  |
+                   |+-----+-+-+-+-+-+-+    |  |
+                   ||          |           |  |
+                   ||          |           |  |
+                   ||          V           |  |
+                   ||  +->+-+-+-+-+-+-+----+  |
+                   ||  |  | OpenWait  |-------+
+                   ||  +--|           |<------+
+                   ||+----+-+-+-+-+-+-+<---+  |
+                   |||         |           |  |
+                   |||         |           |  |
+                   |||         V           |  |
+                   ||| +->+-+-+-+-+-+-+    |  |
+                   ||| |  |TCPPending |----+  |
+                   ||| +--|           |       |
+                   |||+---+-+-+-+-+-+-+<---+  |
+                   ||||        |           |  |
+                   ||||        |           |  |
+                   ||||        V           |  |
+                   |||+--->+-+-+-+-+       |  |
+                   ||+---->| Idle  |-------+  |
+                   |+----->|       |----------+
+                   +------>+-+-+-+-+
+
+        Figure 23: PCEP Finite State Machine for the PCC
+
+   PCEP defines the following set of variables:
+
+   Connect:  the timer (in seconds) started after having initialized a
+      TCP connection using the PCEP-registered TCP port.  The value of
+      the Connect timer is 60 seconds.
+
+   ConnectRetry:  the number of times the system has tried to establish
+      a TCP connection with a PCEP peer without success.
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 79]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   ConnectMaxRetry:  the maximum number of times the system tries to
+      establish a TCP connection using the PCEP-registered TCP port
+      before going back to the Idle state.  The value of the
+      ConnectMaxRetry is 5.
+
+   OpenWait:  the timer that corresponds to the amount of time a PCEP
+      peer will wait to receive an Open message from the PCEP peer after
+      the expiration of which the system releases the PCEP resource and
+      goes back to the Idle state.  The OpenWait timer has a fixed value
+      of 60 seconds.
+
+   KeepWait:  the timer that corresponds to the amount of time a PCEP
+      peer will wait to receive a Keepalive or a PCErr message from the
+      PCEP peer after the expiration of which the system releases the
+      PCEP resource and goes back to the Idle state.  The KeepWait timer
+      has a fixed value of 60 seconds.
+
+   OpenRetry:  the number of times the system has received an Open
+      message with unacceptable PCEP session characteristics.
+
+   The following two state variables are defined:
+
+   RemoteOK:  a boolean that is set to 1 if the system has received an
+      acceptable Open message.
+
+   LocalOK:  a boolean that is set to 1 if the system has received a
+      Keepalive message acknowledging that the Open message sent to the
+      peer was valid.
+
+   Idle State:
+
+   The idle state is the initial PCEP state where the PCEP (also
+   referred to as "the system") waits for an initialization event that
+   can either be manually triggered by the user (configuration) or
+   automatically triggered by various events.  In Idle state, PCEP
+   resources are allocated (memory, potential process, etc.) but no PCEP
+   messages are accepted from any PCEP peer.  The system listens to the
+   PCEP-registered TCP port.
+
+   The following set of variables are initialized:
+
+      TCPRetry=0,
+
+      LocalOK=0,
+
+      RemoteOK=0,
+
+      OpenRetry=0.
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 80]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Upon detection of a local initialization event (e.g., user
+   configuration to establish a PCEP session with a particular PCEP
+   peer, local event triggering the establishment of a PCEP session with
+   a PCEP peer such as the automatic detection of a PCEP peer), the
+   system:
+
+   o  Initiates a TCP connection with the PCEP peer,
+
+   o  Starts the Connect timer,
+
+   o  Moves to the TCPPending state.
+
+   Upon receiving a TCP connection on the PCEP-registered TCP port, if
+   the TCP connection establishment succeeds, the system:
+
+   o  Sends an Open message,
+
+   o  Starts the OpenWait timer,
+
+   o  Moves to the OpenWait state.
+
+   If the connection establishment fails, the system remains in the Idle
+   state.  Any other event received in the Idle state is ignored.
+
+   It is expected that an implementation will use an exponentially
+   increasing timer between automatically generated Initialization
+   events and between retries of TCP connection establishment.
+
+   TCPPending State:
+
+   If the TCP connection establishment succeeds, the system:
+
+   o  Sends an Open message,
+
+   o  Starts the OpenWait timer,
+
+   o  Moves to the OpenWait state.
+
+   If the TCP connection establishment fails (an error is detected
+   during the TCP connection establishment) or the Connect timer
+   expires:
+
+   o  If ConnectRetry = ConnectMaxRetry, the system moves to the Idle
+      State.
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 81]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   o  If ConnectRetry < ConnectMaxRetry, the system:
+
+      1.  Initiates of a TCP connection with the PCEP peer,
+
+      2.  Increments the ConnectRetry variable,
+
+      3.  Restarts the Connect timer,
+
+      4.  Stays in the TCPPending state.
+
+   In response to any other event, the system releases the PCEP
+   resources for that peer and moves back to the Idle state.
+
+   OpenWait State:
+
+   In the OpenWait state, the system waits for an Open message from its
+   PCEP peer.
+
+   If the system receives an Open message from the PCEP peer before the
+   expiration of the OpenWait timer, the system first examines all of
+   its sessions that are in the OpenWait or KeepWait state.  If another
+   session with the same PCEP peer already exists (same IP address),
+   then the system performs the following collision-resolution
+   procedure:
+
+   o  If the system has initiated the current session and it has a lower
+      IP address than the PCEP peer, the system closes the TCP
+      connection, releases the PCEP resources for the pending session,
+      and moves back to the Idle state.
+
+   o  If the session was initiated by the PCEP peer and the system has a
+      higher IP address that the PCEP peer, the system closes the TCP
+      connection, releases the PCEP resources for the pending session,
+      and moves back to the Idle state.
+
+   o  Otherwise, the system checks the PCEP session attributes
+      (Keepalive frequency, DeadTimer, etc.).
+
+   If an error is detected (e.g., malformed Open message, reception of a
+   message that is not an Open message, presence of two OPEN objects),
+   PCEP generates an error notification, the PCEP peer sends a PCErr
+   message with Error-Type=1 and Error-value=1.  The system releases the
+   PCEP resources for the PCEP peer, closes the TCP connection, and
+   moves to the Idle state.
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 82]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   If no errors are detected, OpenRetry=1, and the session
+   characteristics are unacceptable, the PCEP peer sends a PCErr with
+   Error-Type=1 and Error-value=5, and the system releases the PCEP
+   resources for that peer and moves back to the Idle state.
+
+   If no errors are detected, and the session characteristics are
+   acceptable to the local system, the system:
+
+   o  Sends a Keepalive message to the PCEP peer,
+
+   o  Starts the Keepalive timer,
+
+   o  Sets the RemoteOK variable to 1.
+
+   If LocalOK=1, the system clears the OpenWait timer and moves to the
+   UP state.
+
+   If LocalOK=0, the system clears the OpenWait timer, starts the
+   KeepWait timer, and moves to the KeepWait state.
+
+   If no errors are detected, but the session characteristics are
+   unacceptable and non-negotiable, the PCEP peer sends a PCErr with
+   Error-Type=1 and Error-value=3, and the system releases the PCEP
+   resources for that peer and moves back to the Idle state.
+
+   If no errors are detected, and OpenRetry is 0, and the session
+   characteristics are unacceptable but negotiable (such as, the
+   Keepalive period or the DeadTimer), then the system:
+
+   o  Increments the OpenRetry variable,
+
+   o  Sends a PCErr message with Error-Type=1 and Error-value=4 that
+      contains proposed acceptable session characteristics,
+
+   o  If LocalOK=1, the system restarts the OpenWait timer and stays in
+      the OpenWait state.
+
+   o  If LocalOK=0, the system clears the OpenWait timer, starts the
+      KeepWait timer, and moves to the KeepWait state.
+
+   If no Open message is received before the expiration of the OpenWait
+   timer, the PCEP peer sends a PCErr message with Error-Type=1 and
+   Error-value=2, the system releases the PCEP resources for the PCEP
+   peer, closes the TCP connection, and moves to the Idle state.
+
+   In response to any other event, the system releases the PCEP
+   resources for that peer and moves back to the Idle state.
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 83]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   KeepWait State:
+
+   In the Keepwait state, the system waits for the receipt of a
+   Keepalive from its PCEP peer acknowledging its Open message or a
+   PCErr message in response to unacceptable PCEP session
+   characteristics proposed in the Open message.
+
+   If an error is detected (e.g., malformed Keepalive message), PCEP
+   generates an error notification, the PCEP peer sends a PCErr message
+   with Error-Type=1 and Error-value=1.  The system releases the PCEP
+   resources for the PCEP peer, closes the TCP connection, and moves to
+   the Idle state.
+
+   If a Keepalive message is received before the expiration of the
+   KeepWait timer, then the system sets LocalOK=1 and:
+
+   o  If RemoteOK=1, the system clears the KeepWait timer and moves to
+      the UP state.
+
+   o  If RemoteOK=0, the system clears the KeepWait timer, starts the
+      OpenWait timer, and moves to the OpenWait State.
+
+   If a PCErr message is received before the expiration of the KeepWait
+   timer:
+
+   1.  If the proposed values are unacceptable, the PCEP peer sends a
+       PCErr message with Error-Type=1 and Error-value=6, and the system
+       releases the PCEP resources for that PCEP peer, closes the TCP
+       connection, and moves to the Idle state.
+
+   2.  If the proposed values are acceptable, the system adjusts its
+       PCEP session characteristics according to the proposed values
+       received in the PCErr message, restarts the KeepWait timer, and
+       sends a new Open message.  If RemoteOK=1, the system restarts the
+       KeepWait timer and stays in the KeepWait state.  If RemoteOK=0,
+       the system clears the KeepWait timer, starts the OpenWait timer,
+       and moves to the OpenWait state.
+
+   If neither a Keepalive nor a PCErr is received after the expiration
+   of the KeepWait timer, the PCEP peer sends a PCErr message with
+   Error-Type=1 and Error-value=7, and the system releases the PCEP
+   resources for that PCEP peer, closes the TCP connection, and moves to
+   the Idle State.
+
+   In response to any other event, the system releases the PCEP
+   resources for that peer and moves back to the Idle state.
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 84]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   UP State:
+
+   In the UP state, the PCEP peer starts exchanging PCEP messages
+   according to the session characteristics.
+
+   If the Keepalive timer expires, the system restarts the Keepalive
+   timer and sends a Keepalive message.
+
+   If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from
+   the PCEP peer before the expiration of the DeadTimer, the system
+   terminates the PCEP session according to the procedure defined in
+   Section 6.8, releases the PCEP resources for that PCEP peer, closes
+   the TCP connection, and moves to the Idle State.
+
+   If a malformed message is received, the system terminates the PCEP
+   session according to the procedure defined in Section 6.8, releases
+   the PCEP resources for that PCEP peer, closes the TCP connection and
+   moves to the Idle State.
+
+   If the system detects that the PCEP peer tries to set up a second TCP
+   connection, it stops the TCP connection establishment and sends a
+   PCErr with Error-Type=9.
+
+   If the TCP connection fails, the system releases the PCEP resources
+   for that PCEP peer, closes the TCP connection, and moves to the Idle
+   State.
+
+Appendix B.  PCEP Variables
+
+   PCEP defines the following configurable variables:
+
+   Keepalive timer:  minimum period of time between the sending of PCEP
+      messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer.  A
+      suggested value for the Keepalive timer is 30 seconds.
+
+   DeadTimer:  period of timer after the expiration of which a PCEP peer
+      declares the session down if no PCEP message has been received.
+
+   SyncTimer:  timer used in the case of synchronized path computation
+      request using the SVEC object defined in Section 7.13.3.  Consider
+      the case where a PCReq message is received by a PCE that contains
+      the SVEC object referring to M synchronized path computation
+      requests.  If after the expiration of the SyncTimer all the M path
+      computation requests have not been received, a protocol error is
+      triggered and the PCE MUST cancel the whole set of path
+      computation requests.  The aim of the SyncTimer is to avoid the
+      storage of unused synchronized requests should one of them get
+      lost for some reason (e.g., a misbehaving PCC).  Thus, the value
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 85]
+
+RFC 5440                          PCEP                        March 2009
+
+
+      of the SyncTimer must be large enough to avoid the expiration of
+      the timer under normal circumstances.  A RECOMMENDED value for the
+      SyncTimer is 60 seconds.
+
+   MAX-UNKNOWN-REQUESTS:  A RECOMMENDED value is 5.
+
+   MAX-UNKNOWN-MESSAGES:  A RECOMMENDED value is 5.
+
+Appendix C.  Contributors
+
+   The content of this document was contributed by those listed below
+   and the editors listed at the end of the document.
+
+   Arthi Ayyangar
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA  94089
+   USA
+
+   EMail: arthi@juniper.net
+
+
+   Adrian Farrel
+   Old Dog Consulting
+   Phone: +44 (0) 1978 860944
+
+   EMail: adrian@olddog.co.uk
+
+
+   Eiji Oki
+   NTT
+   Midori 3-9-11
+   Musashino, Tokyo,   180-8585
+   JAPAN
+
+   EMail: oki.eiji@lab.ntt.co.jp
+
+
+   Alia Atlas
+   British Telecom
+
+   EMail: akatlas@alum.mit.edu
+
+
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 86]
+
+RFC 5440                          PCEP                        March 2009
+
+
+   Andrew Dolganow
+   Alcatel
+   600 March Road
+   Ottawa, ON  K2K 2E6
+   CANADA
+
+   EMail: andrew.dolganow@alcatel.com
+
+
+   Yuichi Ikejiri
+   NTT Communications Corporation
+   1-1-6 Uchisaiwai-cho, Chiyoda-ku
+   Tokyo,   100-819
+   JAPAN
+
+   EMail: y.ikejiri@ntt.com
+
+
+   Kenji Kumaki
+   KDDI Corporation
+   Garden Air Tower Iidabashi, Chiyoda-ku,
+   Tokyo,   102-8460
+   JAPAN
+
+   EMail: ke-kumaki@kddi.com
+
+Authors' Addresses
+
+   JP Vasseur (editor)
+   Cisco Systems
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   USA
+
+   EMail: jpv@cisco.com
+
+
+   JL Le Roux (editor)
+   France Telecom
+   2, Avenue Pierre-Marzin
+   Lannion  22307
+   FRANCE
+
+   EMail: jeanlouis.leroux@orange-ftgroup.com
+
+
+
+
+
+
+
+Vasseur & Le Roux           Standards Track                    [Page 87]
+