Network
Networking Working Group                      JP Vasseur (Editor)                                JP. Vasseur, Ed.
Internet-Draft                                        Cisco System Inc.
     IETF Internet Draft                                 JL Systems, Inc
Expires: August 28, 2006                                     JL. Le Roux
                                                          France Telecom
                                                     Arthi
                                                             A. Ayyangar
                                                        Juniper Networks
                                                           Eiji
                                                                  E. Oki
                                                     Yuichi Ikejiri
                                                                     NTT
                                                         Alia
                                                                A. Atlas
                                                        Google, Inc
                                                   Andrew
                                                                  Google
                                                             A. Dolganow
                                                                 Alcatel
     Proposed Status: Standard
     Expires: May
                                                              Y. Ikejiri
                                          NTT Communications Corporation
                                                               K. Kumaki
                                                        KDDI Corporation
                                                       February 24, 2006                               November 2005

Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 -

                         draft-ietf-pce-pcep-00.txt

                       draft-ietf-pce-pcep-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2006.

Copyright Notice
   Copyright (C) The Internet Society (2005). All Rights Reserved. (2006).

Abstract

   This document specifies the Path Computation Element communication
   Protocol (PCEP) for communications between a Path Computation Client
   (PCC) and a Path Computation Element (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 MPLS and GMPLS Traffic
   Engineering.  The PCEP protocol 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.

     Conventions used in this document

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. RFC 2119 [RFC2119].

Table of Contents

   1. Terminology................................................3  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2. Introduction...............................................4  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3. Assumptions................................................4  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Transport protocol.........................................5 protocol . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Architectural Protocol Overview (Model)....................5 (Model)  . . . . . . . . . . .  7
     5.1. Problem..................................................5  Problem  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Architectural Protocol Overview..........................6 Overview  . . . . . . . . . . . . .  7
       5.2.1.  Initialization phase...................................6 Phase . . . . . . . . . . . . . . . . .  8
       5.2.2.  Path computation request sent by a PCC to a PCE........7 PCE  . . .  9
       5.2.3.  Path computation reply sent by the PCE to a PCC........8 PCC  . . . 10
       5.2.4. Notifications..........................................9  Notification . . . . . . . . . . . . . . . . . . . . . 12
       5.2.5.  Termination of the PCEP Session........................10 Session  . . . . . . . . . . . 13
   6.  PCEP messages..............................................10 Messages  . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  Common header............................................10 header  . . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  Open message.............................................11 message . . . . . . . . . . . . . . . . . . . . . . . 15
     6.3.  Keepalive message........................................13 message  . . . . . . . . . . . . . . . . . . . . 16
     6.4.  Path Computation Request (PCReq) message.................13 message . . . . . . . . . 17
     6.5.  Path Computation Reply (PCRep) message...................14 message . . . . . . . . . . 18
     6.6.  Notification (PCNtf) message.............................15 message . . . . . . . . . . . . . . . 19
     6.7.  Error (PCErr) message....................................15 Message  . . . . . . . . . . . . . . . . . . 20
     6.8.  Close message  . . . . . . . . . . . . . . . . . . . . . . 21
   7.  Object Formats.............................................16 Formats . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Common object header.....................................16 header . . . . . . . . . . . . . . . . . . . 21
     7.2.  OPEN Object..............................................18 object  . . . . . . . . . . . . . . . . . . . . . . . 23
     7.3.  RP Object................................................19 Object  . . . . . . . . . . . . . . . . . . . . . . . . 24
       7.3.1.  Object definition  . . . . . . . . . . . . . . . . . . 24
       7.3.2.  Handling of the RP object  . . . . . . . . . . . . . . 26
     7.4.  NO-PATH Object...........................................20 Object . . . . . . . . . . . . . . . . . . . . . . 27
     7.5. END-POINTS Object........................................21  END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28
     7.6.  BANDWIDTH object.........................................22 Object . . . . . . . . . . . . . . . . . . . . . 29
     7.7. DELAY Object.............................................23  METRIC Object  . . . . . . . . . . . . . . . . . . . . . . 30
     7.8.  ERO Object...............................................24 Object . . . . . . . . . . . . . . . . . . . . . . . . 32
     7.9.  RRO Object...............................................24 Object . . . . . . . . . . . . . . . . . . . . . . . . 33
     7.10. LSPA Object.............................................24 Object  . . . . . . . . . . . . . . . . . . . . . . . 33
     7.11. IRO Object..............................................26 Object . . . . . . . . . . . . . . . . . . . . . . . . 35
     7.12. SVEC Object.............................................27
       7.13. NOTIFICATION object.....................................28
       7.14. PCEP-ERROR object.......................................31
       8. Object  . . . . . . . . . . . . . . . . . . . . . . . 35
       7.12.1. Independent versus synchronized path computation requests..34
       9. Elements
               requests . . . . . . . . . . . . . . . . . . . . . . . 35
       7.12.2. SVEC Object  . . . . . . . . . . . . . . . . . . . . . 37
       7.12.3. Handling of procedure......................................35
       9.1. Non recognized or non support object received in a
            PCReq message
       9.2. RP object................................................35
       9.3. the SVEC object..............................................36
       10. Object  . . . . . . . . . . . . . 38
     7.13. NOTIFICATION Object  . . . . . . . . . . . . . . . . . . . 39
     7.14. PCEP-ERROR Object  . . . . . . . . . . . . . . . . . . . . 42
     7.15. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 44
   8.  Manageability Considerations..............................36
       11. Considerations . . . . . . . . . . . . . . . . . 45
   9.  IANA Considerations.......................................36
       11.1. Considerations  . . . . . . . . . . . . . . . . . . . . . 45
     9.1.  TCP port................................................36
       11.2. Port . . . . . . . . . . . . . . . . . . . . . . . . . 45
     9.2.  PCEP Objects............................................36
       11.3. Notification............................................39
       11.4. Messages  . . . . . . . . . . . . . . . . . . . . . . 45
     9.3.  PCEP Error..............................................39
       12. Object  . . . . . . . . . . . . . . . . . . . . . . . 46
     9.4.  Notification . . . . . . . . . . . . . . . . . . . . . . . 47
     9.5.  PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 48
   10. Security Considerations...................................40
       12.1. Considerations  . . . . . . . . . . . . . . . . . . . 49
     10.1. PCEP Authentication and Integrity.......................40
       12.2. Integrity  . . . . . . . . . . . . 50
     10.2. PCEP Privacy............................................40
       12.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . 50
     10.3. Protection against Denial of Service attacks............41
       13. Intellectual Property Statement...........................41
       14. Acknowledgment............................................42
       15. References................................................42
       15.1. attacks . . . . . . . 50
     10.4. Request input shaping/policing . . . . . . . . . . . . . . 51
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
     12.1. Normative references....................................42
       15.2. References . . . . . . . . . . . . . . . . . . . 51
     12.2. Informative References..................................43
       16. Authors' Address..........................................44 References . . . . . . . . . . . . . . . . . . 52
   Appendix A: Compliance of A.  Proposed Status and Discussion [To Be Removed
                Upon Publication] . . . . . . . . . . . . . . . . . . 53
   Appendix B.  PCEP to the set of requirements
       specified in draft-ietf-pce-comm-protocol-gen-reqs........... 45 Variables  . . . . . . . . . . . . . . . . . . . 53
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
   Intellectual Property and Copyright Statements . . . . . . . . . . 57

1.  Terminology

   Terminology used in this document

   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 level.

   Inter-domain TE LSP: A TE LSP whose path transits across at least two
   different domains where a domain can either be an IGP area, an
   Autonomous System or a sub-AS (BGP confederations).

   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 the
   PCE).

       PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a
       Detour LSP.

   TED: Traffic Engineering Database which contains the topology and
   resource information of the domain.  The TED may be fed by IGP
   extensions or potentially by other means.

       Explicit

   TE LSP: Traffic Engineering Label Switched Path.

   Strict/loose 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.

       Strict/loose path: mix mix of strict and loose hops comprising of at
   least one loose hop representing the destination where a hop may be
   an abstract node such as an AS.

   Within this document, when PCE-PCE communications are being
   described, the requesting PCE fills the role of a PCC.  This provides
   a saving in documentation without loss of function.

2.  Introduction

       [PCE-ARCH] describes

   [I-D.ietf-pce-architecture]describes the motivations and architecture
   for a PCE-based model to perform path computation for the computation of MPLS and GMPLS TE LSPs.
   The model allows the separation of PCE from PCC, and allows
   cooperation between PCEs.  This necessitates a communication protocol
   between PCC and PCE, and between PCEs.

       [PCE-COM-GEN-REQ]

   [I-D.ietf-pce-comm-protocol-gen-reqs] states the generic requirements
   for such a protocol including a the requirement that for using the same
   protocol must 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 [PCE-COM-GEN-REQ], [I-D.ietf-pce-comm-protocol-gen-
   reqs], 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 [I-D.ietf-pce-pcecp-interarea-
   reqs]and [I-D.ietf-pce-inter-layer-req].

   This document specifies the Path Computation Element communication
   Protocol (PCEP) for communications between Path Computation Client
   (PCC) and a Path Computation Element (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 MPLS and GMPLS Traffic Engineering.
   The PCEP protocol 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.

       The compliance of PCEP to the set of requirements stated in [PCE-COM-
       GEN-REQ] is covered in Appendix A.

3.  Assumptions
       [PCE-ARCH]

   [I-D.ietf-pce-architecture] describes various types of PCE: it is important to note
       that no PCE.  PCEP
   does not make any assumption is made and thus does not impose any constraint
   on the nature of the PCE in this document. PCE.

   Moreover, it is assumed that the PCE gets the required information so
   as to perform TE LSP path computation which usually requires network
   topology and resource information that can be gathered by routing
   protocols or by some other means.  The retrieval of such information
   is out of the scope of this document.

   Similarly, no assumption is made on the discovery method used by a
   PCC to discover a set of PCEs (e.g. via static configuration or
   dynamic discovery) and select a on the PCE to send its path computation
       request(s) to. decision selection process.  For
   the sake of reference [PCE-DISC-REQ] [I-D.ietf-pce-discovery-reqs] defines a list of
   requirements for dynamic PCE discovery. discovery and IGP-based solution for
   such PCE discovery are specified in [I-D.ietf-pce-disco-proto-igp].

4.  Transport protocol

   PCEP operates over TCP using the a well-known TCP port (TBD (to be assigned by
   IANA).  This allows the requirements of reliable messaging and flow
   control to be met without further protocol work.

   An implementation may decide to keep the TCP session alive for an
   unlimited time (this may for instance be the case should an
       implementation have to send new appropriate when path
   computation requests frequently in which case the
       TCP session will already be in place). Another motivation for leaving
       the TCP connection open would be are sent on a frequent basis so as to avoid to
   open a TCP connection
       establishment time. This mode session each time a path computation request is also referred to as the "Permanent
       mode". needed).
   Conversely, in some other circumstances, it may be desirable to
   systematically open and close the TCP connection for each PCEP
   request (this may for (for instance be the case if when sending of PCEP path computation request is a
   rare event). This mode is referred to as the
       "Per-request mode".

       Since there are circumstances where the TCP connection state is used
       to detect the PCC/PCE liveness (e.g case of a stateful PCE detecting
       a PCC failure thanks to the TCP state), the desired mode MUST be
       known by both the PCC and the PCE and is determined during the
       initialization phase.

5.  Architectural Protocol Overview (Model)

   The aim of this section is to describe the PCEP protocol model in the
   spirit of [WP]. [RFC4101].  An architecture protocol overview (the big
   picture of the protocol) is provided in this section where section.  Protocol
   details of the
       protocol can be found in further sections.

5.1.  Problem

   The PCE-based architecture used for the computation of MPLS and GMPLS
   TE LSP paths is described in [PCE-ARCH]. [I-D.ietf-pce-architecture].  When the
   PCC and the PCE are not collocated, a communication protocol between
   the PCC and the PCE is required.  PCEP is such a protocol designed
   specifically for communications between a PCC and a PCE or between
   two PCEs: a PCC may use PCEP to send a path computation request for
   one or more TE LSP(s) to a PCE and such a PCE may reply with a set of
   computed path(s) if one or more path(s) obeying the set of
   constraints can be found.

5.2.  Architectural Protocol Overview

   PCEP operates over TCP, which allows the requirements of reliable
   messaging and flow control to be met without further protocol work.

   Several PCEP messages are defined:

   - Open and Keepalive messages are used to initiate and maintain a
   PCEP session respectively.

   - PCReq: a PCEP message sent by a PCC to a PCE to request a path
   computation.

   - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path
   computation request.  A PCRep message can either contain a set of
   computed path(s) if the request could be satisfied or a negative
   reply otherwise.

   - PCNtf: a PCEP notification message either sent by a PCC to a PCE or
   a PCE to a PCC to notify of specific event.

   - PCErr: a PCEP message related to sent upon the occurrence of a protocol error
   condition.

   - Close message: a message used to close a PCEP session.

   The set of available PCE(s) may be either statically configured on a
   PCC or dynamically discovered (the mechanism for that discovery is
   out of the scope of this document). A PCC may have PCEP sessions  Note that the PCE selection
   algorithm is 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.

   A PCEP session establishment can either be is always triggered by the PCC or the PCE.

       5.2.1 PCC.

5.2.1.  Initialization phase Phase

   The initialization phase consists of two successive steps: 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 connection.

   Once the TCP connection is established, the PCC and the PCE (also
   referred to as "PCEP peers") initiate a PCEP session establishment
   during which various session parameters are advertised. Those negotiated.  These
   parameters are carried within Open messages and include the keepalive
       timer, the PCEP session mode (per-request or permanent), potential
   timer 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 exchanged parameters or one of
   the PCEP peers does not
       answer, answer after the expiration of the transport
   establishment timer, the TCP connection is immediately closed.
   Successive retries are permitted but an implementation SHOULD make
   use of exponential back-off.

   Keepalive messages are used to acknowledge Open messages and once the
   PCEP session is established has been successfully established, Keepalive messages
   are exchanged between PCEP peers to ensure the liveness of the PCEP
   session.

   Details about the Open message and the Keepalive messages can be
   found in .  (Section 6.2) and Section 6.3respectively.

            +-+-+                  +-+-+
            |PCC|                  |PCE|
            +-+-+                  +-+-+
              |                      |
              |---- Open message --->|
              |                      |
              |<--- Open message ----|
              |                      |
              |                      |
              |                      |
              |<--- Keepalive -------|
              |                      |
              |---- Keepalive ------>|

   Figure 1: PCEP Initialization phase (triggered by a PCC)

5.2.2.  Path computation request sent by a PCC to a PCE

       Consider the diagram depicted in figure 2.

                    +-+-+                  +-+-+
                    |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 (or a PCE) has successfully established a PCEP session
   with one or more PCEs, if an event is triggered that requires the
   computation of a path, set of path(s), the PCC first selects the PCE it desires one of more
   PCE(s) to send a path computation the request to (note to.  Note that the PCE selection decision
   process may
       be performed have taken place prior to the PCEP session establishment). establishment.

   Once a 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, address=x'.y'.z'.t', bandwidth=X
   Mbit/s, Priority=Y, ...".  Additionally, the PCC may desire to
   specify the urgency of such request by assigning a request priority. It is worth pointing out
       that each
   Each request is uniquely identified by a request-id number and the
   PCC-PCE addresses pair.  The process is shown in a schematic form in
   figure 2.

   Details about the PCReq message can be found in Section 6.4

5.2.3.  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 path(s) sent
                   |                      |to the PCC
                   |<--- PCRep message ---|
                   |    (Positive reply)  |

    Figure 3a: Path computation request with successful path computation

                 +-+-+                  +-+-+
                 |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 unsuccessfull unsuccessful path computation
   Upon receiving a path computation request from a PCC, the PCE
   triggers a path computation, the result of which can either be:

   - Positive: Positive (Figure 3-a): the PCE manages to compute a path satisfying
   the set of required constraints and constraints.  The PCE returns the set of computed
   path(s) (note
       that to the requesting PCC.  Note that PCEP protocol supports the
   capability to send a single request which refers to the computation
   of multiple paths: for example, compute two link diverse paths). This is illustrated in
       figure 3a. link-diverse paths.

   - Negative: Negative (Figure 3-b): no path could be computed found that satisfies the request.
   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. This is illustrated

   Details about the PCRep message can be found in figure 3b.

       5.2.4 Notifications Section 6.5.

5.2.4.  Notification

   There are several circumstances whereby a PCE may want to notify a
   PCC of a specific event.  For example, suppose that the PCE suddenly
   experiences some congestion that would lead 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, satisfied or
   may experience unacceptable delays.  Such notification may
   potentially resulting result in path computation redirections on the PCC
   towards another PCE, if an alternate PCE is available.  Similarly, a
   PCC may desire to notify a PCE of particular event such as the
   cancellation of pending request(s).

                    +-+-+                  +-+-+
                    |PCC|                  |PCE|
                    +-+-+                  +-+-+
   1)Path computation |                      |
   event              |                      |
   2)PCE Selection    |                      |
   3)Path computation |---- PCReq message--->|
   request X sent to  |                      |4) Path computation
   the selected PCE   |                      |triggered
                      |                      |
                      |                      |
   5) Path computation|                      |
   request X cancelled|                      |
                      |---- PCNtf message -->|
                      |                      |6) Path computation
                      |                      |request X cancelled

   Figure 4: Example of PCC notification (request cancellation) 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   |                      |triggered
                      |                      |
                      |                      |
                      |                      |5) PCE experiencing
                      |                      |congestion
                      |                      |
                      |                      |6) Path computation
                      |                      |request X cancelled
                      |                      |
                      |<--- PCNtf message----|

   Figure 5: Example of PCEP PCE notification (request(s) cancellation) send sent to a PCC

   Details about the PCNtf message can be found in Section 6.6.

5.2.5.  Termination of the PCEP Session

   When one of the PCEP peers desires to terminate a PCEP session it
       MUST
   first sends a PCEP Close message and then close the TCP connection.

   If the PCEP session is terminated by the PCE, the PCC MUST clear clears all the
   states related to pending requests sent to the PCE.  Similarly, if
   the PCC terminates a PCEP session the PCE MUST clear 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 SHOULD be
   maintained for a period of time equal to the Deadtimer.

   Details about the Close message can be found in Section 6.8.

6.  PCEP messages 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 in such
   message for the message to be considered as valid. Conversely, an object is said to
       be optional the  Thus a missing
   mandatory object may or may not be present. As specified in
       section 7.1, a specific PCEP message MUST be considered as a malformed
   message and such condition MUST trigger an Error message.
   Conversely, if an object is optional, the object may or may not be
   present.

   A flag referred to as the P flag is also defined in the common header of
   each PCEP object (see Section 7.1) that can be set by a PCEP peer to
   enforce a PCE to take into account the related information during the
   path computation.  For example, the
       DELAY COST object allows a PCC to
   specify in a path computation request a bounded acceptable delay for the computed path. path cost.  The DELAY COST object is optional (does not have to be present in each path computation
       request message)
   but a PCC may set a flag to ensure that the delay such constraint is being taken into
   account.  Similarly to the previous case, if such constraint cannot
   be taken into account when present in a by the PCE, this should trigger an Error
   message.

   For each PCEP message type a set of rules is defined which specifies
   the set of possible objects that the message can carry.  We use the
   Backus-Naur Form (BNF) to specify such rules.  Square brackets refer
   to optional sub-sequences.  An implementation MUST form the PCEP
   messages using the order specified in this document.

       If a mandatory object is missing in a received PCEP message the
       recipient of the PCEP message MUST trigger a protocol error
       condition.

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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Flags      |                Message-Length  Ver  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Flags     | Message-Type  |        Reserved       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Message-Lenght                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 6 - 6: PCEP message common header
   Ver (Version): 3 bits (Version - 4 bits): PCEP protocol version number.  The current  Current
   version is version 1

       Flags: 8 bits

           No 1.

   Flags (8 bits): no flags are currently defined

       Message Length: 24 bits

           Total length of the PCEP message expressed in bytes including
           the common header.

       Message-Type: 8 bits defined.

   Message-Type (8 bits):

   The following message types are currently defined. defined (to be confirmed by
   IANA).
   Value    Meaning
     1        Open
     2        Keepalive
     3        Path Computation Request
     4        Path Computation Reply
     5        Notification
     6        Error
     7        Close
   Message Length (32 bits): total length of the PCEP message expressed
   in bytes including the common header.

6.2.  Open message

   The Open message is a PCEP message sent by a PCC to a PCE in order to
   establish a PCEP session.  The Message-Type field of the PCEP common
   header for the Open message is set to 1 (To be confirmed by IANA).

   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. The aim of  Any message received prior to an OPEN message MUST
   trigger a protocol error condition and the PCEP session MUST be
   terminated.  The Open message is used to establish a PCEP session
   between the PCEP peers.  During that phase the PCEP peers exchange
   several session characteristics.  If both parties agree on such
   characteristics the PCEP session is successfully established.

       The Message-Type field of the PCEP common header for the Open message
       is set to 1.

       <Open Message>::= <Common Header>
                         <OPEN>

   Open message
   <Open Message>::= <Common Header>
                     <OPEN>
   The Open message MUST only contain a single exactly one OPEN object defined in
       section 7. The various (see
   Section 7.2).  Various session characteristics are specified within
   the OPEN object are the keepalive frequency, session mode (permanent or
       per-request) and potentially some optional parameters such as the
       detailed PCE capabilities and policy rules that specify the
       conditions under which path computation requests may be sent to the
       PCE. Details related to PCE capabilities discovery by means of PCEP
       are out of the scope of this document.

       Keepalive: PCEP object.

   Once an Open message has its own keepalive mechanism used been sent to ensure of the
       liveness of the PCEP session. This requires the determination of the
       frequency at which each PCEP peer sends the keepalive messages.
       Asymmetric values may be chosen; thus there is no constraints
       mandating the use of identical keepalive frequencies by both a PCEP
       peers. The Deadtimer is defined as peer, the period of time sender MUST
   start an initialization timer called InitOpen after the expiration of
   which a PCEP peer declares the session down similar Open message MUST be resent if no PCEP
       message reply has been
   received (keepalive or any other PCEP message: thus,
       any from the PCEP message acts as a keepalive message). peer.  The minimum Keepalive InitOpen timer has a fixed value is of
   1 second and minute.  The maximum number of Open messages named MaxRetryOpen
   that can be sent without any response from the Deadtimer value PCEP peer is equal to 4 times the
       Keepalive value.

       Session mode: PCEP supports two session modes referred to as
   3.

   Upon the
       "permanent" and "per-request" modes. In receipt of an Open message, the permanent mode, receiving PCEP peer MUST
   determine whether the PCEP
       peers maintained a permanent PCEP session (and thus the TCP session
       is also maintained) regardless of the rate at which PCEP messages are
       exchanged. Such mode would typically be used to speed-up response
       times. In the permanent mode, a loss of TCP session MUST be
       interpreted as a communication failure. Conversely, in the
       "per-request" mode, a PCEP session is established on-demand, when one or
       more path computation requests are required and then closed by the
       PCC once those path computation requests are satisfied. Both PCEP
       peers MUST agree on the session mode; in case of disagreement, the
       PCEP session establishment fails.

       Elements of procedure:
       - Once an Open message has been sent to a PCEP peer, the sender MUST
       start an initialization timer called INIT-OPEN after the expiration
       of which a similar Open message MUST be resent if no reply has been
       received from the PCEP peer. The INIT-OPEN timer has a fixed value of
       one minute. The maximum number of Open messages that can be sent
       without any response from the PCEP peer is equal to 3.
       - Upon the receipt of an Open message, the receiving PCEP peer MUST
       determine whether the suggested suggested PCEP session characteristics are
   acceptable.  If at least one or more of the characteristic(s) is not
   acceptable by the receiving peer, it MUST send a PCErr message with Error-type=8,
       Error-value=1. an Error message.  The PCErr
   Error message MUST SHOULD also comprise an contain the related Open object: for each
   unacceptable session parameter, an acceptable parameter value MUST SHOULD
   be proposed in the appropriate field of the Open object in place of
   the originally proposed value.  The PCEP peer may MAY decide to resend an
   Open message with different session characteristics.
       Consecutive retries SHOULD make use of exponential back-off so as to
       avoid undesirable burden of session initialization.  If a second
   Open message is received with the same set of parameters or with
   parameters differing from the proposed values, that are still unacceptable, the receiving peer MUST send a PCErr
   an Error message with Error-Type=8, Error-value=2 and it MUST immediately close the TCP connection.
   Details about error message can be found in Section 7.14.

   If the PCEP session characteristics are acceptable, the receiving
   PCEP peer MUST immediately consequently send a Keepalive message (defined in
   Section 6.3) that would serve as an acknowledgment.

   The PCEP session is considered as operational established once both PCEP peers
   have received a Keepalive message from their peer.

6.3.  Keepalive message

   A Keepalive messages are used either to acknowledge an Open message if
       the receiving is a PCEP peer message sent by a PCC or a PCE in order
   to keep the session in active state.  The Message-Type field of the
   PCEP common header for the Keepalive message is set to 2 (To be
   confirmed by IANA).  The Keepalive message does not contain any
   object.

   Keepalive: PCEP has its own keepalive mechanism used to ensure of 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 constraints
   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 is
   no constraints mandating the use of identical DeadTimers by both PCEP
   peers.  The minimum KeepAliveTimer value is 1 second.

   Keepalive messages are used either to acknowledge an Open message if
   the receiving PCEP peer agrees on the session characteristics and to
   ensure the liveness of the PCEP session.  Keepalive messages are sent
   at the frequency specified in the OPEN object carried within an Open
   message.

       The Message-Type field of  Because any PCEP message may serve as Keepalive an
   implementation may either decide to send Keepalive messages at the
   same frequency regardless on whether other PCEP common header for messages might have
   been sent since the Open last sent Keepalive message
       is set or may decide to 2.
   differ the sending of the next Keepalive message based on the time at
   which the last PCEP message (other than Keepalive) was sent.

   Keepalive message
   <Keepalive Message>::= <Common Header>

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 so as to request a
   path computation.  The Message-Type field of the PCEP common header
   for the PCReq message is set to 3. 3 (To be confirmed by IANA).

   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
   of these objects is missing, the receiving PCE MUST send an error
   message to the requester (PCErr message). requester.  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>
                   [<END-POINTS>]
                   [<LSPA>]
                   [<BANDWIDTH>]
                       [<DELAY>]
                   [<METRIC>]
                   [<RRO>]
                       [<XRO>]
                   [<BANDWIDTH>]
                   [<IRO>]
   The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, DELAY, METRIC, ERO, XRO and IRO
   objects are defined in section Section 7.

       6.5.  The special case of two BANDWIDTH
   objects in details inSection 7.6.

6.5.  Path Computation Reply (PCRep) message

   The PCEP Path Computation reply 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 is set to 4. 4 (To be confirmed by
   IANA).

   The PCRep message MUST comprise contain at least one RP object.  For each
   reply that is bundled into a single PCReq message, an RP object with 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 for Section 7.3for the definition of the RP object).

   A PCRep may comprise multiple computed path(s) corresponding to
   multiple path computation requests originated by a common requesting
       PCC.
   PCC and/or to multiple acceptable paths corresponding to the same
   request.  The bundling of multiple responses within a single PCRep
   message is supported by the PCEP protocol.  If a PCE receives non-synchronized 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 reply each path in separate
   PCRep messages.

   If the path computation request can be successfully satisfied (the
   PCE manages to compute a set of path(s) that obey the requested
   constraint(s)), the set of computed path(s) specified by means of ERO
   object(s) is inserted in the PCRep message.  The ERO object is
   defined in Section 7.8.  Such a situation where multiple computed
   paths are provided in a PCRep message is discussed in detail in section 8.
   Section 7.12.

   If the path computation request cannot be satisfied, the PCRep
   message MUST include a NO-PATH object.  The NO-PATH object (further
   described in section 7) Section 7.4) may also comprise other information (e.g
   reasons for the path computation failure).

   The format of a PCRep message is as follows:
   <PCRep Message> ::= <Common Header>
                       [<svec-list>]
                           <path-list>
                       <response-list>

   where:
      <svec-list>::=<SVEC>[<svec-list>]
          <path-list>::=<path>[<path-list>]

          <path>::=<RP>
      <response-list>::=<response>[<response-list>]

      <response>::=<RP>
                  [<NO-PATH>]
                   [<ero-list>]
                  [<path-list>]

      <path-list>::=<path>[<path-list>]

      <path>::= <ERO>
               [<LSPA>]
               [<BANDWIDTH>]
                   [<DELAY>]
                   [<XRO>]
               [<METRIC>]
               [<IRO>]

       where:
          <ero-list>:==<ERO>[<ero-list]>

6.6.  Notification (PCNtf) message

   The PCEP Notification message (also referred to as the PCNtf message)
   can either be sent by a PCE to a PCC or by a PCC to a PCE so as to
   notify of a specific event.  The Message-Type field of the PCEP
   common header is set to 5. 5 (To be Confirmed by IANA).

   The PCNtf message MUST carry at least one NOTIFICATION object and may
       comprise
   contain several NOTIFICATION objects should the PCE or the PCC intend
   to notify of multiple events.  The NOTIFICATION object is defined in section 7.
   Section 7.13.  The PCNtf message may also comprise contain an RP object when (see
   Section 7.3when the notification refers to a particular path
   computation request.

   The PCNtf message may be sent by a PCC or a PCE in response to a
   request or in an unsolicited manner.

   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>

       The procedure upon the reception of a PCNtf message is defined in
       section 9.

6.7.  Error (PCErr) message Message

   The PCEP Error message (also referred to as a PCErr message) is sent
   when a protocol error condition is met.  The Message-Type field of
   the PCEP common header is set to 6.

   The PCErr message may be sent by a PCC or a PCE in response to a
   request or in an unsolicited manner.  In the former case, the PCErr
   message MUST include the set of RP objects related to the pending
   path computation request(s) which triggered the protocol error
   condition.  In the later case (unsolicited), no RP object is inserted
   within the PCErr message.  No RP object is inserted in a PCErr when
   the error condition occurred during the initialization phase.  A
   PCErr message MUST comprise a PCEP-ERROR object specifying the PCEP
   error condition.  The PCEP-ERROR object is defined in section 7.
   Section 7.14.

   The format of a PCErr message is as follows:
   <PCErr Message> ::= <Common Header>
                       <error-list>
                       [<Open>]

   <error-list>:==<error>[<error-list>]
   <error>::=[<request-id-list>]
              <error-obj-list>

   <request-id-list>:==<RP>[<request-id-list>]

   <error-obj-list>:==<PCEP-ERROR>[<error-obj-list>]
   The procedure upon the reception of a PCErr message is defined in
       section 9.
   Section 7.14.

6.8.  Close message

   The Close message is a PCEP message sent by either a PCC to a PCE or
   by a PCE to a PCC in order to close a PCEP session.  The Message-Type
   field of the PCEP common header for the Open message is set to 7 (To
   be confirmed by IANA).

   Open message
   <Close Message>::= <Common Header>
                     <CLOSE>
   The Close message MUST contain exactly one CLOSE object (see
   Section 6.8).

   Upon the receipt of a Close message, the receiving PCEP peer MUST
   cancel all pending requests and MUST close the TCP connection.

7.  Object Formats

7.1.  Common object header
   A PCEP object carried within a PCEP message consists of one or more
   32-bit words with a common header which 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|I|P|  |Res|P|I|   Object Length (bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Object body)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 8 - 8: PCEP common object header

   Object-Class (to be managed by IANA)

          8-bit field that (8 bits): identifies the PCEP object class class.

   OT (Object-Type) (to be managed by IANA)

           4-bit field that (Object-Type - 4 bits): identifies the PCEP object type

       P flag (Processing-Rule)
          1-bit flag which specifies whether the object must be taken into
          account by the receiving type.

   The Object-Class and Object-Type are managed by IANA.

   The Object-Class and Object-Type fields uniquely identify each PCEP peer
   object.

   Res (3 bits): Reserved.

   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 cleared, set, the object MUST be taken into account by the
          receiving entity. If the PCC or the PCE does not understand the
          object or understands the object but decides to ignore the object,
          this MUST trigger a protocol error condition as defined in section
          7.
   PCE.  Conversely, when the P flag is set cleared, the object is optional
   and
          can be silently ignored.

       I flag

           1-bit flag: the PCE set the is free to ignore it if not supported.

   I flag when (Ignore - 1 bit): the object I flag is carried
           within used by a PCE in a PCRep
   message so as to indicate when the constraint 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.

       Res flags: 2-bit  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 MUST be cleared if the P
   flag reserved is set.

   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".

   Res flags (2 bits).  Reserved field (MUST be set to 0) 0).

   Object Length

          16-bit field containing (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.  The Object-Class
       and Object-Type fields uniquely identify each PCEP object.

       The P bit is used to determine what action a node should take if it
       does not recognize the Object-Class or Object-Type of a PCEP object
       or decides not to take into account the object: there are two
       possible ways a PCEP implementation can react. This choice is
       determined by the P bit, as follows.

       If P flag=0

       The entire PCEP message MUST be rejected and the receiving PCEP peer
       MUST send a PCErr message with a PCEP-ERROR Object ("Unkown Object"
       or "Not supported Object").

       If P flag=1

       The node MAY ignore the object and process the PCEP message if
       possible. In that case (the message can be processed by ignoring the
       object in question), the PCE SHOULD include the object in the
       corresponding PCERep message. The I flag of the common header for
       this object MUST be set. If the path computation cannot be performed,
       a PCErr message MUST be sent to the requesting entity with a PCEP-
       ERROR object (Error-type=2, "Unknown Object").

       7.2. OPEN Object

7.2.  OPEN object

   The OPEN object MUST be present in each Open message and may be
   present in 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
   protocol version, Keepalive frequency, 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
       capability,
   capabilities, policy rules and so on.  No such TLV is currently
   defined.

   OPEN Object-Class is to be assigned by IANA (recommended value=1)

   OPEN Object-Type is to be assigned by IANA (recommended value=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 |  Keepalive    |            SID  Deadtimer    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      SID      |              Reserved  Flags  |                             |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                         Optional TLV(s)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9  - 9: OPEN Object format

       Version (Ver): 3 bits
   Ver (Ver - 3 bits): PCEP version.  Current version is 1.

   Keepalive frequency (Keepalive): 16 bits.

           Specifies (8 bits): minimum period of time (in seconds) between the frequency in seconds at which
   sending of PCEP messages that the sender of the Open message will
   send Keepalive messages.  The minimum value for the Keepalive is 1
   second.  When set to 0, no keepalive once the session is established, no further
   keepalives need to be sent to the remote peer.  A RECOMMENDED value
   for the keepalive frequency is 30 seconds.

       PCEP session-ID (SID): 13 bits.
           Specifies

   DeadTimer (8 bits): specifies the amount of time after the expiration
   of which a 2 octet unsigned PCEP peer declares the session number that identifies with the current session. sender of the Open
   message down if no PCEP message has been received.  The SID DeadTimer
   MUST be incremented each time a new
           PCEP session is established.

       Flags

           One flag set to 0 if the Keepalive is currently defined.

           R flag: when cleared, this indicates that set to 0.  A RECOMMENDED value
   for the sending PCEP peer
           requires DeadTimer is 4 times the establishment value of the Keepalive.

   SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP
   session in permanent mode.
           When set, number that identifies the current session.  The SID MUST be
   incremented each time a per-request mode new PCEP session is requested. established and is mainly
   used for logging and troubleshooting purposes.

   Flags (5 bits): No Flags are currently defined.

   Optional TLVs may be included within the Open message 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 a PCEP object
   within the PCErr message so as to propose alternative session
   characteristic values.

7.3.  RP Object

   The RP (Request Parameters) object MUST be carried within every each PCReq
   and PCRep messages and MAY be carried within PCNtf and PCErr
   messages.  The P flag of the RP object MUST be set.  The RP object is
   used to specify various characteristics of the path computation
   request.

7.3.1.  Object definition

   RP Object-Class is to be assigned by IANA (recommended value=2)

   RP Object-Type is to be assigned by IANA (recommended value=1)
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved    |              Flags          |O|C|B|R|            |O|B|R| Pri |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request-ID-number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLV(s)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10 - 10: RP object body format

   The RP object body has a variable length and may contain additional
   TLVs.  No TLV is currently defined.

   Flags: 18 bits - The following flags are currently defined:

   Pri (Priority) field (3 bits)

           This (Priority - 3 bits): the Priority field may be used by the
   requesting PCC to specify to the PCE the request's priority. priority from 1 to
   7.  The decision of which priority should be used for a specific
   request is of a local matter and MUST be set to 0 when unused.
   Furthermore, the use of the path computation request priority by the
   PCE's requests 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 that case, the priority field SHOULD
   RECOMMENDED be set to 0 by the PCC 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 PCC(s).  The ability of a PCE to support
   requests prioritization may be dynamically discovered by the PCC(s)
   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 the 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 the
           Pri field: handling of request priorities: in other words,
   the path computation request has been honoured but without taking the
   request priority into account.

   R (Reoptimization) bit: (Reoptimization - 1 bit): when set, the requesting PCC specifies
   that the PCReq message relates to the reoptimization of an existing
   TE LSP in which case the path of the existing TE LSP to be
   reoptimized MUST be provided in the PCReq (except of 0-bandwidth TE
   LSP) message by means of an RRO object defined in section 7. Section 7.9.

   B (Bi-directional) bit: (Bi-directional - 1 bit): when set, the PCC specifies that the path
   computation request relates to a bidirectional TE LSP (LSPs that have has the
   same traffic engineering requirements including fate sharing,
   protection and restoration, LSRs, and resource requirements (e.g., (e.g.
   latency and jitter) in each direction). direction.  When cleared, the TE LSP is
   unidirectional.

           C (Cost) bit:

   O (strict/lOose - 1 bit): when set, the PCE MUST provide the cost of the
           computed path in the PCRep message.

           O (strict/lOose): In a PCReq message, when set, this means
   indicates that a strict/loose path is acceptable.  Otherwise, when
   cleared, this indicates to the PCE that an explicit path is required.
   In a PCRep message, when the O bit is set this indicates that the
   returned path is strict/loose, otherwise (the O bit is cleared), the
   returned path is explicit.

           Request-ID-number: 32 bits

           This

   Request-ID-number (32 bits).  The Request-ID-number value (combined combined
   with the source IP address of the PCC) PCC and the PCE address uniquely identifies
   identify the path computation request context and context.  The Request-ID-number
   MUST be incremented each time a new request is sent to the PCE.  If
   no path computation reply is received from the PCE, and the PCC
   wishes to resend its request, the same Request-ID-number MUST be
   used.  Conversely, different Request-ID-number MUST be used for
   different requests sent to a PCE.  The same Request-ID-
           number 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. NO-PATH Object

       When

7.3.2.  Handling of the RP object

   If a PCReq message is received without containing an RP object, the
   PCE cannot find a path satisfying a set of constraints, it MUST include send a NO-PATH object in PCErr message to the corresponding PCRep message. In
       its simplest form, requesting PCC with Error-
   type="Required Object missing" and Error-value="RP Object missing".

   If the NO-PATH object is limited to C bit of the RP message carried within a PCReq message is set of flags
   and just reports local policy has been configured on the impossibility PCE to find a path that satisfies not provide the
       set of constraints. Optionally, if
   computed path cost, a PCErr message MUST be sent by the PCE supports such capability, to the PCRep message MAY also comprise a list of objects that specify
   requesting PCC and the set of constraints that could not pending path computation request MUST be satisfied. When an object
       specifies a variety of constraints,
   discarded.  The Error-type is "Policy Violation" and Error-value is
   "C bit set".

   If the set O bit of unsatisfied
       constraints can be unambiguously determined by the PCC after RP message carried within a simple
       comparison with the original requested constraints.

       NO-PATH Object-Class PCReq message is set
   and local policy has been configured on the PCE to not provide
   explicit path(s) (for instance, for confidentiality reasons), a PCErr
   message MUST be assigned sent by IANA (recommended value=3)
       NO-PATH Object-Type is the PCE to the requesting PCC and the pending
   path computation request MUST be assigned by IANA (recommended value=1) discarded.  The format Error-type is
   "Policy Violation" and Error-value is "O bit set".

   R bit: when the R bit of the NO-PATH 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |C|S|     Flags                 |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 11 - NO-PATH object format

       The NO-PATH object has set in a fixed length of 4 octets.

       Flags: 16 bits - The following flags are currently defined:

       C bit: when set, PCReq message,
   this indicates that the set of unsatisfied
       constraints (reasons why a path could not be found) is specified in
       the PCRep message by means of the relevant PCEP objects. When
       cleared, no reason is specified.

       For example, consider the case of a PCC that sends a path computation request relates to a PCE for a TE LSP the
   reoptimization of X MBits/s. Suppose that PCE cannot
       find a path for X MBits/s. an existing TE LSP.  In this case, the PCE includes in its PCC MUST
   provide the explicit or strict/loose path
       computation reply a NO-PATH by including an RRO object with the C flag set. In addition,
   in the PCRep PCReq message carries the BANDWIDTH object and the bandwidth
       field value is equal so as to X.

       When avoid double bandwidth counting if and
   only if the NO-PATH object TE LSP is absent from a PCRep message, non 0-bandwidth TE LSP.  If the path
       computation request PCC has been fully satisfied and the corresponding
       path(s) is/are provided in the PCRep message.

       7.5. END-POINTS Object

       The END-POINTS object is used in
   previously requested a PCReq message to specify non-explicit path (O bit set), a
   reoptimization can still be requested by the
       source IP address and PCC but this implies for
   the destination IP address PCE to be either stateful (keep track of the TE LSP for
       which a previously computed
   path computation is requested. Two END-POINTS objects (for
       IPv4 and IPv6) are defined.

          END-POINTS Object-Class is with the associated list of strict hops) or to be assigned by IANA (recommended
       value=4)
          END-POINTS Object-Type is have the ability
   to retrieve the complete required path segment.  Alternatively the
   PCC MUST be assigned by IANA (recommended
       value=1 for IPv4 and 2 for IPv6) able to inform PCE of the working path with associated
   list of strict hops in PCReq.  The format absence of an RRO in 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 PCReq
   message for IPv4

       The format a non 0-bandwidth TE LSP when the R bit of the END-POINTS RP 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 set MUST trigger the sending of a PCErr message with Error-
   type="Required Object Missing" and Error-value="RRO Object missing
   for IPv6

       7.6. BANDWIDTH reoptimization".

   If the PCC receives a PCRep message that contains a RP object
   referring to an unknown Request-ID-Number, the PCC MUST send a PCErr
   message with Error-Type="Unknown request reference".

7.4.  NO-PATH Object

   The BANDWIDTH No-PATH object is optional and can be used to specify the
       requested bandwidth and may be carried within PCReq and in PCRep
       messages. The absence of the BANDWIDTH object MUST be interpreted by
       the PCE as messages in response to a path
   computation request related to that was unsuccessful (the PCE could not find a 0 bandwidth TE
       LSP.
   path satisfying the set of constraints).  When carried within a PCReq message, the BANDWIDTH object specifies PCE cannot find a
       bandwidth constraint that must be satisfied by
   path satisfying a set of constraints, it MUST include a NO-PATH
   object in the computed path(s)
       if P flag PCRep message.  In its simplest form, the NO-PATH
   object is cleared limited to a set of flags and MAY be ignored just reports the
   impossibility to find a path that satisfies the set of constraints.
   Optionally, if the P flag is set. In a
       PCRep message, PCE supports such capability, the BANDWIDTH object indicates PCRep message
   MAY also contain a list of objects that the bandwidth
       belong to specify the set of one or more constraint(s)
   constraints that could be not be satisfied. When absent from  The PCE MAY just replicate
   the PCRep message object that means was received that was the
       computed path satisfies cause of the requested bandwidth constraint.

          BANDWIDTH unsuccessful
   computation or MAY optionally report a suggested value for which a
   path could have been found.

   NO-PATH Object-Class is to be assigned by IANA (recommended
       value=5)
          BANDWIDTH value=3)

   NO-PATH Object-Type is to be assigned by IANA (recommended value=1)
   The format of the BANDWIDTH 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|       Flags                 |                        BANDWIDTH          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 14 - BANDWIDTH 11: NO-PATH object body format

       Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in
       IEEE floating point format, expressed in bytes per second.

       7.7. DELAY Object
   The DELAY NO-PATH object can be used to specify body has a strict delay constraint for
       the TE LSP. fixed length of 4 octets.

   Flags (16 bits).  The delay constraint MUST be taken into account during
       path computation if P flag is cleared and MAY be ignored if the P following flags are currently defined:

   C flag is set. Note that the mechanism used by (1 bit): when set, the PCE to retrieve indicates the
       delays set of each link unsatisfied
   constraints (reasons why a path could not be found) in the PCRep
   message by including the relevant PCEP objects.  When cleared, no
   reason is outside of specified.

   Example: consider the scope case of this document (for the
       sake a PCC that sends a path computation
   request to a PCE for a TE LSP of illustration the link delay could be X MBits/s.  Suppose that PCE cannot
   find a path for X MBits/s.  In this case, the IGP metric or PCE must include in the
   PCRep message a
       Service Provider NO-PATH object.  Optionally the PCE may choose to use also include
   the TE metric original BANDWIDTH object so as to represent link
       delays). It must be understood indicate that such path metric is only
       meaningful if used consistently: the reasons for instance, if
   the delay of a path unsuccessful computation segment is exchanged between two PCE residing in
       different domains, consistent ways of defining the delay must be
       used. The delay metric bandwidth constraint (in this
   case, the C flag is set).  If the PCE supports such capability it may be carried within PCReq
   alternatively include the BANDWIDTH Object and PCRep
       messages. The absence report a value of Y in
   the bandwidth field of the DELAY BANDWIDTH object MUST be interpreted by (in this case, the
       PCE as a path computation request without delay constraint. C flag
   is set).

   When
       carried within a PCReq message, the DELAY NO-PATH object specifies a delay
       constraint that must be satisfied by the computed path(s). In is absent from a PCRep
       message and when message, the path
   computation was successful, the DELAY
       object indicates request has been fully satisfied and the delay(s) of corresponding
   path(s) is/are provided in the computed path(s). When PCRep message.

7.5.  END-POINT Object

   The END-POINTS object is used in a PCReq message to specify the path
       computation was unsuccessful
   source IP address and the delay constraint was one destination IP address of the
       mandatory constraints path for
   which a path computation is requested.  Note that could be satisfied the DELAY object MUST
       be present source and
   destination addresses specified in the PCRep message.

       DELAY END-POINTS object may or may
   not correspond to the source and destination IP address of the TE LSP
   but rather to a path segment.  Two END-POINTS objects (for IPv4 and
   IPv6) are defined.

   END-POINTS Object-Class is to be assigned by IANA (recommended value=6)
       DELAY
   value=4)

   END-POINTS Object-Type is to be assigned by IANA (recommended value=1) value=1
   for IPv4 and 2 for IPv6)
   The format of the DELAY 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Delay                     Source IPv4 address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Destination IPv4 address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 15 - DELAY 12: END-POINTS object body format
       Delay: 32 bits. The requested delay constraint is encoded in 32 bits
       in IEEE floating point format, expressed in milliseconds.

       7.8. ERO Object

       The ERO object is used to encode a TE LSP path. If can either be
       carried within a PCReq message to specify the existing path of a TE
       LSP to be reoptimize or within a PCRep message to provide a computed
       TE LSP. for IPv4

   The contents of this object are identical in encoding to the contents format of the Explicit Route Object defined in [RSPV-TE], [GRSVP] and [RSVP-
       UNNUM]. That is, the END-POINTS object is constructed from a series of sub-
       objects. Any RSVP ERO sub-object already defined or that could be
       defined in the future for use in the ERO is acceptable in this
       object.

       PCEP ERO sub-object types correspond to RSVP ERO sub-object types.

       Since the explicit path IPv6 (Object-Type=2) is available 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 immediate signaling by the
       MPLS or GMPLS control plane, the meanings of all IPv6

   The END-POINTS object body has a fixed length of the sub-objects 8 octets for IPv4
   and fields in this object are identical to those defined 32 octets for the ERO.

       ERO Object-Class is to be assigned by IANA (recommended value=7)
       ERO Object-Type is to be assigned by IANA (recommended value=1)

       7.9. RRO IPv6.

7.6.  BANDWIDTH Object

   The RRO BANDWIDTH object is optional and can be used to record specify the route followed by
   requested bandwidth for a TE LSP. The
       PCEP RRO object is exclusively carried within  In the case of a non existing TE
   LSP, the BANDWIDTH object MUST be included in the PCReq message so as
   to specify the route followed by a TE LSP required bandwidth for which a the new TE LSP.  In the case of
   the reoptimization
       is desired.

       The contents of this object are identical in encoding to an existing TE LSP, the contents bandwidth of the Route Record Object defined
   existing TE LSP MUST also be included in [RSPV-TE], [G-RSVP] addition to the requested
   bandwidth if and [RSVP-
       UNNUM]. That is, only if the object is constructed from a series of sub-
       objects. Any RSVP RRO sub-object already two values differ.  Consequently, two
   Object-Type are defined or that could be
       defined in the future for use in the RRO is acceptable in this
       object.

       The meanings of all of refer to the sub-objects requested bandwidth and fields in this object are
       identical to those defined for the RRO.

       PCEP RRO sub-object types correspond to RSVP RRO sub-object types.

       RRO Object-Class is to be assigned by IANA (recommended value=8)
       RRO Object-Type is to be assigned by IANA (recommended value=1)

       7.10. LSPA Object

       The LSPA object specifies various
   bandwidth of a existing TE LSP attributes to be taken into
       account by the PCE during path computation. LSP for which a reoptimization is being
   performed.

   The LSPA (LSP Attributes) BANDWIDTH object can either may be carried within a PCReq message or a and PCRep
       message in case messages.

   The absence of unsuccessful path computation (in this case, the
       PCReq message also comprises a NO-PATH object and the LSPA BANDWIDTH object is
       used to indicate the set of constraint(s) that could not MUST be
       satisfied). Most of the fields of interpreted by the LSPA object are identical PCE as
   a path computation request related to
       the fields of the SESSION-ATTRIBUTE object defined in [RSVP-TE] and
       [FRR].

       LSPA a 0 bandwidth TE LSP.

   BANDWIDTH Object-Class is to be assigned by IANA (recommended value=9)
   value=5)

   Two Objects-Types Object-Type are defined for the LSPA BANDWIDTH object: LSPA without
       resource affinity (Object-Type

   o  Requested bandwidth: BANDWIDTH Object-Type is to be assigned by
      IANA with
       recommended (recommended value=1) and LSPA with resource affinity (Object-type=2).

   o  Bandwidth of an existing TE LSP for which a reoptimization is
      performed.  BANDWIDTH Object-Type is to be assigned by IANA
      (recommended value=2)

   The format of the LSPA BANDWIDTH object body with and without resource affinity
       are 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Setup Prio   |  Holding Prio |  Flags  |N|B|L|    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                     Optional TLV(s)                         //
       |                        Bandwidth                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 16 - LSPA 14: BANDWIDTH object body format (without resource affinity)

       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  |N|B|L|    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       //                     Optional TLV(s)                         //
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 17 - LSPA
   Bandwidth: 32 bits.  The requested bandwidth is encoded in 32 bits in
   IEEE floating point format, expressed in bytes per second.

   The BANDWIDTH object body format (with resource affinity)

       Setup Priority (8 bits)

         The priority has a fixed length of 4 octets.

7.7.  METRIC Object

   The METRIC object is optional and can be used for several purposes.

   In a PCReq message, a PCC MAY insert a METRIC object:

   o  To indicate the session with respect metric that must be optimized by the path
      computation algorithm.  Currently, two metrics are defined: the
      IGP cost and the TE metric (see [RFC3785]).

   o  To indicate a bound on the path cost than must not be exceeded for
      the path to taking resources,
         in be considered as acceptable by the range of 0 PCC.

   In a PCRep message, the METRIC object MAY be inserted so as to 7.  The value 0 is
   provide the highest priority. 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 Setup Priority is path computation algorithmic aspects used in deciding whether this session can
          preempt another session.

       Holding Priority

          The priority of by the session PCE to optimize
   a path with respect to holding resources, a specific metric are outside the scope of
   this document.

   It must be understood that such path metric is only meaningful if
   used consistently: for instance, if the delay of a path computation
   segment is exchanged between two PCE residing in different domains,
   consistent ways of defining the range delay must be used.

   The absence of 0 the METRIC object MUST be interpreted by the PCE as a
   path computation request for which the PCE may choose the metric to 7.  The value 0
   be used.

   METRIC Object-Class is the highest priority.
          Holding Priority to be assigned by IANA (recommended value=6)

   METRIC Object-Type is used in deciding whether this session can to be preempted assigned by another session. IANA (recommended value=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

   T (Type - 3 bits): Specifies the metric type.  Two values are
   currently defined:

   o  T=1: The flags L, IGP metric

   o  T=2: The TE cost

   B and N correspond to the "Local protection desired"
       bit ([RSVP-TE]), "Bandwidth protection desired" bit ([FRR]) and (Bound - 1 bit): When set in a PCReq message, the "Node protection desired" bit ([FRR]) of metric-value
   indicates a bound (a maximum) for the SESSION-ATTRIBUTE Object
       respectively.

       L Flag (Local protection desired)

          When set, this means path cost that must not be
   exceeded for the PCC to consider the computed path MUST included links
          protected with Fast Reroute as defined in [FRR].

       B Flag (Bandwidth protection desired) acceptable.
   When set, this means that the computed path MUST included links
          protected with Fast Reroute as defined in [FRR] and that benefit
          from bandwidth protection. The B flag is cleared, the metric-value field MUST only be set to
   0x0000.  In a PCReq message, if the L
          flag B-flag is set.

       N Flag (Node protection desired) cleared, then the
   metric-value field MUST be set to 0.  The B flag MUST always be
   cleared in a PCRep message.

   C (Cost - 1 bit): When set, set in a PECReq message, this means indicates that
   the PCE MUST provide the computed path MUST included links
          protected cost (should a path satisfying
   the constraints be found) in the PCRep message with Fast Reroute as defined regards to the
   corresponding metric.

   Metric-value (32 bits): metric value encoded in 32 bits in [FRR] and that such
          links MUST be protected with NNOP (Next-next hop backup tunnel). IEEE
   floating point format.

   The N flag MUST only be set METRIC object body has a fixed length of 8 octets.

   Multiple METRIC Objects MAY be inserted in a PCRep or the L flag is set.

       Note that PCReq
   message.

   In a PCReq message the B flag and N flag are not exclusive.

       7.11. IRO Object

       The IRO (Include Route Object) presence of multiple METRIC object is optional and can be used
   to specify that the computed path must traverse a set of specified
       network elements. The IRO object multi-parameters (e.g. a metric may be carried within PCReq and
       PCRep messages.

          IRO Object-Class is to be assigned by IANA (recommended value=10)
          IRO Object-Type is a constraint or a
   parameter to be assigned minimize/maximize) objective function or multiple bounds
   for different constraints.

   In a PCRep message, unless not allowed by IANA (recommended value=1)

       0
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                             |
      //                       (subobjects)                          |
       |                                                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 18 - IRO objet body format

       Subobjects

       The IRO PCE policy, at least one
   METRIC object is made MUST be present that reports the computed path cost if
   the C bit of sub-object(s) identical to the ones defined RP object was set in [RSVP-TE], [G-MPLS] and [RSVP-UNNUM] for use the corresponding path
   computation request (the B-flag MUST be cleared); optionally the
   PCRep message may contain additional METRIC objects that correspond
   to bound constraints, in EROs.

       The following subobject types are supported:

       Type         Subobject
        1            IPv4 prefix
        2            IPv6 prefix
        4            Unnumbered  interface ID
       32            Autonomous system number

       The L bit of such sub-object has which case the metric-value MUST be equal to
   the corresponding path metric cost (the B-flag MUST be set).  If no meaning within an IRO object.

       The ERO object carried within a PCReq
   path satisfying the constraints could be found by the PCE, the METRIC
   objects MAY also be present in the PCRep message is exclusively used with the NO-PATH
   object, to indicate a constraint metric (B-Flag was set in the context of path
   computation request) that cannot be satisfied.

   Example: if a PCC sends a reoptimization path computation request, thus the
       need request to define a new object (IRO) PCE where the
   metric to specify optimize is the IGP metric and the inclusion TE metric must not
   exceed the value of
       specified network element(s) M, two METRIC object are inserted in a path.

       7.12. SVEC the PCReq
   message:

   o  First METRIC Object

       Section 8 details with B=0, T=1, metric-value=0x0000

   o  Second METRIC Object with B=1, T=2, metric-value=M

   If a path satisfying the circumstances under which it may set of constraints can be desirable
       and/or required found by the PCE
   and no policy preventing to correlate several provide the path computation requests. This
       leads to cost in place, the specification of PCE
   inserts one METRIC object with B=0, T=1, metric-value= computed IGP
   path cost.  Additionally, the SVEC PCE may insert a second METRIC object (Synchronization
       VECtor).
   with B=1, T=2, metric-value= computed TE path cost.

7.8.  ERO Object

   The SVEC ERO object is optional in used to encode a PCEP message. TE LSP.  The aim of the SVEC object ERO Object is carried
   within a PCReq PCRep message is to
       specify provide the computed TE LSP should have the correlation of M
   path computation requests. been successful.

   The SVEC contents of this object are identical in encoding to the contents
   of the Explicit Route Object defined in [RFC3209], [RFC3473] and
   [RFC3477].  That is, the object is constructed from a variable length object series of sub-
   objects.  Any RSVP ERO sub-object already defined or that lists could be
   defined in the set of M requests future for use in the ERO is acceptable in this
   object.

   PCEP ERO sub-object types correspond to RSVP ERO sub-object types.

   Since the computation of which MUST be synchronized. Each explicit path computation
       request is uniquely identified available for immediate signaling by the Request-ID-number carried
       within
   MPLS or GMPLS control plane, the respective RP object. The SVEC object also contains a set meanings of all of flags that specify the synchronization type.

       The SVEC sub-objects
   and fields in this object is carried within PCReq messages.

          SVEC are identical to those defined for the ERO.

   ERO Object-Class is to be assigned by IANA (recommended value=11)
          SVEC value=7)

   ERO Object-Type is to be assigned by IANA (recommended value=1)

       One Object-Type is defined for this

7.9.  RRO Object

   The RRO object is used to be assigned record the route followed by IANA
       with a recommended value of 1. TE LSP.  The format of the SVEC
   PCEP RRO object body is exclusively carried within a PCReq message so 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|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     RP Object #1                              |
       |                                                               |
       //                                                             //
       |                     RP Object #M                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 19 - SVEC body object format

       Flags

       Defines
   to specify the synchronization type between multiple path computation
       requests.

       L (Link diverse) bit: when set, route followed by a TE LSP for which a reoptimization
   is desired.

   The contents of this indicates 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-
   objects.  Any RSVP RRO sub-object already defined or that could be
   defined in the computed
       paths corresponding to the requests specified by future for use in the following RP
       objects MUST not have any link RRO is acceptable in common.

       N (Node diverse) bit: when set, this indicates that the computed
       paths corresponding to the requests specified by
   object.

   The meanings of all of the following RP
       objects MUST not have any node sub-objects and fields in common.

       S (SRLG diverse) bit: when set, this indicates that the computed
       paths corresponding object are
   identical to those defined for the requests specified RRO.

   PCEP RRO sub-object types correspond to RSVP RRO sub-object types.

   RRO Object-Class is to be assigned by the following RP
       objects MUST not share any SRLG (Shared Risk Link Group). IANA (recommended value=8)

   RRO Object-Type is to be assigned by IANA (recommended value=1)

7.10.  LSPA Object

   The flags defined above are not exclusive.

       7.13. NOTIFICATION LSPA object is optional and specifies various TE LSP attributes
   to be taken into account by the PCE during path computation.  The NOTIFICATION
   LSPA (LSP Attributes) object is exclusively can either be carried within a PCNtf PCReq
   message
       and can either be used in or a PCRep message sent by in case of unsuccessful path computation
   (in this case, the PCRep message also comprises a PCC NO-PATH object and
   the LSPA object is used to a PCE or by a
       PCE indicate the set of constraint(s) that
   could not be satisfied).  Most of the fields of the LSPA object are
   identical to a PCC so as the fields of the SESSION-ATTRIBUTE object defined in
   [RFC3209] and [RFC4090].  When absent from the PCReq message, this
   means that the Setup and Holding priorities are equal to notify of an event.

       NOTIFICATION 0, and there
   are no affinity constraints.

   LSPA Object-Class is to be assigned by IANA (recommended
       value=12)
       NOTIFICATION Object-Type is to be assigned by IANA (recommended
       value=1)

       One Object-Type is value=9)

   Two Objects-Types are defined for this object the LSPA object: LSPA without
   resource affinity (Object-Type to be assigned by IANA with a
   recommended value of 1. value=1) and LSPA with resource affinity (Object-type=2).

   The format of the NOTIFICATION body LSPA object is body with and without resource affinity
   are 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length  Setup Prio   |  Holding Prio |  Flags      |L|    Reserved   | Notification-
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Notification-                                                               |
   //                     Optional TLV(s)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 16: LSPA object body format (without resource affinity)

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | type                       Exclude-any                             | value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Include-any                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Include-all                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Setup Prio   |  Holding Prio |  Flags  |L|     Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     Optional TLV(s)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 20 - NOTIFICATION body 17: LSPA object body format

       Length

           The Length contains the total length of the object in bytes and
           includes the Type and Length fields.  This length must be a
           multiple of 4 and must be at least 12.

       Flags

           No flags are currently defined

       A NOTIFICATION object is characterized by a Notification-type that
       specifies the class of notification and the Notification-value that
       provides additional information related to the nature of the
       notification. Both the Notification-type and Notification-value
       should be managed by IANA (see IANA section). (with resource affinity)

   Setup Prio (Setup Priority - 8 bits).  The following Notification-type and Notification-value values are
       currently defined:

       Notification-type=1: Pending Request cancelled

       Notification-value=1: PCC cancels a set priority of pending request(s)

           A Notification-type=1, Notification-value=1 indicates that the
           PCC wants session
   with respect to inform a PCE of taking resources, in the cancellation of a set of
           pending request(s). Such event could be triggered because range of
           external conditions such as 0 to 7.  The value
   0 is the receipt of a positive reply from highest priority.  The Setup Priority is used in deciding
   whether this session can preempt another PCE (should the PCC have sent multiple requests to a set session.

   Holding Prio (Holding Priority - 8 bits).  The priority of PCEs for the same path computation request), a network event
           such as a network failure rendering
   session with respect to holding resources, in the request obsolete or any
           other event(s) local range of 0 to 7.
   The value 0 is the PCC. A NOTIFICATION object with
           Notification-type=1, Notification-value=1 highest priority.  Holding Priority is exclusively carried
           within a PCNtf message sent used in
   deciding whether this session can be preempted by the PCC another session.
   Flags
   The flag L corresponds to the PCE. The RP object
           MUST also be present in "Local protection desired" bit
   ([RFC3209]) of the PCNtf message. Multiple RP objects
           may be carried within SESSION-ATTRIBUTE Object.

   L Flag (Local protection desired).  When set, this means that the PCNtf message
   computed path must include links protected with Fast Reroute as
   defined in which case the
           notification applies to all of them. If such notification [RFC4090].

7.11.  IRO Object

   The IRO (Include Route Object) object 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 request(s)

           A Notification-type=1, Notification-value=2 indicates optional and can be used to
   specify that the
           PCE wants to inform computed path must traverse a PCC of the cancellation set of specified
   network elements.  The IRO object 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
           pending request(s). Such event elements that could not be triggered because
   included.

   IRO Object-Class is to be assigned by IANA (recommended value=10)

   IRO Object-Type is to be assigned by IANA (recommended value=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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 18: IRO object body format
   Subobjects The IRO object is made of
           some PCE congested state or because sub-object(s) identical to the
   ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs.

   The following subobject types are supported.

   Type   Subobject
        1   IPv4 prefix
        2   IPv6 prefix
        4   Unnumbered Interface ID
       32   Autonomous system number
   The L bit of some such sub-object has no meaning within an IRO object.

7.12.  SVEC Object

7.12.1.  Independent versus synchronized path computation requests that are part

   The PCEP protocol allows for the set bundling of synchronized multiple independent
   path computation requests are missing. A NOTIFICATION object with Notification-
           type=1, Notification-value=2 is exclusively carried within a
           PCNtf message sent by a PCE to a PCC. The RP object MUST also be
           present in the PCNtf single PCRep message. Multiple RP objects may be
           comprised within the PCNtf message in which case the
           notification applies to all  A set of them. If such notification
   path computation requests is
           received said to be non synchronized if their
   respective treatment (path computations) can be performed by a PCE from in
   a PCC, the PCE MUST silently ignore the
           notification serialized and no errors should be generated.

       Notification-type=2: PCE congestion

       Notification-value=1

           A Notification-type=2, Notification-value=1 indicates to the
           PCC(s) that independent fashion.

   There are various circumstances where the PCE is currently in synchronization of a congested state. If no RP
           objects are comprised in set of
   path computations may be beneficial or required.

   Consider the PCNtf message, this indicates that
           no other case of a set of N TE LSPs for which a PCC needs to send
   path computation requests SHOULD be sent to that PCE until a PCE.  The first solution consists of
   sending N separate PCReq messages to the congested
           state is cleared: selected PCE.  In this case,
   the pending path computation requests are not affected and will
           be served. If some pending requests cannot be served due to independent.  Note that the
           congested state, PCC may
   chose to distribute the PCE MUST also include a set of RP object(s) N requests across K PCEs for load
   balancing reasons.  Considering that identifies the set of pending M (with M<N) requests which will not be
           honored and which will are sent
   to a particular PCEi, as described above, such M requests can be cancelled by the PCE. In this case, sent
   in the PCE does not have form of successive PCReq messages destined to send an additional PCNtf message with
           Notification-type=1 PCEi or grouped
   within a single PCReq message.  This is of course a viable solution
   if and Notification-value=2 since only if such requests are independent.  That said, it can be
   desirable to request from the list of
           cancelled requests is specified by including PCE the corresponding
           set computation of RP object(s). If such notification is received by their paths in a
   synchronized fashion that is likely to lead to more optimal path
   computations and/or reduced blocking probability if the PCE
           from is a PCC,
   stateless PCE.  In other words, the PCE MUST silently ignore should not compute the notification
   corresponding paths in a serialized and no
           errors independent manner but it
   should be generated.

           Optionally, a TLV named CONGESTION-DURATION may be included in rather simultaneously compute their paths.

   For example, trying to simultaneously compute the NOTIFICATION object that specifies paths of M TE LSPs
   may allow the duration during which
           no further request should be sent PCE to improve the PCE. Once this period
           has expired likelihood to meet multiple
   constraints.  Consider the PCE should no longer be considered in congested
           state.

           The CONGESTION-DURATION TLV is composed case of 1 octet two TE LSPs requesting N1 MBits/s
   and N2 MBits/s respectively and a maximum tolerable end-to-end delay
   for each TE LSP of X ms.  There may be circumstances where the type,
           1 octet specifying the number
   computation of bytes in the value field
           followed by a fix length value field first TE LSP irrespectively of 4 octets specifying the
           estimated PCE congestion duration in seconds. The CONGESTION-
           DURATION TLV is padded second TE LSP
   may lead to eight-octet alignment

           TYPE: To be assigned by IANA
           LENGTH: 4
           VALUE: estimated congestion duration in seconds

       Notification-value=2

           A Notification-type=2, Notification-value=2 indicates that the
           PCE impossibility to meet the delay criteria for the
   second TE LSP.  A second example is no longer in congested state and related to the bandwidth
   constraint.  It is available quite straightforward to process
           new provide examples where a
   serialized independent path computation requests. An implementation MUST make sure
           that a PCE sends such notification approach would lead to every PCC the
   impossibility to which a
           Notification message (with Notification-type=2, Notification-
           value=1) has been sent unless satisfy both requests (due to bandwidth
   fragmentation) while a CONGESTION-DURATION TLV has been
           included in the corresponding message and synchronized path computation would
   successfully satisfy both requests.  A last example relates to the PCE wishes
   ability to wait
           for avoid the expiration allocation of that period the same resource to multiple
   requests thus helping to reduce the call set up failure probability
   compared to the serialized computation of time before receiving new independent requests. An implementation

   Furthermore, if the PCC has to send a large number of path
   computation requests, it may decide also be desirable to cancel such
           notification if pack multiple
   requests within a single PCReq object so as to minimize the control
   plane overhead.  Note that the algorithm used by the PCC is in down state for to "pack" a specific period.
           A RECOMMENDED value for
   set of requests introduces some unavoidable trade-off between control
   plane load and delays and such delay algorithm is 1 hour. outside of the scope of
   this document.

   There are other cases where the computation of M requests must be
   synchronized an obvious example of which being the computation of M
   diverse paths.  If such
           notification is received by a PCE from paths are computed in a PCC, the PCE MUST
           silently ignore non-synchronized
   fashion this seriously increases the notification and no errors should be
           generated.

       It is RECOMMENDED probability of not being able to support some dampening notification procedure on
   satisfy all requests (sometimes also referred to as the well-know
   "trapping problem").  Furthermore, this would not allow a PCE so to
   implement objective functions such as trying to avoid too frequent congestion notifications and
       releases. For example, an implementation could make use minimize the sum of an
       hysteresis approach using
   the TE LSP costs.  In such a dual-thresholds mechanism triggering case, the
       sending path computation requests must
   be synchronized: they cannot be computed independently of congestion notifications and releases. Furthermore, in
       case each other.

   The synchronization of high instabilities a set of path computation requests is achieved
   by using the SVEC object that specifies the list of synchronized
   requests along with the PCE resources, an additional
       dampening mechanism SHOULD nature of the synchronization.

7.12.2.  SVEC Object

   Section 7.12.1 details the circumstances under which it may be used (linear or exponential)
   desirable and/or required to pace
       the notification frequency and avoid synchronize a set of path computation requests
       oscillation.

       7.14. PCEP-ERROR
   requests.  The SVEC (Synchronization VECtor) object allows a PCC to
   request such synchronization.  The PCEP-ERROR SVEC object is exclusively optional and may be
   carried within a PCErr message
       and can either be used in PCReq message.

   The aim of the SVEC object carried within a PCReq message sent by a PCC to a PCE or by a
       PCE is to
   specify the correlation of M path computation requests.  The SVEC
   object is a PCC to notify 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 PCEP protocol error.

           PCEP-ERROR set of flags that specify the synchronization type.

   SVEC Object-Class is to be assigned by IANA (recommended
       value=13)
           PCEP-ERROR value=11)

   SVEC Object-Type is to be assigned by IANA (recommended value=1)

   One Object-Type is defined for this object to be assigned by IANA
   with a recommended value of 1.

   The format of the PCEP-ERROR 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length   Reserved    |                   Flags    |   Error-Type  |  Error-Value  |                 |S|N|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
       //                     Optional TLV(s)                         //                     Request-ID-number #1                      |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 21 - PCEP-ERROR object body format

       A PCEP-ERROR object is used to report a PCEP protocol 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 should be managed by
       IANA (see the IANA section).

       Length (8 bits)

           The Length contains the total length of the object in bytes
           including the Type and Length fields.  This length must be a
           multiple of 4 and must be at least 8.

       Flags (8 bits)

           No flag is currently defined.

       Error-type (8 bits)

           The Error-type defines the class of error.

       Error-value (8 bits)

           Provides additional details about the error.

       Optionally the PCErr message may contain additional TLV so as to
       provide further information about the encountered error. No TLV is
       currently defined.

       A single PCErr message may contain multiple PCEP-ERROR objects.

       For each PCEP protocol error, an Error type and value is defined.

       Error-Type    Meaning
          1          Capability not supported
          2          Unknown Object
                      Error-value=1: Unrecognized object class
                      Error-value=2: Unrecognized object Type
          3          Not supported object
                      Error-value=1: Not supported object class
                      Error-value=2: Not supported object Type
          4          Policy violation
                      Error-value=1: C bit set (request rejected)
                      Error-value=2: O bit set (request rejected)
          5          Required 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)
                      Error-value=3: END-POINTS
   //                                                             //
   |                     Request-ID-number #M                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 19: SVEC body object missing
          6          Synchronized format
   Flags: Defines the synchronization type between multiple path
   computation request missing
          7          Unknown request reference
          8          Unacceptable PCEP session characteristics
                      Error-value=1: parameter negotiation
                      Error-value=2: parameters negotiation failed
          9          Deadtimer expired
       In case of the Error-Type 1, the PCE requests.

   L (Link diverse) bit: when set, this indicates that the path
       computation request cannot be completed because it does not support
       one or more required capability. The computed
   paths corresponding path computation
       request MUST then be cancelled.

       If a PCEP message is received that carries a mandatory PCEP object (P
       flag cleared) not recognized to the requests specified by the PCEP peer or recognized but following RP
   objects MUST not
       supported, then have any link in common.

   N (Node diverse) bit: when set, this indicates that the PCEP peer MUST send a PCErr message with a PCEP-
       ERROR object (Error-Type=2 and 3 respectively). The computed
   paths corresponding
       path computation request MUST be cancelled to the requests specified by the PCE without further
       notification.

       If a path computation request is received which is following RP
   objects MUST not compliant with
       an agreed policy between have any node in common.

   S (SRLG diverse) bit: when set, this indicates that the PCC and computed
   paths corresponding to the PCE, requests specified by the PCE MUST send a
       PCErr message with a PCEP-ERROR object (Error-Type=4). The
       corresponding path computation following RP
   objects MUST be cancelled.

       If a path computation request is received that does not contain a
       required object, the PCE MUST send a PCErr message with a PCEP-ERROR
       object (Error-Type=5). If there share any SRLG (Shared Risk Link Group).

   The flags defined above are multiple mandatory objects
       missing, not exclusive.

7.12.3.  Handling of the PCErr message MUST contain one PCEP-ERROR object per
       missing object. SVEC Object

   The corresponding path computation MUST be cancelled.

       If SVEC object allows a PCC sends to specify a synchronized list of M path computation request to a PCE and
   requests that must be synchronized along with the PCE does not receive all nature of the synchronized
   synchronization.  The set of M path computation requests listed may be sent
   within the corresponding SVEC object during a
       configurable period of time, single PCReq message or multiple PCReq message.  In the
   later case, it is RECOMMENDED for the PCE MUST send to implement a PCErr local timer
   upon the receipt of the first PCReq message with a
       PCEP-ERROR that comprises the SVEC
   object (Error-Type=6). The corresponding synchronized after the expiration of which, if all the M path computation MUST be cancelled.

       If a PCC receives
   requests have not been received, a PCRep message related to an unknown path
       computation request, protocol error is triggered (this
   timer is called the PCC MUST send a PCErr message with a PCEP-
       ERROR object (Error-Type=6). SyncTimer).  In addition, this case the PCC PCE MUST include in the
       PCErr message the unknown RP object.

       If one or more characteristic(s) is not acceptable by cancel the receiving
       peer, it
   whole set of path computation requests and MUST send a PCErr message
   with Error-type=8, Error-value=1.
       The PCErr Error-Type="Synchronized path computation request missing".

   Note that such PCReq message MUST may also comprise an Open object: for each
       unacceptable session parameter, an acceptable parameter value MUST be
       proposed in non-synchronized path
   computation requests.  For example, the appropriate field of PCReq message may comprise N
   synchronized path computation requests related to RP 1, ... , RP N
   listed in the Open SVEC object along with any other path computation
   requests.

7.13.  NOTIFICATION Object

   The NOTIFICATION object is exclusively carried within a PCNtf message
   and can either be used in place of the
       originally proposed value. If a second Open 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 received to be assigned by IANA (recommended
   value=12)

   NOTIFICATION Object-Type is to be assigned by IANA (recommended
   value=1)

   One Object-Type is defined for this object to be assigned by IANA
   with
       the same set a recommended value of 1.

   The format of parameters or with parameters differing from the
       proposed values, 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 TLV(s)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 20: NOTIFICATION body object format
   NT (Notification Type - 8 bits): the receiving peer MUST send a PCErr message with
       Error-Type=8, Error-value=2 and it MUST immediately close Notification-type specifies the TCP
       connection.

       If a PCEP peer does not receive any PCEP message (Keepalive, PCReq,
       PCRep, PCNtf) during
   class of notification

   NV (Notification Value - 8 bits): the Deadtimer period (equal Notification-value provides
   addition information related to four times the
       Keepalive value advertised in the OPEN object) nature of the PCEP peer MUST
       send a PCErr message with a PCEP-ERROR object (Error-type=9, Error-
       value=1). Additionally, notification.

   Flags: no flags are currently defined.

   Both the PCEP session MUST be terminated Notification-type and the
       TCP connection MUST Notification-value should be closed.

     8. Independent versus synchronized path computation requests managed
   by IANA.

   The PCEP protocol permits the bundling of multiple independent path
       computation requests within following Notification-type and Notification-value values are
   currently defined:

   o  Notification-type=1: Pending Request cancelled

      *  Notification-value=1: PCC cancels a single PCRep message. A set of path
       computation requests is said pending request(s).
         A Notification-type=1, Notification-value=1 indicates that the
         PCC wants to be non synchronized if their
       respective treatment (path computations) can be performed by inform a PCE in
       a serialized and independent fashion.

       There are various circumstances where of the synchronization cancellation of a set of
       path computations may
         pending request(s).  Such event could be beneficial or required.

       Consider the case triggered because of a set
         external conditions such as the receipt of N TE LSPs for which a PCC needs to send
       path computation requests to a positive reply
         from another PCE so as to obtain their respective
       paths. The first solution consists of sending N separate PCReq
       messages to the selected PCE. In this case, the path computation
       requests are independent. Note that (should the PCC may chose have sent multiple requests to distribute
       the
         a set of N requests across K PCEs for load balancing reasons.
       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 grouped within a single
       PCReq message. This is of course same path computation request), a viable solution if and only if network
         event such requests are independent. That said, it can be desirable to
       request from the PCE the computation of their paths in as a synchronized
       fashion that is likely to lead network failure rendering the request obsolete
         or any other event(s) local to more optimal path computations
       and/or reduced blocking probability if the PCE PCC.  A NOTIFICATION object
         with Notification-type=1, Notification-value=1 is exclusively
         carried within a stateless PCNtf message sent by the PCC to the PCE. In
       other words,  The
         RP object MUST also be present in the PCE should not compute PCNtf message.  Multiple
         RP objects may be carried within the corresponding paths PCNtf message in which
         case the notification applies to all of them.  If such
         notification is received by a
       serialized PCC from a PCE, the PCC MUST
         silently ignore the notification and independent manner but it no errors should rather simultaneously
       compute their paths.

       For example, trying to simultaneously compute the paths be
         generated.

      *  Notification-value=2: PCE cancels a set of M TE LSPs
       may allow pending request(s).
         A Notification-type=1, Notification-value=2 indicates that the
         PCE wants to improve the likelihood to meet multiple
       constraints. Consider inform a PCC of the case cancellation of two TE LSPs requesting N1 MBits/s
       and N2 MBits/s respectively and a maximum tolerable end to end delay
       for each TE LSP set of X ms. There may
         pending request(s).  Such event could be circumstances where the
       computation triggered because of
         some PCE congested state or because of some path computation
         requests that are part the first TE LSP irrespectively set of synchronized path computation
         requests are missing.  A NOTIFICATION object with Notification-
         type=1, Notification-value=2 is exclusively carried within a
         PCNtf message sent by a PCE to a PCC.  The RP object MUST also
         be present in the second TE LSP PCNtf message.  Multiple RP objects may lead to be
         comprised within the PCNtf message in which case the impossibility
         notification applies to meet all of them.  If such notification is
         received by a PCE from a PCC, the delay criteria for PCE MUST silently ignore the
       second TE LSP.
         notification and no errors should be generated.

   o  Notification-type=2: PCE congestion

      *  Notification-value=1.  A second example is related Notification-type=2, Notification-
         value=1 indicates to the bandwidth
       constraint. It PCC(s) that the PCE is quite straightforward to provide examples where currently in a
       serialized independent path computation approach would lead to
         congested state.  If no RP objects are comprised in the
       impossibility to satisfy both PCNtf
         message, this indicates that no other requests (due to bandwidth
       fragmentation) while a synchronized path computation would
       successfully satisfy both requests. A last example relates to the
       ability SHOULD be sent
         to avoid that PCE until the allocation of congested state is cleared: the same resource to multiple pending
         requests thus helping are not affected and will be served.  If some pending
         requests cannot be served due to reduce the call congested state, the PCE
         MUST also include a set up failure probability
       compared to of RP object(s) that identifies the serialized computation set
         of independent requests.

       Furthermore, if pending requests that are now cancelled by the PCC has PCE and will
         not be honored.  In this case, the PCE does not have to send a large number an
         additional PCNtf message with Notification-type=1 and
         Notification-value=2 since the list of path
       computation requests, it may also be desirable to pack multiple cancelled requests within is
         specified by including the corresponding set of RP object(s).
         If such notification is received by a single PCReq object so as to minimize PCE from a PCC, the PCE
         MUST silently ignore the notification and no errors should be
         generated.

   Optionally, a TLV named CONGESTION-DURATION may be included in the control
       plane overhead. Note
   NOTIFICATION object that specifies the algorithm used by the PCC duration during which no further
   request should be sent to "pack"
       a set of requests introduces some unavoidable trade-off between control
       plane load and delays and such algorithm is outside of the scope of PCE. Once this document.

       There are other cases where period has expired the computation of M requests must PCE
    should no longer be
       synchronized an obvious example considered in congested state.

   The CONGESTION-DURATION TLV is composed of which being 1 octet for the computation type,
   1 octet specifying the number of M
       diverse paths. If such paths are computed bytes in a non-synchronized
       fashion this seriously increases the probability value field, 2 octets
   for an "Unused" field (the value of not being able to
       satisfy all requests (sometimes also referred which MUST be set to as the well-know
       "trapping problem"). Furthermore, this would not allow 0), followed by
   a fix length value field of 4 octets specifying the estimated PCE
   congestion duration in seconds. The CONGESTION-DURATION TLV is padded
   to
       implement objective functions such as trying to minimize eight-octet alignment.

   TYPE: To be assigned by IANA
   LENGTH: 4
   VALUE: estimated congestion duration in seconds

      *  If a new PCEP session is established while the sum of PCE is in
         congested state, the TE LSP costs. In such PCE MUST immediately send a case, PCErr with
         Notification-type=2, Notification-value=1 along with optionally
         the CONGESTION-DURATION TLV.

      *  Notification-value=2.  A Notification-type=2, Notification-
         value=2 indicates that the PCE is no longer in congested state
         and is available to process new path computation requests are
       synchronized: they cannot be computed independently of each other.

       The synchronization of a set of path computation requests is
       achieved by using the SVEC object requests.  An
         implementation MUST make sure that specifies a PCE sends such
         notification to every PCC to which a Notification message (with
         Notification-type=2, Notification-value=1) has been sent unless
         a CONGESTION-DURATION TLV has been included in the list of
       synchronized requests along with
         corresponding message and the nature of PCE wishes to wait for the synchronization.

     9. Elements
         expiration of procedure

       9.1. Non recognized or non support object received that period of time before receiving new
         requests.  An implementation may decide to cancel such
         notification if the PCC is in down state for a PCReq message specific period.
         A RECOMMENDED value for such delay is 1 hour.  If a PCEP message such
         notification is received that carries a mandatory PCEP object (P
       flag cleared) not recognized by the a PCE or recognized but not
       supported, then from a PCC, the PCE MUST send a PCErr message with a PCEP-ERROR
       object (Error-Type=2
         silently ignore the notification and 3 respectively). In addition, no errors should be
         generated.  It is RECOMMENDED to support some dampening
         notification procedure on the PCRep
       message MUST comprise PCE so as to avoid too frequent
         congestion notifications and releases.  For example, an
         implementation could make use of an hysteresis approach using a
         dual-thresholds mechanism triggering the set sending of non recognized congestion
         notifications and releases.  Furthermore, in case of high
         instabilities of the PCE resources, an additional dampening
         mechanism SHOULD be used (linear or non supported
       object(s). The corresponding exponential) to pace the
         notification frequency and avoid path computation request MUST be
       cancelled by the PCE without further notification.

       9.2. RP object requests
         oscillation.

7.14.  PCEP-ERROR Object

   The absence of a RP PCEP-ERROR object in the PCReq message MUST trigger the
       sending of is exclusively carried within a PCErr message with Error-type=5 and Error-value=1.

       If the C bit
   to notify of the RP message carried within a PCReq message PCEP protocol error.

   PCEP-ERROR Object-Class is set
       and some local policy has been configured on the PCE not to provide
       such cost, a PCErr message MUST be sent assigned by the PCE IANA (recommended
   value=13)

   PCEP-ERROR Object-Type is to the requesting
       PCC and the pending path computation request MUST be discarded. assigned by IANA (recommended
   value=1)

   One Object-Type is defined for this object to be assigned by IANA
   with a recommended value of 1.

   The
       Error-type and Error-value format of the PCEP-ERROR object MUST be set to body is as follows:
    0                   1                   2                   3
    0 1 2 3 4
       and 5 6 7 8 9 0 1 respectively.

       If 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 TLV(s)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 21: PCEP-ERROR object body format
   A PCEP-ERROR object is used to report a PCEP protocol error and is
   characterized by an Error-Type that specifies the O bit type of error and
   an Error-value that provides additional information about the RP message carried within a PCReq message is set error
   type.  Both the Error-Type and some local policy has been configured on the PCE Error-Value should be managed by
   IANA (see the IANA section).

   Flags (8 bits): no flag is currently defined.

   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 TLV so as to not
   provide
       explicit path(s) (for instance, for confidentiality reasons), then a further information about the encountered error.  No TLV is
   currently defined.

   A single PCErr message MUST be sent by the PCE to the requesting PCC and the
       pending path computation request MUST be discarded. The may contain multiple PCEP-ERROR objects.

   For each PCEP protocol error, an Error-type and an Error-value are
   defined.
   Error-Type    Meaning
      1          Capability not supported
      2          Unknown Object
                  Error-value=1: Unrecognized object class
                  Error-value=2: Unrecognized object Type
      3          Not supported object
                  Error-value=1: Not supported object class
                  Error-value=2: Not supported object Type
      4          Policy violation
                  Error-value=1: C bit of the PCEP-ERROR METRIC object MUST be set to 4 and 2
       respectively.

       R bit: when the R (request rejected)
                  Error-value=2: O bit of the RP object is set in (request rejected)
      5          Mandatory Object missing
                  Error-value=1: RP object missing
                  Error-value=2: RRO object missing for a PCReq message,
       this indicates that the path computation request relates to the reoptimization
                                 request (R bit of an existing TE LSP. In this case, the PCC MUST
       provide the explicit or strict/loose path by including an RRO RP object
       in the PCReq message so as to avoid double bandwidth counting (unless
       the TE LSP is a 0-bandwidth TE LSP). If the PCC has previously
       requested a non-explicit set)
                  Error-value=3: END-POINTS object missing
      6          Synchronized path (O bit set), a reoptimization can still
       be requested by the PCC but this implies for computation request missing
      7          Unknown request reference
      8          Unacceptable PCEP session characteristics
                  Error-value=1: parameter negotiation
                  Error-value=2: parameters negotiation failed
      9         Deadtimer expired

   Error-Type=1: the PCE to be either
       stateful (keep track of indicates that the previously computed path with the
       associated list of strict hops) computation request
   cannot be completed because it does not support one or to have the ability to retrieve
       the complete more required
   capability.  The corresponding path segment, computation request MUST be
   cancelled.

   Error-Type=2 or for PCC to inform PCE of the
       working path with associated list of strict hops in PCReq. The
       absence of an RRO in the PCReq Error-Type=3: if a PCEP message when is received that
   carries a PCEP object (with the R bit of P flag set) not recognized by the RP
       object is set MUST trigger PCE
   or recognized but not supported, then the sending of PCE MUST send a PCErr
   message with Error-
       type=5 a PCEP-ERROR object (Error-Type=2 and Error-value=2.

       If 3 respectively).
   The corresponding path computation request MUST be cancelled by the PCC receives
   PCE without further notification.

   Error-Type=4: if a PCRep message path computation request is received which contains a RP object
       referring to is not
   compliant with an unknown Request-ID-Number, it MUST trigger agreed policy between the
       sending of PCC and the PCE, the PCE
   MUST send a PCErr message with Error-Type=7 and Error-value=1.

       9.3. SVEC object

       When a requesting PCC desires to send multiple synchronized PCEP-ERROR object (Error-Type=4).
   The corresponding path computation requests, it MUST send all the path computation requests be cancelled.  Policy-
   specific TLV(s) carried within a single PCReq message that contains all the synchronized PCEP-ERROR object may be defined
   in other documents to specify the nature of the policy violation.

   Error-Type=5: if a path computation requests: in request is received that case, does not
   contain a mandatory object, the PCReq message PCE MUST also
       comprise send a SVEC PCErr message with a
   PCEP-ERROR object (Error-Type=5).  If there are multiple mandatory
   objects missing, the PCErr message MUST contain one PCEP-ERROR object listing all the synchronized
   per missing object.  The corresponding path computation
       requests. Note that such PCReq message may also comprise non- MUST be
   cancelled.

   Error-Type=6: if a PCC sends a synchronized path computation requests. For example, request
   to a PCE and the PCE does not receive all the PCReq
       message may comprise N synchronized path
   computation requests related
       to RP 1, ... , RP N listed in within the corresponding SVEC object along with any other path
       computation requests.

       If some RPs objects carried with
   after the SVEC object are missing in expiration of the
       PCReq message, timer SyncTimer defined in
   Section 7.12.3, the PCE MUST send a PCErr message with Error-Type = 6
       to the PCC.

     10. Manageability Considerations

       It is expected and required to specify a MIB for the PCEP
       communication protocol (in a separate document).

       Furthermore, additional tools related to performance, fault and
       diagnostic detection are required which will also be specified in
       separate documents.

     11. IANA Considerations

       11.1. TCP port

       The PCEP protocol will use a well-known TCP port to be assigned by
       IANA.

       11.2. PCEP Objects
       Several new PCEP objects are defined in this document that have an
       Object-Class and an Object-Type. The new Object-Class and Object-Type
       should be assigned by IANA.

       - Open Object

       The Object-Class of the Open object is to be assigned by IANA
       (recommended value=1).

       One Object-Type is defined for this object and should be assigned by
       IANA with a recommended value of 1.

       - RP Object

       The Object-Class of the RP object is to be assigned by IANA
       (recommended value=2).

       One Object-Type is defined for this PCEP-ERROR
   object and should be assigned by
       IANA with a recommended value of 1.

       - NO-PATH Object (Error-Type=6).  The Object-Class of the NO-PATH object is to corresponding synchronized path
   computation MUST be assigned by IANA
       (recommended value=3).

       One Object-Type cancelled.  It is defined RECOMMENDED for this object and should be assigned by
       IANA with a recommended value of 1.

       - END-POINTS Object the PCE to
   include the REQ-MISSING TLV(s) (defined below) that identifies the
   missing request(s).

   The Object-Class REQ-MISSING TLV is composed of 1 octet for the END-POINTS object is to be assigned by IANA
       (recommended value=4).

       Two Object-Type are defined type,
   1 octet specifying the number of bytes in the value field, 2 octets
   for this object and should an "Unused" field (the value of which MUST be assigned set to 0), followed by
       IANA with
   a recommended fix length value field of 1 and 2 for IPv4 and IPv6
       respectively.

       - BANDWIDTH Object

       The Object-Class of 4 octets specifying the BANDWIDTH object request-id-number
   that correspond to the missing request. The REQ-MISSING TLV is padded
   to eight-octet alignment.

   TYPE: To be assigned by IANA
       (recommended value=5).

       One Object-Type is defined for this
   LENGTH: 4
   VALUE: request-id-number that corresponds to the missing request

   Error-Type=7: 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 and should be assigned (Error-Type=7).  In addition, the PCC MUST include
   in the PCErr message the unknown RP object.

   Error-Type=8: if one or more PCEP session characteristic(s) are not
   acceptable by
       IANA the receiving peer and are not negotiable, it MUST send
   a PCErr message with Error-type=8, Error-value=1.  Conditions under
   which such error message is sent are detailed in Section 6.2

   Error-Type=9: If a recommended value of 1.

       - DELAY Object

       The Object-Class of PCEP peer does not receive any PCEP message
   (Keepalive, PCReq, PCRep, PCNtf) during the DELAY Deadtimer period, the
   PCEP peer MUST send a PCErr message with a PCEP-ERROR object is to (Error-
   type=9, Error-value=1).  The PCEP session MUST be assigned by IANA
       (recommended value=6).

       One Object-Type is terminated
   according to the procedure defined for this object and should be assigned by
       IANA with a recommended value of 1.

       - ERO in Section 6.8.

7.15.  CLOSE Object

   The Object-Class of the ERO CLOSE object is to MUST be assigned by IANA
       (recommended value=7).

       One Object-Type is defined for this object and should present in each Close message.  There MUST
   be assigned by
       IANA with a recommended value of 1.

       - RRO Object

       The Object-Class of the RRO only one CLOSE object per Close message.

   CLOSE Object-Class is to be assigned by IANA (recommended value=8).

       One value=14)

   CLOSE Object-Type is defined for this object and should to be assigned by IANA with a recommended value of 1.

       - LSPA Object (recommended value=1)
   The Object-Class format of the LSPA CLOSE object body is to be assigned by IANA
       (recommended value=9).

       Two Object-Types are defined for this object and should be assigned
       by IANA with a recommended value of as follows:
    0             1 (without resource affinity) and               2 (with resource affinity).

       - IRO               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 TLV(s)                     //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 14: CLOSE Object

       The Object-Class of format
   Reason (4 bits): specifies the IRO object is to be assigned by IANA
       (recommended value=10).

       One Object-Type is defined reason for this object and should be assigned by
       IANA with a recommended value closing the PCEP session.
   The setting of 1.

       - SVEC Object this field is optional.  Two values are currently
   defined.

   Reasons
    Value        Meaning
      1          No explanation provided
      2          DeadTimer expired
      3          PCEP session characteristics negotiation failure
   Flags (4 bits): No Flags are currently defined.

   Optional TLVs may be included within the CLOSE object body.  The Object-Class
   specification of such TLVs is outside the SVEC object scope of this document.

8.  Manageability Considerations

   It is expected and required to be assigned by IANA
       (recommended value=11).

       One Object-Type is defined specify a MIB for this object the PCEP
   communication protocol (in a separate document).  Furthermore,
   additional tools related to performance, fault and should diagnostic
   detection are required which will also be assigned by specified in separate
   documents.

9.  IANA with a recommended value of 1.

       - NOTIFICATION Object Considerations

9.1.  TCP Port

   The Object-Class of the NOTIFICATION object is PCEP protocol will use a well-known TCP port to be assigned by
   IANA.

9.2.  PCEP Messages

   Each PCEP message has a Message-Type.

   Value    Meaning
     1        Open
     2        Keepalive
     3        Path Computation Request
     4        Path Computation Reply
     5        Notification
     6        Error
     7        Close

9.3.  PCEP Object

   IANA
       (recommended value=12).

       One Object-Type is defined for this assigns value to PCEP parameters.  Each PCEP object has an
   Object-Class and should be assigned by
       IANA with a recommended value of 1.

       - PCEP-ERROR Object
       The an Object-Type.

   Object-Class      Name

          1                 OPEN
                            Object-Type
                               1

          2                 RP
                            Object-Type
                               1

          3                 NO-PATH
                            Object-Type
                               1

          4                 END-POINTS
                            Object-Type
                               1 : IPv4 addresses
                               2: IPv6 addresses

          5                 BANDWIDTH
                            Object-Type
                               1: Requested bandwidth
                               2: Bandwidth of the PCEP-ERROR object an existing TE LSP
                                  for which a reoptimization is to be assigned by IANA
       (recommended value=13).

       One performed.

          6                 METRIC
                            Object-Type is defined for this object and should be assigned by
       IANA
                               1

          7                 ERO
                            Object-Type
                               1

          8                 RRO
                            Object-Type
                               1

          9                 LSPA
                            Object-Type
                               1: without resource affinity
                               2: with a recommended value of 1.

       11.3. resource affinity

         10                 IRO
                            Object-Type
                               1

         11                 SVEC
                            Object-Type
                               1

         12                 NOTIFICATION
                            Object-Type
                               1

         13                 PCEP-ERROR
                            Object-Type
                               1

         14                 CLOSE
                            Object-Type
                               1

9.4.  Notification

   A NOTIFICATION object is characterized by a Notification-type that
   specifies the class of notification and a Notification-value that
   provides additional information related to the nature of the
   notification.  Both the Notification-type and Notification-value
       should be are
   managed by IANA (see IANA section).

       The following

   Notification-type and Notification-value values are
       currently defined:

       Notification-type=1:     Name
            1                    Pending Request cancelled

         Notification-value=1:
                                  Notification-value
                                           1: PCC cancels a set of pending request(s)

         Notification-value=2:
                                           2: PCE cancels a set of pending request(s)

       Notification-type=2:
            2                    PCE congestion

          Notification-value=1: Congestion
                                  Notification-value
                                           1: PCE in congested state

         Notification-value=2:
                                           2: PCE no longer in congested state

       11.4.

9.5.  PCEP Error

       A

   PCEP-ERROR object is objects are used to report a PCEP protocol error and is are
   characterized by an Error-Type which 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 should be are managed by IANA.

       Error-Type

   Error-type          Meaning
         1                  Capability not supported
                             Error-value
                                   1

         2                  Unknown Object
                      Error-value=1:
                             Error-value
                                   1: Unrecognized object class
                      Error-value=2:
                                   2: Unrecognized object Type

         3                  Not supported object
                      Error-value=1:
                             Error-value
                                   1: Not supported object class
                      Error-value=2:
                                   2: Not supported object Type

         4                  Policy violation
                      Error-value=1:
                             Error-value
                                   1: C bit of the METRIC object set (request rejected)
                      Error-value=2:
                                   2: O bit of the RP object set (request rejected)

         5          Required Object                  Mandatory object missing
                      Error-value=1:
                             Error-value
                                   1: RP object missing
                      Error-value=2:
                                   2: RRO object missing for a reoptimization request
                                      (R bit of the RP object set).
                      Error-value=3: set)
                                   3: END-POINTS object missing

         6                  Synchronized path computation request missing
                             Error-value
                                   1

         7                  Unknown request reference
                             Error-value
                                   1

         8                  Unacceptable PCEP session characteristics
                      Error-value=1: parameter negotiation
                      Error-value=2: parameters negotiation failed
                             Error-value
                                  1

         9                  Deadtimer expired

     12. expiration
                             Error-value
                                  1

10.  Security Considerations

   The PCEP communication protocol could be the target of the following attacks:
         -Spoofing

   o  Spoofing (PCC or PCE impersonation)
         -Snooping

   o  Snooping (message interception)
         -Falsification
         -Denial

   o  Falsification

   o  Denial of Service

   A PCEP attack may have significant impact, particularly in an inter-
       AS
   inter-AS context as PCEP facilitates inter-AS path establishment.
   Several mechanisms are proposed below, so as to ensure
   authentication, integrity and privacy of PCEP Communications, and
   also to protect against DoS attacks.

    12.1.

10.1.  PCEP Authentication and Integrity

   It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to
   provide for the authenticity and integrity of PCEP messages.  This
   will allow protecting against PCE or PCC impersonation and also
   against message content falsification.

   This requires the maintenance, exchange and configuration of MD-5
   keys on PCCs and PCEs.  Note that such maintenance may be especially
   onerous to the operators as pointed out in [BGP-SEC-REQ]. [I-D.ietf-rpsec-
   bgpsecrec].  Hence it is important to limit the number of keys while
   ensuring the required level of security.

   MD-5 signature faces some limitations, as per explained in [RFC2385].
   Note that when one digest technique stronger than MD5 is specified
   and implemented, PCEP could be easily upgraded to use it.

   12.2.

10.2.  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 intercept a PCE message
   could obtain sensitive information related to computed paths and
   resources.  Privacy can be ensured thanks to encryption.  To ensure
   privacy of PCEP communication, IPSec [IPSEC] [RFC2406] tunnels MAY be used
   between PCC and PCEs or between PCEs.  Note that this could also be
   used to ensure Authentication and Integrity, in which case, TCP MD-5
   option would not be required.

    12.3.

10.3.  Protection against Denial of Service attacks

   PCEP can be the target of TCP DoS attacks, such as for instance SYN
   attacks, as all protocols running on top of TCP.  PCEP can use the
   same mechanisms as defined in [LDP] [RFC3036] to mitigate the threat of
   such attacks:

       -

   o  A PCE should avoid promiscuous TCP listens for PCEP TCP session
      establishment.  It should use only listens that are specific to
      authorized PCCs.
       -

   o  The use of the MD5 option helps somewhat since it prevents a SYN
      from being accepted unless the MD5 segment checksum is valid.
      However, the receiver must compute the checksum before it can
      decide to discard an otherwise acceptable SYN segment.
       - The use of access-list on the PCE so as to restrict access to
       authorized PCCs.

     13. Intellectual Property Statement

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights or other rights that might be claimed to
       pertain to the implementation or use of the technology described in
       this document or the extent to which any license under such rights
       might or might not be available; nor does it represent that it has
       made any independent effort to identify any such rights. Information
       on the procedures with respect to rights in RFC documents can be
       found in BCP 78 and BCP 79.

       Copies of IPR disclosures made to the IETF Secretariat and any
       assurances of licenses to be made available, or the result of an
       attempt made to obtain a general license or permission for the use of
       such proprietary rights by implementers or users

   o  The use of this
       specification can be obtained from access-list on the IETF on-line IPR repository at
       http://www.ietf.org/ipr.

       The IETF invites any interested party PCE so as to bring restrict access to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights that may cover technology that
      authorized PCCs.

10.4.  Request input shaping/policing

   A PCEP implementation may be required to implement
       this standard. Please address the information subject to the IETF at ietf-
       ipr@ietf.org.

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

       Internet-Drafts are draft documents valid for sending a maximum very large number of six
       months and may be updated, replaced, or obsoleted by other documents
       at any time. It is inappropriate to use Internet-Drafts PCEP messages (e.g.
   PCReq messages).  Thus, especially in multi-Service Providers
   environments, a PCE implementation should implement request input
   shaping/policing so as  reference
       material or to cite them other than as "work in progress.

     14. Acknowledgment

       We throttle the amount of received PCEP
   messages without compromising the implementation behavior.

11.  Acknowledgements

   The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash,
   Igor Bryskin for their very valuable input.  Special thank to Adrian
   Farrel for his very valuable suggestions.

     15.

12.  References

       15.1.

12.1.  Normative references

       [RFC] References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to indicate
       requirements levels", RFC 2119, March 1997.

       [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
       RFC 3667, February 2004.

       [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
       Technology", Indicate
              Requirement Levels", BCP 79, 14, RFC 3979, 2119, March 2005.

       [RSVP] R. Braden et al., "Resource ReSerVation Protocol (RSVP) -
       Version 1 Functional Specification", RFC 2205, November 1997.

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

       [G-RSVP] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions",
       RFC 3473, January 2003.

       [RSVP-UNNUM] Kompella, K., Rekhter Y., "Signalling Unnumbered Links
       in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
       RFC 3477, January 2003.

       [COPS] Durham, D., "The COPS (Common Open Policy Service) Protocol",
       RFC 2748, January 2000.

       [SCTP] Stewart et al., "Stream Control Transmission Protocol",
       RFC2960, October 2000.

       [TCP] J. Postel, "Transmission Control Protocol", RFC 793, November
       1981.

       [DS-TE-PROTO] Le Faucheur et al,"Protocol extensions for support of
       Differentiated-Service-aware MPLS Traffic Engineering",

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 4124,
       June 2005.

       [G-RECV-E2E-SIG] J. P. Lang et al, "RSVP-TE Extensions in support of
       End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based
       Recovery", draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
       (working in progress).

       [FRR] P. Pan, 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, A. Atlas, JP. Vasseur, M. Jork, D.H Gan and
       D. Cooper, "Fast Reroute "RSVP-TE: Extensions to RSVP-TE RSVP for LSP
              Tunnels",
       RFC4090, May 2005.

       15.2  Informative References

       [WP] E. Rescorla, "Writting Protocol Models", RFC 4101, June 2005.

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

       [PCE-GEN-COM-REQ] J. Ash, J.L Le Roux et al., "PCE Communication
       Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-
       reqs, work Progress.

       [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support
       of Generalized 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-
       gmpls-routing, work in progress.

       [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al,
       "Requirements for inter-area MPLS Traffic Engineering", RFC4105, June
       2005.

       [INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req, work
       in progress.

       [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A
       Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-
       ccamp-inter-domain-framework, work in progress.

       [MGT] A. Farrel et al., "Requirements for Manageability Sections in
       Routing Area Drafts", draft-farrel-rtg-manageability-requirements,
       work in progress.

       [XRO] Lee et al, "Exclude Routes - Extension to RSVP-TE", drfat-ietf-
       ccamp-rsvp-te-exclude-route, work in progress.

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

       [BGP-SEC-REQ] B. Christian Ed., "BGP Security Requirements",
       draft-ietf-rpsec-bgpsecrec, work in progress

       [LDP] L. Andersson, et al., "LDP Specification", RFC3036, (RSVP-TE) Extensions", RFC 3473, January
       2001

       [DOBB] H. Dobbertin, "The Status of MD5 After a Recent Attack",
       RSALabs' CryptoBytes, Vol. 2 No. 2, Summer 1996.

       [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",RFC 1321,
       April 1992.

       [IPSEC] S. Kent, A. Atkinson, " IP Encapsulating Security Payload
       (ESP)", RFC2406, November 1998

     16. Authors' Address

       Jean-Philippe Vasseur (Editor)
       Cisco Systems, Inc.
       300 Beaver Brook Road
       Boxborough , MA - 01719
       USA
       Email: jpv@cisco.com

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

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

       Eiji Oki
       NTT
       Midori 3-9-11
       Musashino, Tokyo 180-8585
       JAPAN
       Email: oki.eiji@lab.ntt.co.jp

       Alia 2003.

   [RFC3477]  Kompella, K. Atlas
       Google Inc.
       1600 Amphitheatre Parkway
       Mountain View, CA 94043
       EMail: akatlas@alum.mit.edu

       Andrew Dolganow
       Alcatel
       600 March Rd., K2K 2E6 Ottawa, ON, Canada
       Phone: +1 (613)784 6285
       Email: andrew.dolganow@alcatel.com

       Yuichi Ikejiri
       NTT Communications Corporation
       1-1-6, Uchisaiwai-cho, Chiyoda-ku
       Tokyo 100-8019
       JAPAN
       Email: y.ikejiri@ntt.com
       Appendix A and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol - Compliance of PCEP Traffic Engineering
              (RSVP-TE)", RFC 3477, January 2003.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to the set of requirements specified
       in draft-ietf-pce-comm-protocol-gen-reqs

       [PCE-GEN-COM-REQ] lists a set of requirement RSVP-TE for the PCE
       communication protocol. The aim of the appendix A is to list the
       compliance of PCEP to such requirements. Note that requirements that
       are not satisfied in the context of the present version may be
       satisfied LSP Tunnels", RFC 4090,
              May 2005.

12.2.  Informative References

   [I-D.ietf-ccamp-inter-domain-rsvp-te]
              Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
              Engineering - RSVP-TE extensions",
              draft-ietf-ccamp-inter-domain-rsvp-te-02 (work in further revisions.

       The following legend is used
              progress), October 2005.

   [I-D.ietf-pce-architecture]
              Farrel, A., "A Path Computation Element (PCE) Based
              Architecture", draft-ietf-pce-architecture-04 (work in the table below:

       YES: PCEP fully fulfills the requirement
       ME (Minor Extension): PCEP could satisfy the requirement with minor
       extension(s).
       SE (Substantial Extension): PCEP could satisfy the requirement with
       substantial extension(s).
       NO: PCEP cannot meet the requirement without substantial redesign of
       the protocol.

       Requirement                                     Necessity  Compliance
       ------------------------------------------------------------------
       Commonality of PCC-PCE
              progress), January 2006.

   [I-D.ietf-pce-comm-protocol-gen-reqs]
              Roux, J. and PCE-PCE Communication    MUST      YES
       Client-Server J. Ash, "PCE Communication                         MUST      YES
       Support PCC/PCE request message to request path
       computation                                         MUST      YES
       Support PCE response message with computed path     MUST      YES
       Support unsolicited communication PCE-PCC           MUST      YES
       Maintain PCC-PCE session                            NON-RQMT
       Use of Existing Transport Protocol                  MAY       YES
       Transport Generic
              Requirements", draft-ietf-pce-comm-protocol-gen-reqs-04
              (work in progress), February 2006.

   [I-D.ietf-pce-disco-proto-igp]
              Roux, J., "IGP protocol satisfy reliability & security
       requirements                                        MAY       YES
       Transport Protocol Limits Size of Message           MUST NOT  YES
       Support extensions for Path Computation Requests                   MUST      YES
       Include source & destination
       Support path constraints (e.g., bandwidth, hops,
       affinities) to include/exclude                      MUST      YES
       Support path reoptimization & inclusion of a
       previously computed path                            MUST      YES
       Allow to select/prefer from advertised list of
       standard objective functions/options                MUST      ME
       Allow to customize objective function/options       MUST      ME
       Request a less-constrained path                     MAY       ME
       Support request
              Element (PCE) Discovery",
              draft-ietf-pce-disco-proto-igp-00 (work in progress),
              November 2005.

   [I-D.ietf-pce-discovery-reqs]
              Roux, J., "Requirements for less-constrained path,
       including constraint-relaxation policy's            SHOULD    ME
       Support Path Computation Responses                  MUST      YES
       Negative response support reasons Element (PCE)
              Discovery", draft-ietf-pce-discovery-reqs-03 (work in
              progress), February 2006.

   [I-D.ietf-pce-inter-layer-req]
              Oki, E., "PCC-PCE Communication Requirements for failure,
       constraints to relax to achieve positive result,
       less-constrained path reflecting
       constraint-relaxation policy's                      SHOULD    ME
       Cancellation Inter-
              Layer Traffic Engineering",
              draft-ietf-pce-inter-layer-req-01 (work in progress),
              March 2006.

   [I-D.ietf-pce-pcecp-interarea-reqs]
              Roux, J., "PCE Communication Protocol (PCECP) Specific
              Requirements for Inter-Area  (G)MPLS Traffic Engineering",
              draft-ietf-pce-pcecp-interarea-reqs-01 (work in progress),
              February 2006.

   [I-D.ietf-rpsec-bgpsecrec]
              Christian, B. and T. Tauber, "BGP Security Requirements",
              draft-ietf-rpsec-bgpsecrec-03 (work in progress),
              October 2005.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2385]  Heffernan, A., "Protection of Pending Requests                    MUST      YES
       Multiple Requests BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC2406]  Kent, S. and Responses                     MUST      YES
       Limit by configuration number R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3785]  Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and
              T. Telkamp, "Use of requests within Interior Gateway Protocol (IGP) Metric
              as a message                                           MUST      YES
       Support multiple computed paths in response         MUST      YES
       Support "continuation correlation" where related
       requests or computed paths cannot fit within one
       message                                             MUST      YES
       Maximum message size & maximum number second MPLS Traffic Engineering (TE) Metric", BCP 87,
              RFC 3785, May 2004.

   [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
              June 2005.

Appendix A.  Proposed Status and Discussion [To Be Removed Upon
             Publication]

   This Internet-Draft is being submitted for eventual publication as an
   RFC with a proposed status of requests
       per message exchanged through PCE messages to PCC,
       or indicated in request message                     MAY       ME
       Reliable Message Exchange (achieved by Standard.  Discussion of this proposal
   should take place on the following mailing list: pce@ietf.org.

Appendix B.  PCEP
       itself or transport protocol                        MUST      YES
       Allow detection & recovery Variables

   PCEP defines variable that can be configured.  The following PCEP
   variables are defined.

   KeepAlive timer: minimum period of lost messages to
       occur quickly & not impede operation time between the sending of PCEP        MUST      ME
       Handle overload situations without significant
       decrease in performance, e.g., through throttling
       of requests                                         MUST      YES
       Provide acknowledged message delivery with
       retransmission, in order message delivery or
       facility to restore order, message corruption
       detection, flow control & back-pressure
   messages (Keepalive, PCReq, PCRep, PCNtf) to
       throttle requests, rapid partner failure
       detection, informed rapidly a PCEP peer.  A
   suggested value for the Keepalive timer is 30 seconds.

   DeadTimer: period of failure timer after the expiration of PCE-PCC
       connection                                          MUST      YES
       Functionality added to which a PCEP peer
   declared the session down if transport protocol
       provides it                                         SHOULD NOT N/A
       Secure Message Exchange (provided by no PCEP or
       transport protocol                                  MUST      YES
       Support mechanisms to prevent spoofing (e.g.,
       authentication), snooping (e.g., encryption),
       DOS attacks                                         MUST      YES
       Request Prioritization                              MUST      YES
       Unsolicited Notifications                           SHOULD    YES
       Allow Asynchronous Communication                    MUST      YES
       PCC Has to Wait for Response Before Making
       Another Request                                     MUST NOT  YES
       Allow order of responses differ from order of
       Requests                                            MUST      YES
       Communication Overhead Minimization                 SHOULD    YES
       Give particular attention to message size           SHOULD
       Extensibility without requiring modifications to has been received.

   SyncTimer: the SYNC timer is used in the protocol                                        MUST      YES
       Easily extensible to support intra-area,
       inter-area, inter-AS intra provider, inter-AS
       inter-provider, multi-layer path & virtual network
       topology case of synchronized path
   computation                           MUST      YES
       Easily extensible to support future applications
       not in scope (e.g., P2MP path computations)         SHOULD    YES
       Scalability at least linearly with increase request using the SVEC object defined in
       number of PCCs, PCEs, PCCs communicating with Section 7.12.3.
   Consider the case where a
       single PCE, PCEs communicated to PCReq message is received by a single PCC,
       PCEs communicated PCE that
   comprises the SVEC object referring to by another PCE, domains, M synchronized path
       requests, handling bursts
   computation requests.  If after the expiration of the SYNC timer all
   the M path computation requests               MUST      YES
       Support Path Computation Constraints                MUST      ME
       Support Different Service Provider Environments
       (e.g., MPLS-TE have not been received, a protocol
   error is triggered and GMPLS networks, centralized &
       distributed PCE path computation, single &
       multiple the PCE path computation) MUST      YES
       Policy Support cancel the whole set of path
   computation requests.  A RECOMMENDED value for policies the SYNC timer is 60
   seconds.

Authors' Addresses

   JP Vasseur (editor)
   Cisco Systems, Inc
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Email: jpv@cisco.com

   JL Le Roux
   France Telecom
   2, Avenue Pierre-Marzin
   Lannion,   22307
   FRANCE

   Email: jeanlouis.leroux@francetelecom.com

   Arthi Ayyangar
   Juniper Networks
   1194 N.Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Email: arthi@juniper.net

   Eiji Oki
   NTT
   Midori 3-9-11
   Musashino, Tokyo,   180-8585
   JAPAN

   Email: oki.eiji@lab.ntt.co.jp

   Alia Atlas
   Google
   1600 Amphitheatre Parkway
   Montain View, CA  94043
   USA

   Email: akatlas@alum.mit.edu
   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

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to accept/reject
       requests, PCC identify any such rights.  Information
   on the procedures with respect to determine reason for rejection,
       notification rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of policy violation                    MUST      ME
       Aliveness Detection IPR disclosures made to the IETF Secretariat and any
   assurances of PCCs/PCEs, partner failure
       Detection                                           MUST      YES
       PCC/PCE Failure Response procedures defined for
       PCE/PCC failures, PCC able licenses to clear pending
       Request                                             MUST      YES
       PCC select another PCE upon detection be made available, or the result of PCE
       failure                                             MUST      YES
       PCE able an
   attempt made to clear pending requests from obtain a PCC
       (e.g. when it detects PCC failure general license or request
       buffer full)                                        MUST      YES
       Protocol Recovery support resynchronization permission for the use of
       information & requests between sender & receiver    MUST      ME
       Minimize repeat data transfer, allow PCE to
       respond
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to computation requests issued before
       failure without requests being re-issued            SHOULD    ME
       Stateful PCE able bring to resynchronize/recover
       states (e.g., LSP status, paths) after restart      SHOULD    SE

     Full Copyright Statement

       Copyright (C) The Internet Society (2005).

       This document is subject its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the rights, licenses and  restrictions
       contained in BCP 78, and except as set forth therein, information to the authors
       retain all their rights." IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

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

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.