tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5440

 
 
 

Path Computation Element (PCE) Communication Protocol (PCEP)

Part 2 of 4, p. 15 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
5.  Transport Protocol

   PCEP operates over TCP using a registered TCP port (4189).  This
   allows the requirements of reliable messaging and flow control to be
   met without further protocol work.  All PCEP messages MUST be sent
   using the registered TCP port for the source and destination TCP
   port.

6.  PCEP Messages

   A PCEP message consists of a common header followed by a variable-
   length body made of a set of objects that can either be mandatory or
   optional.  In the context of this document, an object is said to be
   mandatory in a PCEP message when the object MUST be included for the
   message to be considered valid.  A PCEP message with a missing
   mandatory object MUST trigger an Error message (see Section 7.15).
   Conversely, if an object is optional, the object may or may not be
   present.

   A flag referred to as the P flag is defined in the common header of
   each PCEP object (see Section 7.2).  When this flag is set in an
   object in a PCReq, the PCE MUST take the information carried in the
   object into account during the path computation.  For example, the
   METRIC object defined in Section 7.8 allows a PCC to specify a
   bounded acceptable path cost.  The METRIC object is optional, but a
   PCC may set a flag to ensure that the constraint is taken into
   account.  In this case, if the constraint cannot be taken into
   account by the PCE, the PCE MUST trigger an Error message.

   For each PCEP message type, rules are defined that specify the set of
   objects that the message can carry.  We use the Backus-Naur Form
   (BNF) (see [RBNF]) to specify such rules.  Square brackets refer to
   optional sub-sequences.  An implementation MUST form the PCEP
   messages using the object ordering specified in this document.

Top      Up      ToC       Page 16 
6.1.  Common Header

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ver |  Flags  |  Message-Type |       Message-Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: PCEP Message Common Header

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

   Flags (5 bits):  No flags are currently defined.  Unassigned bits are
      considered as reserved.  They MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Message-Type (8 bits):  The following message types are currently
      defined:

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

   Message-Length (16 bits):  total length of the PCEP message including
      the common header, expressed in bytes.

6.2.  Open Message

   The Open message is a PCEP message sent by a PCC to a PCE and by a
   PCE to a PCC in order to establish a PCEP session.  The Message-Type
   field of the PCEP common header for the Open message is set to 1.

   Once the TCP connection has been successfully established, the first
   message sent by the PCC to the PCE or by the PCE to the PCC MUST be
   an Open message as specified in Appendix A.

   Any message received prior to an Open message MUST trigger a protocol
   error condition causing a PCErr message to be sent with Error-Type
   "PCEP session establishment failure" and Error-value "reception of an
   invalid Open message or a non Open message" and the PCEP session
   establishment attempt MUST be terminated by closing the TCP
   connection.

Top      Up      ToC       Page 17 
   The Open message is used to establish a PCEP session between the PCEP
   peers.  During the establishment phase, the PCEP peers exchange
   several session characteristics.  If both parties agree on such
   characteristics, the PCEP session is successfully established.

   The format of an Open message is as follows:

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

   The Open message MUST contain exactly one OPEN object (see
   Section 7.3).

   Various session characteristics are specified within the OPEN object.
   Once the TCP connection has been successfully established, the sender
   MUST start an initialization timer called OpenWait after the
   expiration of which, if no Open message has been received, it sends a
   PCErr message and releases the TCP connection (see Appendix A for
   details).

   Once an Open message has been sent to a PCEP peer, the sender MUST
   start an initialization timer called KeepWait after the expiration of
   which, if neither a Keepalive message has been received nor a PCErr
   message in case of disagreement of the session characteristics, a
   PCErr message MUST be sent and the TCP connection MUST be released
   (see Appendix A for details).

   The OpenWait and KeepWait timers have a fixed value of 1 minute.

   Upon the receipt of an Open message, the receiving PCEP peer MUST
   determine whether the suggested PCEP session characteristics are
   acceptable.  If at least one of the characteristics is not acceptable
   to the receiving peer, it MUST send an Error message.  The Error
   message SHOULD also contain the related OPEN object and, for each
   unacceptable session parameter, an acceptable parameter value SHOULD
   be proposed in the appropriate field of the OPEN object in place of
   the originally proposed value.  The PCEP peer MAY decide to resend an
   Open message with different session characteristics.  If a second
   Open message is received with the same set of parameters or with
   parameters that are still unacceptable, the receiving peer MUST send
   an Error message and it MUST immediately close the TCP connection.
   Details about error messages can be found in Section 7.15.
   Successive retries are permitted, but an implementation SHOULD make
   use of an exponential back-off session establishment retry procedure.

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

Top      Up      ToC       Page 18 
   The PCEP session is considered as established once both PCEP peers
   have received a Keepalive message from their peer.

6.3.  Keepalive Message

   A Keepalive message is a PCEP message sent by a PCC or a PCE in order
   to keep the session in active state.  The Keepalive message is also
   used in response to an Open message to acknowledge that an Open
   message has been received and that the PCEP session characteristics
   are acceptable.  The Message-Type field of the PCEP common header for
   the Keepalive message is set to 2.  The Keepalive message does not
   contain any object.

   PCEP has its own keepalive mechanism used to ensure the liveness of
   the PCEP session.  This requires the determination of the frequency
   at which each PCEP peer sends Keepalive messages.  Asymmetric values
   may be chosen; thus, there is no constraint mandating the use of
   identical keepalive frequencies by both PCEP peers.  The DeadTimer is
   defined as the period of time after the expiration of which a PCEP
   peer declares the session down if no PCEP message has been received
   (Keepalive or any other PCEP message); thus, any PCEP message acts as
   a Keepalive message.  Similarly, there are no constraints mandating
   the use of identical DeadTimers by both PCEP peers.  The minimum
   Keepalive timer value is 1 second.  Deployments SHOULD consider
   carefully the impact of using low values for the Keepalive timer as
   these might not give rise to the expected results in periods of
   temporary network instability.

   Keepalive messages are sent at the frequency specified in the OPEN
   object carried within an Open message according to the rules
   specified in Section 7.3.  Because any PCEP message may serve as
   Keepalive, an implementation may either decide to send Keepalive
   messages at fixed intervals regardless of whether other PCEP messages
   might have been sent since the last sent Keepalive message, or may
   decide to differ the sending of the next Keepalive message based on
   the time at which the last PCEP message (other than Keepalive) was
   sent.

   Note that sending Keepalive messages to keep the session alive is
   optional, and PCEP peers may decide not to send Keepalive messages
   once the PCEP session is established; in which case, the peer that
   does not receive Keepalive messages does not expect to receive them
   and MUST NOT declare the session as inactive.

   The format of a Keepalive message is as follows:

   <Keepalive Message>::= <Common Header>

Top      Up      ToC       Page 19 
6.4.  Path Computation Request (PCReq) Message

   A Path Computation Request message (also referred to as a PCReq
   message) is a PCEP message sent by a PCC to a PCE to request a path
   computation.  A PCReq message may carry more than one path
   computation request.  The Message-Type field of the PCEP common
   header for the PCReq message is set to 3.

   There are two mandatory objects that MUST be included within a PCReq
   message: the RP and the END-POINTS objects (see Section 7).  If one
   or both of these objects is missing, the receiving PCE MUST send an
   error message to the requesting PCC.  Other objects are optional.

   The format of a PCReq message is as follows:

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   where:

      <svec-list>::=<SVEC>[<svec-list>]
      <request-list>::=<request>[<request-list>]

      <request>::= <RP>
                   <END-POINTS>
                   [<LSPA>]
                   [<BANDWIDTH>]
                   [<metric-list>]
                   [<RRO>[<BANDWIDTH>]]
                   [<IRO>]
                   [<LOAD-BALANCING>]

   where:

   <metric-list>::=<METRIC>[<metric-list>]

   The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and
   LOAD-BALANCING objects are defined in Section 7.  The special case of
   two BANDWIDTH objects is discussed in detail in Section 7.7.

   A PCEP implementation is free to process received requests in any
   order.  For example, the requests may be processed in the order they
   are received, reordered and assigned priority according to local
   policy, reordered according to the priority encoded in the RP object
   (Section 7.4.1), or processed in parallel.

Top      Up      ToC       Page 20 
6.5.  Path Computation Reply (PCRep) Message

   The PCEP Path Computation Reply message (also referred to as a PCRep
   message) is a PCEP message sent by a PCE to a requesting PCC in
   response to a previously received PCReq message.  The Message-Type
   field of the PCEP common header for the PCRep message is set to 4.

   The bundling of multiple replies to a set of path computation
   requests within a single PCRep message is supported by PCEP.  If a
   PCE receives non-synchronized path computation requests by means of
   one or more PCReq messages from a requesting PCC, it MAY decide to
   bundle the computed paths within a single PCRep message so as to
   reduce the control plane load.  Note that the counter side of such an
   approach is the introduction of additional delays for some path
   computation requests of the set.  Conversely, a PCE that receives
   multiple requests within the same PCReq message MAY decide to provide
   each computed path in separate PCRep messages or within the same
   PCRep message.  A PCRep message may contain positive and negative
   replies.

   A PCRep message may contain a set of computed paths corresponding to
   either a single path computation request with load-balancing (see
   Section 7.16) or multiple path computation requests originated by a
   requesting PCC.  The PCRep message may also contain multiple
   acceptable paths corresponding to the same request.

   The PCRep message MUST contain at least one RP object.  For each
   reply that is bundled into a single PCReq message, an RP object MUST
   be included that contains a Request-ID-number identical to the one
   specified in the RP object carried in the corresponding PCReq message
   (see Section 7.4 for the definition of the RP object).

   If the path computation request can be satisfied (i.e., the PCE finds
   a set of paths that satisfy the set of constraints), the set of
   computed paths specified by means of Explicit Route Objects (EROs) is
   inserted in the PCRep message.  The ERO is defined in Section 7.9.
   The situation where multiple computed paths are provided in a PCRep
   message is discussed in detail in Section 7.13.  Furthermore, when a
   PCC requests the computation of a set of paths for a total amount of
   bandwidth by means of a LOAD-BALANCING object carried within a PCReq
   message, the ERO of each computed path may be followed by a BANDWIDTH
   object as discussed in section Section 7.16.

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

Top      Up      ToC       Page 21 
   The format of a PCRep message is as follows:


   <PCRep Message> ::= <Common Header>
                       <response-list>

   where:

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

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

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

      <path>::= <ERO><attribute-list>

   where:

    <attribute-list>::=[<LSPA>]
                       [<BANDWIDTH>]
                       [<metric-list>]
                       [<IRO>]

    <metric-list>::=<METRIC>[<metric-list>]

6.6.  Notification (PCNtf) Message

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

   The PCNtf message MUST carry at least one NOTIFICATION object and MAY
   contain several NOTIFICATION objects should the PCE or the PCC intend
   to notify of multiple events.  The NOTIFICATION object is defined in
   Section 7.14.  The PCNtf message MAY also contain RP objects (see
   Section 7.4) when the notification refers to particular path
   computation requests.

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

Top      Up      ToC       Page 22 
   The format of a PCNtf message is as follows:

   <PCNtf Message>::=<Common Header>
                     <notify-list>

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

   <notify>::= [<request-id-list>]
                <notification-list>

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

   <notification-list>::=<NOTIFICATION>[<notification-list>]

6.7.  Error (PCErr) Message

   The PCEP Error message (also referred to as a PCErr message) is sent
   in several situations: when a protocol error condition is met or when
   the request is not compliant with the PCEP specification (e.g.,
   reception of a malformed message, reception of a message with a
   mandatory missing object, policy violation, unexpected message,
   unknown request reference).  The Message-Type field of the PCEP
   common header for the PCErr message is set to 6.

   The PCErr message is sent by a PCC or a PCE in response to a request
   or in an unsolicited manner.  If the PCErr message is sent in
   response to a request, the PCErr message MUST include the set of RP
   objects related to the pending path computation requests that
   triggered the error condition.  In the latter case (unsolicited), no
   RP object is inserted in the PCErr message.  For example, no RP
   object is inserted in a PCErr when the error condition occurred
   during the initialization phase.  A PCErr message MUST contain a
   PCEP-ERROR object specifying the PCEP error condition.  The PCEP-
   ERROR object is defined in Section 7.15.

   The format of a PCErr message is as follows:

   <PCErr Message> ::= <Common Header>
                       ( <error-obj-list> [<Open>] ) | <error>
                       [<error-list>]

   <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]

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

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

Top      Up      ToC       Page 23 
   <error-list>::=<error>[<error-list>]

   The procedure upon the receipt of a PCErr message is defined in
   Section 7.15.

6.8.  Close Message

   The Close message is a PCEP message that is either sent by a PCC to a
   PCE or by a PCE to a PCC in order to close an established PCEP
   session.  The Message-Type field of the PCEP common header for the
   Close message is set to 7.

   The format of a Close message is as follows:

   <Close Message>::= <Common Header>
                      <CLOSE>

   The Close message MUST contain exactly one CLOSE object (see
   Section 6.8).  If more than one CLOSE object is present, the first
   MUST be processed and subsequent objects ignored.

   Upon the receipt of a valid Close message, the receiving PCEP peer
   MUST cancel all pending requests, it MUST close the TCP connection
   and MUST NOT send any further PCEP messages on the PCEP session.

6.9.  Reception of Unknown Messages

   A PCEP implementation that receives an unrecognized PCEP message MUST
   send a PCErr message with Error-value=2 (capability not supported).

   If a PCC/PCE receives unrecognized messages at a rate equal or
   greater than MAX-UNKNOWN-MESSAGES unknown message requests per
   minute, the PCC/PCE MUST send a PCEP CLOSE message with close
   value="Reception of an unacceptable number of unknown PCEP message".
   A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5.  The PCC/PCE MUST
   close the TCP session and MUST NOT send any further PCEP messages on
   the PCEP session.

7.  Object Formats

   PCEP objects have a common format.  They begin with a common object
   header (see Section 7.2).  This is followed by object-specific fields
   defined for each different object.  The object may also include one
   or more type-length-value (TLV) encoded data sets.  Each TLV has the
   same structure as described in Section 7.1.

Top      Up      ToC       Page 24 
7.1.  PCEP TLV Format

   A PCEP object may include a set of one or more optional TLVs.

   All PCEP TLVs have the following format:

   Type:   2 bytes
   Length: 2 bytes
   Value:  variable

   A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes
   specifying the TLV length, and a value field.

   The Length field defines the length of the value portion in bytes.
   The TLV is padded to 4-bytes alignment; padding is not included in
   the Length field (so a 3-byte value would have a length of 3, but the
   total size of the TLV would be 8 bytes).

   Unrecognized TLVs MUST be ignored.

   IANA management of the PCEP Object TLV type identifier codespace is
   described in Section 9.

7.2.  Common Object Header

   A PCEP object carried within a PCEP message consists of one or more
   32-bit words with a common header that has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Object body)                        //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: PCEP Common Object Header

   Object-Class (8 bits):  identifies the PCEP object class.

   OT (Object-Type - 4 bits):  identifies the PCEP object type.

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

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

Top      Up      ToC       Page 25 
   Res flags (2 bits):  Reserved field.  This field MUST be set to zero
      on transmission and MUST be ignored on receipt.

   P flag (Processing-Rule - 1-bit):  the P flag allows a PCC to specify
      in a PCReq message sent to a PCE whether the object must be taken
      into account by the PCE during path computation or is just
      optional.  When the P flag is set, the object MUST be taken into
      account by the PCE.  Conversely, when the P flag is cleared, the
      object is optional and the PCE is free to ignore it.

   I flag (Ignore - 1 bit):  the I flag is used by a PCE in a PCRep
      message to indicate to a PCC whether or not an optional object was
      processed.  The PCE MAY include the ignored optional object in its
      reply and set the I flag to indicate that the optional object was
      ignored during path computation.  When the I flag is cleared, the
      PCE indicates that the optional object was processed during the
      path computation.  The setting of the I flag for optional objects
      is purely indicative and optional.  The I flag has no meaning in a
      PCRep message when the P flag has been set in the corresponding
      PCReq message.

   If the PCE does not understand an object with the P flag set or
   understands the object but decides to ignore the object, the entire
   PCEP message MUST be rejected and the PCE MUST send a PCErr message
   with Error-Type="Unknown Object" or "Not supported Object" along with
   the corresponding RP object.  Note that if a PCReq includes multiple
   requests, only requests for which an object with the P flag set is
   unknown/unrecognized MUST be rejected.

   Object Length (16 bits):  Specifies the total object length including
      the header, in bytes.  The Object Length field MUST always be a
      multiple of 4, and at least 4.  The maximum object content length
      is 65528 bytes.

7.3.  OPEN Object

   The OPEN object MUST be present in each Open message and MAY be
   present in a PCErr message.  There MUST be only one OPEN object per
   Open or PCErr message.

   The OPEN object contains a set of fields used to specify the PCEP
   version, Keepalive frequency, DeadTimer, and PCEP session ID, along
   with various flags.  The OPEN object may also contain a set of TLVs
   used to convey various session characteristics such as the detailed
   PCE capabilities, policy rules, and so on.  No TLVs are currently
   defined.

Top      Up      ToC       Page 26 
   OPEN Object-Class is 1.

   OPEN Object-Type is 1.

   The format of the OPEN object body is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ver |   Flags |   Keepalive   |  DeadTimer    |      SID      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                       Optional TLVs                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9: OPEN Object Format

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

   Flags (5 bits):  No flags are currently defined.  Unassigned bits are
      considered as reserved.  They MUST be set to zero on transmission
      and MUST be ignored on receipt.

   Keepalive (8 bits):  maximum period of time (in seconds) between two
      consecutive PCEP messages sent by the sender of this message.  The
      minimum value for the Keepalive is 1 second.  When set to 0, once
      the session is established, no further Keepalive messages are sent
      to the remote peer.  A RECOMMENDED value for the keepalive
      frequency is 30 seconds.

   DeadTimer (8 bits):  specifies the amount of time after the
      expiration of which the PCEP peer can declare the session with the
      sender of the Open message to be down if no PCEP message has been
      received.  The DeadTimer SHOULD be set to 0 and MUST be ignored if
      the Keepalive is set to 0.  A RECOMMENDED value for the DeadTimer
      is 4 times the value of the Keepalive.

   Example:

   A sends an Open message to B with Keepalive=10 seconds and
   DeadTimer=40 seconds.  This means that A sends Keepalive messages (or
   any other PCEP message) to B every 10 seconds and B can declare the
   PCEP session with A down if no PCEP message has been received from A
   within any 40-second period.

Top      Up      ToC       Page 27 
   SID (PCEP session ID - 8 bits):  unsigned PCEP session number that
      identifies the current session.  The SID MUST be incremented each
      time a new PCEP session is established.  It is used for logging
      and troubleshooting purposes.  Each increment SHOULD have a value
      of 1 and may cause a wrap back to zero.

      The SID is used to disambiguate instances of sessions to the same
      peer.  A PCEP implementation could use a single source of SIDs
      across all peers, or one source for each peer.  The former might
      constrain the implementation to only 256 concurrent sessions.  The
      latter potentially requires more states.  There is one SID number
      in each direction.

   Optional TLVs may be included within the OPEN object body to specify
   PCC or PCE characteristics.  The specification of such TLVs is
   outside the scope of this document.

   When present in an Open message, the OPEN object specifies the
   proposed PCEP session characteristics.  Upon receiving unacceptable
   PCEP session characteristics during the PCEP session initialization
   phase, the receiving PCEP peer (PCE) MAY include an OPEN object
   within the PCErr message so as to propose alternative acceptable
   session characteristic values.

7.4.  RP Object

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

   The P flag of the RP object MUST be set in PCReq and PCRep messages
   and MUST be cleared in PCNtf and PCErr messages.  If the RP object is
   received with the P flag set incorrectly according to the rules
   stated above, the receiving peer MUST send a PCErr message with
   Error-Type=10 and Error-value=1.  The corresponding path computation
   request MUST be cancelled by the PCE without further notification.

7.4.1.  Object Definition

   RP Object-Class is 2.

   RP Object-Type is 1.

Top      Up      ToC       Page 28 
   The format of the RP object body is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Flags                    |O|B|R| Pri |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Request-ID-number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10: RP Object Body Format

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

   Flags (32 bits)

   The following flags are currently defined:

   o  Pri (Priority - 3 bits): the Priority field may be used by the
      requesting PCC to specify to the PCE the request's priority from 1
      to 7.  The decision of which priority should be used for a
      specific request is a local matter; it MUST be set to 0 when
      unused.  Furthermore, the use of the path computation request
      priority by the PCE's scheduler is implementation specific and out
      of the scope of this document.  Note that it is not required for a
      PCE to support the priority field: in this case, it is RECOMMENDED
      that the PCC set the priority field to 0 in the RP object.  If the
      PCE does not take into account the request priority, it is
      RECOMMENDED to set the priority field to 0 in the RP object
      carried within the corresponding PCRep message, regardless of the
      priority value contained in the RP object carried within the
      corresponding PCReq message.  A higher numerical value of the
      priority field reflects a higher priority.  Note that it is the
      responsibility of the network administrator to make use of the
      priority values in a consistent manner across the various PCCs.
      The ability of a PCE to support request prioritization MAY be
      dynamically discovered by the PCCs by means of PCE capability
      discovery.  If not advertised by the PCE, a PCC may decide to set
      the request priority and will learn the ability of the PCE to
      support request prioritization by observing the Priority field of
      the RP object received in the PCRep message.  If the value of the
      Pri field is set to 0, this means that the PCE does not support

Top      Up      ToC       Page 29 
      the handling of request priorities: in other words, the path
      computation request has been honored but without taking the
      request priority into account.

   o  R (Reoptimization - 1 bit): when set, the requesting PCC specifies
      that the PCReq message relates to the reoptimization of an
      existing TE LSP.  For all TE LSPs except zero-bandwidth LSPs, when
      the R bit is set, an RRO (see Section 7.10) MUST be included in
      the PCReq message to show the path of the existing TE LSP.  Also,
      for all TE LSPs except zero-bandwidth LSPs, when the R bit is set,
      the existing bandwidth of the TE LSP to be reoptimized MUST be
      supplied in a BANDWIDTH object (see Section 7.7).  This BANDWIDTH
      object is in addition to the instance of that object used to
      describe the desired bandwidth of the reoptimized LSP.  For zero-
      bandwidth LSPs, the RRO and BANDWIDTH objects that report the
      characteristics of the existing TE LSP are optional.

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

   o  O (strict/loose - 1 bit): when set, in a PCReq message, this
      indicates that a loose path is acceptable.  Otherwise, when
      cleared, this indicates to the PCE that a path exclusively made of
      strict hops is required.  In a PCRep message, when the O bit is
      set this indicates that the returned path is a loose path;
      otherwise (when the O bit is cleared), the returned path is made
      of strict hops.

   Unassigned bits are considered reserved.  They MUST be set to zero on
   transmission and MUST be ignored on receipt.

   Request-ID-number (32 bits):  The Request-ID-number value combined
      with the source IP address of the PCC and the PCE address uniquely
      identify the path computation request context.  The Request-ID-
      number is used for disambiguation between pending requests, and
      thus it MUST be changed (such as by incrementing it) each time a
      new request is sent to the PCE, and may wrap.

      The value 0x00000000 is considered invalid.

      If no path computation reply is received from the PCE (e.g., the
      request is dropped by the PCE because of memory overflow), and the
      PCC wishes to resend its request, the same Request-ID-number MUST
      be used.  Upon receiving a path computation request from a PCC

Top      Up      ToC       Page 30 
      with the same Request-ID-number, the PCE SHOULD treat the request
      as a new request.  An implementation MAY choose to cache path
      computation replies in order to quickly handle retransmission
      without having to process a path computation request twice (in the
      case that the first request was dropped or lost).  Upon receiving
      a path computation reply from a PCE with the same Request-ID-
      number, the PCC SHOULD silently discard the path computation
      reply.

      Conversely, different Request-ID-numbers MUST be used for
      different requests sent to a PCE.

      The same Request-ID-number MAY be used for path computation
      requests sent to different PCEs.  The path computation reply is
      unambiguously identified by the IP source address of the replying
      PCE.

7.4.2.  Handling of the RP Object

   If a PCReq message is received that does not contain an RP object,
   the PCE MUST send a PCErr message to the requesting PCC with Error-
   Type="Required Object missing" and Error-value="RP Object missing".

   If the O bit of the RP message carried within a PCReq message is
   cleared and local policy has been configured on the PCE to not
   provide explicit paths (for instance, for confidentiality reasons), a
   PCErr message MUST be sent by the PCE to the requesting PCC and the
   pending path computation request MUST be discarded.  The Error-Type
   is "Policy Violation" and Error-value is "O bit cleared".

   When the R bit of the RP object is set in a PCReq message, this
   indicates that the path computation request relates to the
   reoptimization of an existing TE LSP.  In this case, the PCC MUST
   also provide the strict/loose path by including an RRO object in the
   PCReq message so as to avoid/limit double-bandwidth counting if and
   only if the TE LSP is a non-zero-bandwidth TE LSP.  If the PCC has
   not requested a strict path (O bit set), a reoptimization can still
   be requested by the PCC, but this requires that the PCE either be
   stateful (keep track of the previously computed path with the
   associated list of strict hops), or have the ability to retrieve the
   complete required path segment.  Alternatively, the PCC MUST inform
   the PCE about the working path and the associated list of strict hops
   in PCReq.  The absence of an RRO in the PCReq message for a non-zero-
   bandwidth TE LSP (when the R bit of the RP object is set) MUST
   trigger the sending of a PCErr message with Error-Type="Required
   Object Missing" and Error-value="RRO Object missing for
   reoptimization".

Top      Up      ToC       Page 31 
   If a PCC/PCE receives a PCRep/PCReq message that contains an RP
   object referring to an unknown Request-ID-number, the PCC/PCE MUST
   send a PCErr message with Error-Type="Unknown request reference".
   This is used for debugging purposes.  If a PCC/PCE receives PCRep/
   PCReq messages with unknown requests at a rate equal or greater than
   MAX-UNKNOWN-REQUESTS unknown requests per minute, the PCC/PCE MUST
   send a PCEP CLOSE message with close value="Reception of an
   unacceptable number of unknown requests/replies".  A RECOMMENDED
   value for MAX-UNKNOWN-REQUESTS is 5.  The PCC/PCE MUST close the TCP
   session and MUST NOT send any further PCEP messages on the PCEP
   session.

   The reception of a PCEP message that contains an RP object referring
   to a Request-ID-number=0x00000000 MUST be treated in similar manner
   as an unknown request.

7.5.  NO-PATH Object

   The NO-PATH object is used in PCRep messages in response to an
   unsuccessful path computation request (the PCE could not find a path
   satisfying the set of constraints).  When a PCE cannot find a path
   satisfying a set of constraints, it MUST include a NO-PATH object in
   the PCRep message.

   There are several categories of issue that can lead to a negative
   reply.  For example, the PCE chain might be broken (should there be
   more than one PCE involved in the path computation) or no path
   obeying the set constraints could be found.  The "NI (Nature of
   Issue)" field in the NO-PATH object is used to report the error
   category.

   Optionally, if the PCE supports such capability, the NO-PATH object
   MAY contain an optional NO-PATH-VECTOR TLV defined below and used to
   provide more information on the reasons that led to a negative reply.
   The PCRep message MAY also contain a list of objects that specify the
   set of constraints that could not be satisfied.  The PCE MAY just
   replicate the set of objects that was received that was the cause of
   the unsuccessful computation or MAY optionally report a suggested
   value for which a path could have been found (in which case, the
   value differs from the value in the original request).

   NO-PATH Object-Class is 3.

   NO-PATH Object-Type is 1.

Top      Up      ToC       Page 32 
   The format of the NO-PATH object body is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Nature of Issue|C|          Flags              |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 11: NO-PATH Object Format

   NI - Nature of Issue (8 bits):  The NI field is used to report the
      nature of the issue that led to a negative reply.  Two values are
      currently defined:

         0: No path satisfying the set of constraints could be found

         1: PCE chain broken

      The Nature of Issue field value can be used by the PCC for various
      purposes:

      *  Constraint adjustment before reissuing a new path computation
         request,

      *  Explicit selection of a new PCE chain,

      *  Logging of the error type for further action by the network
         administrator.

      IANA management of the NI field codespace is described in
      Section 9.

   Flags (16 bits).

   The following flag is currently defined:

   o  C flag (1 bit): when set, the PCE indicates the set of unsatisfied
      constraints (reasons why a path could not be found) in the PCRep
      message by including the relevant PCEP objects.  When cleared, no
      failing constraints are specified.  The C flag has no meaning and
      is ignored unless the NI field is set to 0x00.

   Unassigned bits are considered as reserved.  They MUST be set to zero
   on transmission and MUST be ignored on receipt.

Top      Up      ToC       Page 33 
   Reserved (8 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   The NO-PATH object body has a variable length and may contain
   additional TLVs.  The only TLV currently defined is the NO-PATH-
   VECTOR TLV defined below.

   Example: consider the case of a PCC that sends a path computation
   request to a PCE for a TE LSP of X Mbit/s.  Suppose that PCE cannot
   find a path for X Mbit/s.  In this case, the PCE must include in the
   PCRep message a NO-PATH object.  Optionally, the PCE may also include
   the original BANDWIDTH object so as to indicate that the reason for
   the unsuccessful computation is the bandwidth constraint (in this
   case, the NI field value is 0x00 and C flag is set).  If the PCE
   supports such capability, it may alternatively include the BANDWIDTH
   object and report a value of Y in the bandwidth field of the
   BANDWIDTH object (in this case, the C flag is set) where Y refers to
   the bandwidth for which a TE LSP with the same other characteristics
   (such as Setup/Holding priorities, TE LSP attribute, local
   protection, etc.) could have been computed.

   When the NO-PATH object is absent from a PCRep message, the path
   computation request has been fully satisfied and the corresponding
   paths are provided in the PCRep message.

   An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH
   object in order to provide more information on the reasons that led
   to a negative reply.

   The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined
   in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes
   specifying the TLV length (length of the value portion in bytes)
   followed by a fixed-length 32-bit flags field.

   Type:   1
   Length: 4 bytes
   Value:  32-bit flags field

   IANA manages the space of flags carried in the NO-PATH-VECTOR TLV
   (see Section 9).

   The following flags are currently defined:

   o  Bit number: 31 - PCE currently unavailable

   o  Bit number: 30 - Unknown destination

   o  Bit number: 29 - Unknown source

Top      Up      ToC       Page 34 
7.6.  END-POINTS Object

   The END-POINTS object is used in a PCReq message to specify the
   source IP address and the destination IP address of the path for
   which a path computation is requested.  The P flag of the END-POINTS
   object MUST be set.  If the END-POINTS object is received with the P
   flag cleared, the receiving peer MUST send a PCErr message with
   Error-Type=10 and Error-value=1.  The corresponding path computation
   request MUST be cancelled by the PCE without further notification.

   Note that the source and destination addresses specified in the END-
   POINTS object may correspond to the source and destination IP address
   of the TE LSP or to those of a path segment.  Two END-POINTS objects
   (for IPv4 and IPv6) are defined.

   END-POINTS Object-Class is 4.

   END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6.

   The format of the END-POINTS object body for IPv4 (Object-Type=1) is
   as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source IPv4 address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 12: END-POINTS Object Body Format for IPv4

Top      Up      ToC       Page 35 
   The format of the END-POINTS object for IPv6 (Object-Type=2) is as
   follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                Source IPv6 address (16 bytes)                 |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |              Destination IPv6 address (16 bytes)              |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 13: END-POINTS Object Body Format for IPv6

   The END-POINTS object body has a fixed length of 8 bytes for IPv4 and
   32 bytes for IPv6.

   If more than one END-POINTS object is present, the first MUST be
   processed and subsequent objects ignored.

7.7.  BANDWIDTH Object

   The BANDWIDTH object is used to specify the requested bandwidth for a
   TE LSP.  The notion of bandwidth is similar to the one used for RSVP
   signaling in [RFC2205], [RFC3209], and [RFC3473].

   If the requested bandwidth is equal to 0, the BANDWIDTH object is
   optional.  Conversely, if the requested bandwidth is not equal to 0,
   the PCReq message MUST contain a BANDWIDTH object.

   In the case of the reoptimization of a TE LSP, the bandwidth of the
   existing TE LSP MUST also be included in addition to the requested
   bandwidth if and only if the two values differ.  Consequently, two
   Object-Type values are defined that refer to the requested bandwidth
   and the bandwidth of the TE LSP for which a reoptimization is being
   performed.

   The BANDWIDTH object may be carried within PCReq and PCRep messages.

   BANDWIDTH Object-Class is 5.

Top      Up      ToC       Page 36 
   Two Object-Type values are defined for the BANDWIDTH object:

   o  Requested bandwidth: BANDWIDTH Object-Type is 1.

   o  Bandwidth of an existing TE LSP for which a reoptimization is
      requested.  BANDWIDTH Object-Type is 2.

   The format of the BANDWIDTH object body is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Bandwidth                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 14: BANDWIDTH Object Body Format

   Bandwidth (32 bits):  The requested bandwidth is encoded in 32 bits
      in IEEE floating point format (see [IEEE.754.1985]), expressed in
      bytes per second.  Refer to Section 3.1.2 of [RFC3471] for a table
      of commonly used values.

   The BANDWIDTH object body has a fixed length of 4 bytes.

7.8.  METRIC Object

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

   In a PCReq message, a PCC MAY insert one or more METRIC objects:

   o  To indicate the metric that MUST be optimized by the path
      computation algorithm (IGP metric, TE metric, hop counts).
      Currently, three metrics are defined: the IGP cost, the TE metric
      (see [RFC3785]), and the number of hops traversed by a TE LSP.

   o  To indicate a bound on the path cost that MUST NOT be exceeded for
      the path to be considered as acceptable by the PCC.

   In a PCRep message, the METRIC object MAY be inserted so as to
   provide the cost for the computed path.  It MAY also be inserted
   within a PCRep with the NO-PATH object to indicate that the metric
   constraint could not be satisfied.

   The path computation algorithmic aspects used by the PCE to optimize
   a path with respect to a specific metric are outside the scope of
   this document.

Top      Up      ToC       Page 37 
   It must be understood that such path metrics are only meaningful if
   used consistently: for instance, if the delay of a computed path
   segment is exchanged between two PCEs residing in different domains,
   consistent ways of defining the delay must be used.

   The absence of the METRIC object MUST be interpreted by the PCE as a
   path computation request for which no constraints need be applied to
   any of the metrics.

   METRIC Object-Class is 6.

   METRIC Object-Type is 1.

   The format of the METRIC object body is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |    Flags  |C|B|       T       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          metric-value                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 15: METRIC Object Body Format

   The METRIC object body has a fixed length of 8 bytes.

   Reserved (16 bits):  This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

   T (Type - 8 bits):  Specifies the metric type.

      Three values are currently defined:
      *  T=1: IGP metric
      *  T=2: TE metric
      *  T=3: Hop Counts

   Flags (8 bits):  Two flags are currently defined:

      *  B (Bound - 1 bit): When set in a PCReq message, the metric-
         value indicates a bound (a maximum) for the path metric that
         must not be exceeded for the PCC to consider the computed path
         as acceptable.  The path metric must be less than or equal to
         the value specified in the metric-value field.  When the B flag
         is cleared, the metric-value field is not used to reflect a
         bound constraint.

Top      Up      ToC       Page 38 
      *  C (Computed Metric - 1 bit): When set in a PCReq message, this
         indicates that the PCE MUST provide the computed path metric
         value (should a path satisfying the constraints be found) in
         the PCRep message for the corresponding metric.

      Unassigned flags MUST be set to zero on transmission and MUST be
      ignored on receipt.

   Metric-value (32 bits):  metric value encoded in 32 bits in IEEE
      floating point format (see [IEEE.754.1985]).

   Multiple METRIC objects MAY be inserted in a PCRep or a PCReq message
   for a given request (i.e., for a given RP).  For a given request,
   there MUST be at most one instance of the METRIC object for each
   metric type with the same B flag value.  If, for a given request, two
   or more instances of a METRIC object with the same B flag value are
   present for a metric type, only the first instance MUST be considered
   and other instances MUST be ignored.

   For a given request, the presence of two METRIC objects of the same
   type with a different value of the B flag is allowed.  Furthermore,
   it is also allowed to insert, for a given request, two METRIC objects
   with different types that have both their B flag cleared: in this
   case, an objective function must be used by the PCE to solve a multi-
   parameter optimization problem.

   A METRIC object used to indicate the metric to optimize during the
   path computation MUST have the B flag cleared and the C flag set to
   the appropriate value.  When the path computation relates to the
   reoptimization of an exiting TE LSP (in which case, the R flag of the
   RP object is set), an implementation MAY decide to set the metric-
   value field to the computed value of the metric of the TE LSP to be
   reoptimized with regards to a specific metric type.

   A METRIC object used to reflect a bound MUST have the B flag set, and
   the C flag and metric-value field set to the appropriate values.

   In a PCRep message, unless not allowed by PCE policy, at least one
   METRIC object MUST be present that reports the computed path metric
   if the C flag of the METRIC object was set in the corresponding path
   computation request (the B flag MUST be cleared).  The C flag has no
   meaning in a PCRep message.  Optionally, the PCRep message MAY
   contain additional METRIC objects that correspond to bound
   constraints; in which case, the metric-value MUST be equal to the
   corresponding computed path metric (the B flag MUST be set).  If no
   path satisfying the constraints could be found by the PCE, the METRIC
   objects MAY also be present in the PCRep message with the NO-PATH
   object to indicate the constraint metric that could be satisfied.

Top      Up      ToC       Page 39 
   Example: if a PCC sends a path computation request to a PCE where the
   metric to optimize is the IGP metric and the TE metric must not
   exceed the value of M, two METRIC objects are inserted in the PCReq
   message:

   o  First METRIC object with B=0, T=1, C=1, metric-value=0x0000

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

   If a path satisfying the set of constraints can be found by the PCE
   and there is no policy that prevents the return of the computed
   metric, the PCE inserts one METRIC object with B=0, T=1, metric-
   value= computed IGP path cost.  Additionally, the PCE may insert a
   second METRIC object with B=1, T=2, metric-value= computed TE path
   cost.

7.9.  Explicit Route Object

   The ERO is used to encode the path of a TE LSP through the network.
   The ERO is carried within a PCRep message to provide the computed TE
   LSP if the path computation was successful.

   The contents of this object are identical in encoding to the contents
   of the Resource Reservation Protocol Traffic Engineering Extensions
   (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209],
   [RFC3473], and [RFC3477].  That is, the object is constructed from a
   series of sub-objects.  Any RSVP-TE ERO sub-object already defined or
   that could be defined in the future for use in the RSVP-TE ERO is
   acceptable in this object.

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

   Since the explicit path is available for immediate signaling by the
   MPLS or GMPLS control plane, the meanings of all of the sub-objects
   and fields in this object are identical to those defined for the ERO.

   ERO Object-Class is 7.

   ERO Object-Type is 1.

7.10.  Reported Route Object

   The RRO is exclusively carried within a PCReq message so as to report
   the route followed by a TE LSP for which a reoptimization is desired.

   The contents of this object are identical in encoding to the contents
   of the Route Record Object defined in [RFC3209], [RFC3473], and
   [RFC3477].  That is, the object is constructed from a series of sub-

Top      Up      ToC       Page 40 
   objects.  Any RSVP-TE RRO sub-object already defined or that could be
   defined in the future for use in the RSVP-TE RRO is acceptable in
   this object.

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

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

   RRO Object-Class is 8.

   RRO Object-Type is 1.



(page 40 continued on part 3)

Next RFC Part