6.  PCEP Messages

   As defined in [RFC5440], a PCEP message consists of a common header
   followed by a variable-length body made of a set of objects.  For
   each PCEP message type, a set of rules is defined that specifies the
   set of objects that the message can carry.

6.1.  The PCRpt Message

   A Path Computation LSP State Report message (also referred to as a
   PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
   current state of an LSP.  A PCRpt message can carry more than one LSP
   State Reports.  A PCC can send an LSP State Report either in response
   to an LSP Update Request from a PCE or asynchronously when the state
   of an LSP changes.  The Message-Type field of the PCEP common header
   for the PCRpt message is 10.

   The format of the PCRpt message is as follows:

      <PCRpt Message> ::= <Common Header>
                          <state-report-list>
   Where:

      <state-report-list> ::= <state-report>[<state-report-list>]

      <state-report> ::= [<SRP>]
                         <LSP>
                         <path>
    Where:
      <path>::= <intended-path>
                [<actual-attribute-list><actual-path>]
                <intended-attribute-list>

      <actual-attribute-list>::=[<BANDWIDTH>]
                                [<metric-list>]

   Where:
      <intended-path> is represented by the ERO object defined in
      Section 7.9 of [RFC5440].

      <actual-attribute-list> consists of the actual computed and
      signaled values of the <BANDWIDTH> and <metric-lists> objects
      defined in [RFC5440].

      <actual-path> is represented by the RRO object defined in
      Section 7.10 of [RFC5440].

      <intended-attribute-list> is the attribute-list defined in
      Section 6.5 of [RFC5440] and extended by PCEP extensions.

   The SRP object (see Section 7.2) is OPTIONAL.  If the PCRpt message
   is not in response to a PCupd message, the SRP object MAY be omitted.

   When the PCC does not include the SRP object, the PCE MUST treat this
   as an SRP object with an SRP-ID-number equal to the reserved value
   0x00000000.  The reserved value 0x00000000 indicates that the state
   reported is not a result of processing a PCUpd message.

   If the PCRpt message is in response to a PCUpd message, the SRP
   object MUST be included and the value of the SRP-ID-number in the SRP
   object MUST be the same as that sent in the PCUpd message that
   triggered the state that is reported.  If the PCC compressed several
   PCUpd messages for the same LSP by only processing the one with the
   highest number, then it should use the SRP-ID-number of that request.
   No state compression is allowed for state reporting, e.g., PCRpt
   messages MUST NOT be pruned from the PCC's egress queue even if
   subsequent operations on the same LSP have been completed before the
   PCRpt message has been sent to the TCP stack.  The PCC MUST
   explicitly report state changes (including removal) for paths it
   manages.

   The LSP object (see Section 7.3) is REQUIRED, and it MUST be included
   in each LSP State Report on the PCRpt message.  If the LSP object is
   missing, the receiving PCE MUST send a PCErr message with
   Error-type=6 (Mandatory Object missing) and Error-value 8 (LSP object
   missing).

   If the LSP transitioned to non-operational state, the PCC SHOULD
   include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
   Code to report the error to the PCE.

   The intended path, represented by the ERO object, is REQUIRED.  If
   the ERO object is missing, the receiving PCE MUST send a PCErr
   message with Error-type=6 (Mandatory Object missing) and Error-value
   9 (ERO object missing).  The ERO may be empty if the PCE does not
   have a path for a delegated LSP.

   The actual path, represented by the RRO object, SHOULD be included in
   a PCRpt by the PCC when the path is up or active, but it MAY be
   omitted if the path is down due to a signaling error or another
   failure.

   The intended-attribute-list maps to the attribute-list in Section 6.5
   of [RFC5440] and is used to convey the requested parameters of the
   LSP path.  This is needed in order to support the switch from passive

   to active stateful PCE as described in Section 5.8.2.  When included
   as part of the intended-attribute-list, the meaning of the BANDWIDTH
   object is the requested bandwidth as intended by the operator.  In
   this case, the BANDWIDTH Object-Type of 1 SHOULD be used.  Similarly,
   to indicate a limiting constraint, the METRIC object SHOULD be
   included as part of the intended-attribute-list with the B flag set
   and with a specific metric value.  To indicate the optimization
   metric, the METRIC object SHOULD be included as part of the
   intended-attribute-list with the B flag unset and the metric value
   set to zero.  Note that the intended-attribute-list is optional and
   thus may be omitted.  In this case, the PCE MAY use the values in the
   actual-attribute-list as the requested parameters for the path.

   The actual-attribute-list consists of the actual computed and
   signaled values of the BANDWIDTH and METRIC objects defined in
   [RFC5440].  When included as part of the actual-attribute-list,
   Object-Type 2 [RFC5440] SHOULD be used for the BANDWIDTH object, and
   the C flag SHOULD be set in the METRIC object [RFC5440].

   Note that the ordering of intended-path, actual-attribute-list,
   actual-path, and intended-attribute-list is chosen to retain
   compatibility with implementations of an earlier version of this
   standard.

   A PCE may choose to implement a limit on the resources a single PCC
   can occupy.  If a PCRpt is received that causes the PCE to exceed
   this limit, the PCE MUST notify the PCC using a PCNtf message with
   Notification Type 4 (Stateful PCE resource limit exceeded) and
   Notification Value 1 (Entering resource limit exceeded state), and it
   MUST terminate the session.

6.2.  The PCUpd Message

   A Path Computation LSP Update Request message (also referred to as
   PCUpd message) is a PCEP message sent by a PCE to a PCC to update
   attributes of an LSP.  A PCUpd message can carry more than one LSP
   Update Request.  The Message-Type field of the PCEP common header for
   the PCUpd message is 11.

   The format of a PCUpd message is as follows:

      <PCUpd Message> ::= <Common Header>
                          <update-request-list>
   Where:

      <update-request-list> ::= <update-request>[<update-request-list>]

      <update-request> ::= <SRP>
                           <LSP>
                           <path>
   Where:
      <path>::= <intended-path><intended-attribute-list>

   Where:
      <intended-path> is represented by the ERO object defined in
      Section 7.9 of [RFC5440].

      <intended-attribute-list> is the attribute-list defined in
      [RFC5440] and extended by PCEP extensions.

   There are three mandatory objects that MUST be included within each
   LSP Update Request in the PCUpd message: the SRP object (see
   Section 7.2), the LSP object (see Section 7.3) and the ERO object (as
   defined in [RFC5440], which represents the intended path.  If the SRP
   object is missing, the receiving PCC MUST send a PCErr message with
   Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
   object missing).  If the LSP object is missing, the receiving PCC
   MUST send a PCErr message with Error-type=6 (Mandatory Object
   missing) and Error-value=8 (LSP object missing).  If the ERO object
   is missing, the receiving PCC MUST send a PCErr message with
   Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object
   missing).

   The ERO in the PCUpd may be empty if the PCE cannot find a valid path
   for a delegated LSP.  One typical situation resulting in this empty
   ERO carried in the PCUpd message is that a PCE can no longer find a
   strict SRLG-disjoint path for a delegated LSP after a link failure.
   The PCC SHOULD implement a local policy to decide the appropriate
   action to be taken: either tear down the LSP or revoke the delegation
   and use a locally computed path, or keep the existing LSP.

   A PCC only acts on an LSP Update Request if permitted by the local
   policy configured by the network manager.  Each LSP Update Request
   that the PCC acts on results in an LSP setup operation.  An LSP
   Update Request MUST contain all LSP parameters that a PCE wishes to

   be set for the LSP.  A PCC MAY set missing parameters from locally
   configured defaults.  If the LSP specified in the Update Request is
   already up, it will be re-signaled.

   The PCC SHOULD minimize the traffic interruption and MAY use the
   make-before-break procedures described in [RFC3209] in order to
   achieve this goal.  If the make-before-break procedures are used, two
   paths will briefly coexist.  The PCC MUST send separate PCRpt
   messages for each, identified by the LSP-IDENTIFIERS TLV.  When the
   old path is torn down after the head end switches over the traffic,
   this event MUST be reported by sending a PCRpt message with the
   LSP-IDENTIFIERS-TLV of the old path and the R bit set.  The
   SRP-ID-number that the PCC associates with this PCRpt MUST be
   0x00000000.  Thus, a make-before-break operation will typically
   result in at least two PCRpt messages, one for the new path and one
   for the removal of the old path (more messages may be possible if
   intermediate states are reported).

   If the path setup fails due to an RSVP signaling error, the error is
   reported to the PCE.  The PCC will not attempt to re-signal the path
   until it is prompted again by the PCE with a subsequent PCUpd
   message.

   A PCC MUST respond with an LSP State Report to each LSP Update
   Request it processed to indicate the resulting state of the LSP in
   the network (even if this processing did not result in changing the
   state of the LSP).  The SRP-ID-number included in the PCRpt MUST
   match that in the PCUpd.  A PCC MAY respond with multiple LSP State
   Reports to report LSP setup progress of a single LSP.  In that case,
   the SRP-ID-number MUST be included for the first message; for
   subsequent messages, the reserved value 0x00000000 SHOULD be used.

   Note that a PCC MUST process all LSP Update Requests -- for example,
   an LSP Update Request is sent when a PCE returns delegation or puts
   an LSP into non-operational state.  The protocol relies on TCP for
   message-level flow control.

   If the rate of PCUpd messages sent to a PCC for the same target LSP
   exceeds the rate at which the PCC can signal LSPs into the network,
   the PCC MAY perform state compression on its ingress queue.  The
   compression algorithm is based on the fact that each PCUpd request
   contains the complete LSP state the PCE wishes to be set and works as
   follows: when the PCC starts processing a PCUpd message at the head
   of its ingress queue, it may search the queue forward for more recent
   PCUpd messages pertaining to that particular LSP, prune all but the
   latest one from the queue, and process only the last one as that
   request contains the most up-to-date desired state for the LSP.  The
   PCC MUST NOT send PCRpt nor PCErr messages for requests that were

   pruned from the queue in this way.  This compression step may be
   performed only while the LSP is not being signaled, e.g., if two
   PCUpd arrive for the same LSP in quick succession and the PCC started
   the signaling of the changes relevant to the first PCUpd, then it
   MUST wait until the signaling finishes (and report the new state via
   a PCRpt) before attempting to apply the changes indicated in the
   second PCUpd.

   Note also that it is up to the PCE to handle inter-LSP dependencies;
   for example, if ordering of LSP setups is required, the PCE has to
   wait for an LSP State Report for a previous LSP before starting the
   update of the next LSP.

   If the PCUpd cannot be satisfied (for example, due to an unsupported
   object or a TLV), the PCC MUST respond with a PCErr message
   indicating the failure (see Section 7.3.3).

6.3.  The PCErr Message

   If the stateful PCE capability has been advertised on the PCEP
   session, the PCErr message MAY include the SRP object.  If the error
   reported is the result of an LSP Update Request, then the
   SRP-ID-number MUST be the one from the PCUpd that triggered the
   error.  If the error is unsolicited, the SRP object MAY be omitted.
   This is equivalent to including an SRP object with the SRP-ID-number
   equal to the reserved value 0x00000000.

   The format of a PCErr message from [RFC5440] is extended 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> | <stateful-request-id-list>]
                 <error-obj-list>

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

      <stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]

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

6.4.  The PCReq Message

   A PCC MAY include the LSP object in the PCReq message (see
   Section 7.3) if the stateful PCE capability has been negotiated on a
   PCEP session between the PCC and a PCE.

   The definition of the PCReq message from [RFC5440] is extended to
   optionally include the LSP object after the END-POINTS object.  The
   encoding from [RFC5440] will become:

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

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

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

6.5.  The PCRep Message

   A PCE MAY include the LSP object in the PCRep message (see
   Section 7.3) if the stateful PCE capability has been negotiated on a
   PCEP session between the PCC, and the PCE and the LSP object were
   included in the corresponding PCReq message from the PCC.

   The definition of the PCRep message from [RFC5440] is extended to
   optionally include the LSP object after the Request Parameter (RP)
   object.  The encoding from [RFC5440] will become:

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

   Where:

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

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


7.  Object Formats

   The PCEP objects defined in this document are compliant with the PCEP
   object format defined in [RFC5440].  The P and I flags of the PCEP
   objects defined in the current document MUST be set to 0 on
   transmission and SHOULD be ignored on receipt since they are
   exclusively related to path computation requests.

7.1.  OPEN Object

   This document defines one new optional TLV for use in the OPEN
   object.

7.1.1.  STATEFUL-PCE-CAPABILITY TLV

   The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
   OPEN object for stateful PCE capability advertisement.  Its format is
   shown in the following figure:

      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=16         |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Flags                           |U|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 9: STATEFUL-PCE-CAPABILITY TLV Format

   The type (16 bits) of the TLV is 16.  The length field is 16 bits
   long and has a fixed value of 4.

   The value comprises a single field -- Flags (32 bits):

   U (LSP-UPDATE-CAPABILITY - 1 bit):  if set to 1 by a PCC, the U flag
      indicates that the PCC allows modification of LSP parameters; if
      set to 1 by a PCE, the U flag indicates that the PCE is capable of

      updating LSP parameters.  The LSP-UPDATE-CAPABILITY flag must be
      advertised by both a PCC and a PCE for PCUpd messages to be
      allowed on a PCEP session.

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

   A PCEP speaker operating in passive stateful PCE mode advertises the
   stateful PCE capability with the U flag set to 0.  A PCEP speaker
   operating in active stateful PCE mode advertises the stateful PCE
   capability with the U flag set to 1.

   Advertisement of the stateful PCE capability implies support of LSPs
   that are signaled via RSVP, as well as the objects, TLVs, and
   procedures defined in this document.

7.2.  SRP Object

   The SRP (Stateful PCE Request Parameters) object MUST be carried
   within PCUpd messages and MAY be carried within PCRpt and PCErr
   messages.  The SRP object is used to correlate between update
   requests sent by the PCE and the error reports and state reports sent
   by the PCC.

   SRP Object-Class is 33.

   SRP Object-Type is 1.

   The format of the SRP object body is shown in Figure 10:

       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                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        SRP-ID-number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                      Optional TLVs                          //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 10: The SRP Object Format

   The SRP object body has a variable length and may contain additional
   TLVs.

   Flags (32 bits): None defined yet.

   SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the
   current PCEP session uniquely identifies the operation that the PCE
   has requested the PCC to perform on a given LSP.  The SRP-ID-number
   is incremented each time a new request is sent to the PCC, and it may
   wrap around.

   The values 0x00000000 and 0xFFFFFFFF are reserved.

   Optional TLVs MAY be included within the SRP object body.  The
   specification of such TLVs is outside the scope of this document.

   Every request to update an LSP receives a new SRP-ID-number.  This
   number is unique per PCEP session and is incremented each time an
   operation is requested from the PCE.  Thus, for a given LSP, there
   may be more than one SRP-ID-number unacknowledged at a given time.
   The value of the SRP-ID-number is echoed back by the PCC in PCErr and
   PCRpt messages to allow for correlation between requests made by the
   PCE and errors or state reports generated by the PCC.  If the error
   or report was not a result of a PCE operation (for example, in the
   case of a link down event), the reserved value of 0x00000000 is used
   for the SRP-ID-number.  The absence of the SRP object is equivalent
   to an SRP object with the reserved value of 0x00000000.  An
   SRP-ID-number is considered unacknowledged and cannot be reused until
   a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for
   the same LSP.  In case of SRP-ID-number wrapping, the last
   SRP-ID-number before the wrapping MUST be explicitly acknowledged, to
   avoid a situation where SRP-ID-numbers remain unacknowledged after
   the wrap.  This means that the PCC may need to issue two PCUpd
   messages on detecting a wrap.

7.3.  LSP Object

   The LSP object MUST be present within PCRpt and PCUpd messages.  The
   LSP object MAY be carried within PCReq and PCRep messages if the
   stateful PCE capability has been negotiated on the session.  The LSP
   object contains a set of fields used to specify the target LSP, the
   operation to be performed on the LSP, and LSP delegation.  It also
   contains a flag indicating to a PCE that the LSP State
   Synchronization is in progress.  This document focuses on LSPs that
   are signaled with RSVP; many of the TLVs used with the LSP object
   mirror RSVP state.

   LSP Object-Class is 32.

   LSP Object-Type is 1.

   The format of the LSP object body is shown in Figure 11:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                PLSP-ID                |    Flag |  O  |A|R|S|D|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        TLVs                                 //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 11: The LSP Object Format

   PLSP-ID (20 bits): A PCEP-specific identifier for the LSP.  A PCC
   creates a unique PLSP-ID for each LSP that is constant for the
   lifetime of a PCEP session.  The PCC will advertise the same PLSP-ID
   on all PCEP sessions it maintains at a given time.  The mapping of
   the symbolic path name to PLSP-ID is communicated to the PCE by
   sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV.  All
   subsequent PCEP messages then address the LSP by the PLSP-ID.  The
   values of 0 and 0xFFFFF are reserved.  Note that the PLSP-ID is a
   value that is constant for the lifetime of the PCEP session, during
   which time for an RSVP-signaled LSP there might be different RSVP
   identifiers (LSP-id, tunnel-id) allocated to it.

   Flags (12 bits), starting from the least significant bit:

   D (Delegate - 1 bit):  On a PCRpt message, the D flag set to 1
      indicates that the PCC is delegating the LSP to the PCE.  On a
      PCUpd message, the D flag set to 1 indicates that the PCE is
      confirming the LSP delegation.  To keep an LSP delegated to the
      PCE, the PCC must set the D flag to 1 on each PCRpt message for
      the duration of the delegation -- the first PCRpt with the D flag
      set to 0 revokes the delegation.  To keep the delegation, the PCE
      must set the D flag to 1 on each PCUpd message for the duration of
      the delegation -- the first PCUpd with the D flag set to 0 returns
      the delegation.

   S (SYNC - 1 bit):  The S flag MUST be set to 1 on each PCRpt sent
      from a PCC during State Synchronization.  The S flag MUST be set
      to 0 in other messages sent from the PCC.  When sending a PCUpd
      message, the PCE MUST set the S flag to 0.

   R (Remove - 1 bit):  On PCRpt messages, the R flag indicates that the
      LSP has been removed from the PCC and the PCE SHOULD remove all
      state from its database.  Upon receiving an LSP State Report with
      the R flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
      remove all state for the path identified by the LSP-IDENTIFIERS

      TLV from its database.  When the all-zeros LSP-IDENTIFIERS TLV is
      used, the PCE SHOULD remove all state for the PLSP-ID from its
      database.  When sending a PCUpd message, the PCE MUST set the R
      flag to 0.

   A (Administrative - 1 bit):  On PCRpt messages, the A flag indicates
      the PCC's target operational status for this LSP.  On PCUpd
      messages, the A flag indicates the LSP status that the PCE desires
      for this LSP.  In both cases, a value of '1' means that the
      desired operational state is active, and a value of '0' means that
      the desired operational state is inactive.  A PCC ignores the A
      flag on a PCUpd message unless the operator's policy allows the
      PCE to control the corresponding LSP's administrative state.

   O (Operational - 3 bits):  On PCRpt messages, the O field represents
      the operational status of the LSP.

      The following values are defined:

      0 - DOWN:         not active.

      1 - UP:           signaled.

      2 - ACTIVE:       up and carrying traffic.

      3 - GOING-DOWN:   LSP is being torn down, and resources are being
                        released.

      4 - GOING-UP:     LSP is being signaled.

      5-7 - Reserved:   these values are reserved for future use.

   Unassigned bits are reserved for future uses.  They MUST be set to 0
   on transmission and MUST be ignored on receipt.  When sending a PCUpd
   message, the PCE MUST set the O field to 0.

   TLVs that may be included in the LSP object are described in the
   following sections.  Other optional TLVs, that are not defined in
   this document, MAY also be included within the LSP object body.

7.3.1.  LSP-IDENTIFIERS TLVs

   The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt
   messages for RSVP-signaled LSPs.  If the TLV is missing, the PCE will
   generate an error with Error-type=6 (Mandatory Object missing) and
   error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session.
   The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd
   messages for RSVP-signaled LSPs.  The special value of all zeros for

   this TLV is used to refer to all paths pertaining to a particular
   PLSP-ID.  There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one
   for IPv6.

   It is the responsibility of the PCC to send to the PCE the
   identifiers for each RSVP incarnation of the tunnel.  For example, in
   a make-before-break scenario, the PCC MUST send a separate PCRpt for
   the old and reoptimized paths and explicitly report removal of any of
   these paths using the R bit in the LSP object.

   The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
   figure:

      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=18             |           Length=16           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Sender Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             LSP ID            |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Extended Tunnel ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Endpoint Address                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 12: IPV4-LSP-IDENTIFIERS TLV Format

   The type (16 bits) of the TLV is 18.  The length field is 16 bits
   long and has a fixed value of 16.  The value contains the following
   fields:

   IPv4 Tunnel Sender Address:  contains the sender node's IPv4 address,
      as defined in [RFC3209], Section 4.6.2.1, for the LSP_TUNNEL_IPv4
      Sender Template Object.

   LSP ID:  contains the 16-bit 'LSP ID' identifier defined in
      [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
      Object.  A value of 0 MUST be used if the LSP is not yet signaled.

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.

   Extended Tunnel ID:  contains the 32-bit 'Extended Tunnel ID'
      identifier defined in [RFC3209], Section 4.6.1.1 for the
      LSP_TUNNEL_IPv4 Session Object.

   IPv4 Tunnel Endpoint Address:  contains the egress node's IPv4
      address, as defined in [RFC3209], Section 4.6.1.1, for the
      LSP_TUNNEL_IPv4 Sender Template Object.

   The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following
   figure:

      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=19             |           Length=52           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                  IPv6 Tunnel Sender Address                   |
     +                          (16 octets)                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             LSP ID            |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                       Extended Tunnel ID                      |
     +                          (16 octets)                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                  IPv6 Tunnel Endpoint Address                 |
     +                          (16 octets)                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 13: IPV6-LSP-IDENTIFIERS TLV Format

   The type (16 bits) of the TLV is 19.  The length field is 16 bits
   long and has a fixed value of 52.  The value contains the following
   fields:

   IPv6 Tunnel Sender Address:  contains the sender node's IPv6 address,
      as defined in [RFC3209], Section 4.6.2.2, for the LSP_TUNNEL_IPv6
      Sender Template Object.

   LSP ID:  contains the 16-bit 'LSP ID' identifier defined in
      [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
      Object.  A value of 0 MUST be used if the LSP is not yet signaled.

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.

   Extended Tunnel ID:  contains the 128-bit 'Extended Tunnel ID'
      identifier defined in [RFC3209], Section 4.6.1.2 for the
      LSP_TUNNEL_IPv6 Session Object.

   IPv6 Tunnel Endpoint Address:  contains the egress node's IPv6
      address, as defined in [RFC3209], Section 4.6.1.2, for the
      LSP_TUNNEL_IPv6 Session Object.

   The Tunnel ID remains constant over the lifetime of a tunnel.

7.3.2.  Symbolic Path Name TLV

   Each LSP MUST have a symbolic path name that is unique in the PCC.
   The symbolic path name is a human-readable string that identifies an
   LSP in the network.  The symbolic path name MUST remain constant
   throughout an LSP's lifetime, which may span across multiple
   consecutive PCEP sessions and/or PCC restarts.  The symbolic path
   name MAY be specified by an operator in a PCC's configuration.  If
   the operator does not specify a unique symbolic name for an LSP, then
   the PCC MUST auto-generate one.

   The PCE uses the symbolic path name as a stable identifier for the
   LSP.  If the PCEP session restarts, or the PCC restarts, or the PCC
   re-delegates the LSP to a different PCE, the symbolic path name for
   the LSP remains constant and can be used to correlate across the PCEP
   session instances.

   The other protocol identifiers for the LSP cannot reliably be used to
   identify the LSP across multiple PCEP sessions, for the following
   reasons.

   o  The PLSP-ID is unique only within the scope of a single PCEP
      session.

   o  The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs
      that are signaled with RSVP-TE, and it may change during the
      lifetime of the LSP.

   The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
   LSP State Report (PCRpt) message when during a given PCEP session an
   LSP is first reported to a PCE.  A PCC sends to a PCE the first LSP

   State Report either during State Synchronization or when a new LSP is
   configured at the PCC.

   The initial PCRpt creates a binding between the symbolic path name
   and the PLSP-ID for the LSP that lasts for the duration of the PCEP
   session.  The PCC MAY omit the symbolic path name from subsequent LSP
   State Reports for that LSP on that PCEP session, and just use the
   PLSP-ID.

   The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
   figure:

      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=17             |       Length (variable)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                      Symbolic Path Name                     //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 14: SYMBOLIC-PATH-NAME TLV Format

   Type (16 bits): the type is 17.

   Length (16 bits): indicates the total length of the TLV in octets and
   MUST be greater than 0.  The TLV MUST be zero-padded so that the TLV
   is 4-octet aligned.

   Symbolic Path Name (variable): symbolic name for the LSP, unique in
   the PCC.  It SHOULD be a string of printable ASCII characters,
   without a NULL terminator.

7.3.3.  LSP Error Code TLV

   The LSP Error Code TLV is an optional TLV for use in the LSP object
   to convey error information.  When an LSP Update Request fails, an
   LSP State Report MUST be sent to report the current state of the LSP,
   and it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason
   for the failure.  Similarly, when a PCRpt is sent as a result of an
   LSP transitioning to non-operational state, the LSP-ERROR-CODE TLV
   SHOULD be included to indicate the reason for the transition.

   The format of the LSP-ERROR-CODE TLV is shown in the following
   figure:

      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=20             |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LSP Error Code                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 15: LSP-ERROR-CODE TLV Format

   The type (16 bits) of the TLV is 20.  The length field is 16 bits
   long and has a fixed value of 4.  The value contains an error code
   that indicates the cause of the failure.

   The following LSP Error Codes are currently defined:

               Value      Description
               -----      -------------------------------------
                 1        Unknown reason
                 2        Limit reached for PCE-controlled LSPs
                 3        Too many pending LSP Update Requests
                 4        Unacceptable parameters
                 5        Internal error
                 6        LSP administratively brought down
                 7        LSP preempted
                 8        RSVP signaling error

7.3.4.  RSVP Error Spec TLV

   The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
   to carry RSVP error information.  It includes the RSVP ERROR_SPEC or
   USER_ERROR_SPEC object ([RFC2205] and [RFC5284]), which were returned
   to the PCC from a downstream node.  If the setup of an LSP fails at a
   downstream node that returned an ERROR_SPEC to the PCC, the PCC
   SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with
   LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV
   with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC object.

   The format of the RSVP-ERROR-SPEC TLV is shown in the following
   figure:

      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=21             |            Length (variable)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                RSVP ERROR_SPEC or USER_ERROR_SPEC Object      +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 16: RSVP-ERROR-SPEC TLV Format

   Type (16 bits): the type is 21.

   Length (16 bits): indicates the total length of the TLV in octets.
   The TLV MUST be zero-padded so that the TLV is 4-octet aligned.

   Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
   object, as specified in [RFC2205] and [RFC5284], including the object
   header.