Skip to main content

PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-07

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8231.
Authors Edward Crabbe , Jan Medved , Ina Minei , Robert Varga
Last updated 2013-10-08
Replaces draft-crabbe-pce-stateful-pce, draft-crabbe-pce-stateful-pce-mpls-te
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8231 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pce-stateful-pce-07
#x27;s PCEP session with a PCE terminates unexpectedly, the PCC
   MUST wait the time interval specified in Redelegation Timeout
   Interval before revoking LSP delegations to that PCE and attempting
   to redelegate LSPs to an alternate PCE.  If a PCEP session with the
   original PCE can be reestablished before the Redelegation Timeout
   Interval timer expires, LSP delegations to the PCE remain intact.

   Likewise, when a PCC's PCEP session with a PCE terminates
   unexpectedly, the PCC MUST wait for the State Timeout Interval before
   flushing any LSP state associated with that PCE.  Note that the State
   Timeout Interval timer may expire before the PCC has redelegated the
   LSPs to another PCE, for example if a PCC is not connected to any
   active stateful PCE or if no connected active stateful PCE accepts
   the delegation.  In this case, the PCC SHALL flush any LSP state set
   by the PCE upon expiration of the State Timeout Interval and revert
   to operator-defined default parameters.  This operation SHOULD be
   done in a make-before-break fashion.

   The State Timeout Interval SHOULD be greater than or equal to the

Crabbe, et al.           Expires April 11, 2014                [Page 17]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   Redelegation Timeout Interval and MAY be set to infinity (meaning
   that until the PCC specifically takes action to change the parameters
   set by the PCE, they will remain intact).

5.5.3.  Returning a Delegation

   A PCE that no longer wishes to update an LSP's parameters SHOULD
   return the LSP delegation back to the PCC by sending an empty LSP
   Update Request which has the Delegate flag set to 0.  Note that in
   order to keep a delegation, the PCE MUST set the Delegate flag to 1
   on each LSP Update Request sent to the PCC.

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |---PCRpt, Delegate=1--->| LSP delegated
                       |            .           |
                       |            .           |
                       |            .           |
                       |<--PCUpd, Delegate=0----| Delegation returned
                       |                        |
                       |---PCRpt, Delegate=0--->| No delegation for LSP
                       |                        |

                     Figure 6: Returning a Delegation

   If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
   not connected to any active stateful PCE or if no connected active
   stateful PCE accepts the delegation), the LSP delegation on the PCC
   will time out within a configurable Redelegation Timeout Interval and
   the PCC MUST flush any LSP state set by a PCE at the expiration of
   the State Timeout Interval.

5.5.4.  Redundant Stateful PCEs

   In a redundant configuration where one PCE is backing up another PCE,
   the backup PCE may have only a subset of the LSPs in the network
   delegated to it.  The backup PCE does not update any LSPs that are
   not delegated to it.  In order to allow the backup to operate in a
   hot-standby mode and avoid the need for state synchronization in case
   the primary fails, the backup receives all LSP State Reports from a
   PCC.  When the primary PCE for a given LSP set fails, after expiry of
   the Redelegation Timeout Interval, the PCC SHOULD delegate to the
   redundant PCE all LSPs that had been previously delegated to the
   failed PCE.  Assuming that the State Timeout Interval had been
   configured to be larger than the Redelegation Timeout Interval (as
   recommended), this delegation change will not cause any changes to

Crabbe, et al.           Expires April 11, 2014                [Page 18]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   the LSP parameters.

5.5.5.  Redelegation on PCE Failure

   On failure, the goal is to: 1) avoid any traffic loss on the LSPs
   that were updated by the PCE that crashed 2) minimize the churn in
   the network in terms of ownership of the LSPs, 3) not leave any
   "orphan" (undelegated) LSPs and 4) be able to control when the state
   that was set by the PCE can be changed or purged.  The values chosen
   for the Redelegation Timeout and State Timeout values affect the
   ability to accomplish these goals.

   This section summarizes the behaviour with regards to LSP delegation
   and LSP state on a PCE failure.

   If the PCE crashes but recovers within the Redelegation Timeout, both
   the delegation state and the LSP state are kept intact.

   If the PCE crashes but does not recover within the Redelegation
   Timeout, the delegation state is returned to the PCC.  If the PCC can
   redelegate the LSPs to another PCE, and that PCE accepts the
   delegations, there will be no change in LSP state.  If the PCC cannot
   redelegate the LSPs to another PCE, then upon expiration of the State
   Timeout Interval, the state set by the PCE is flushed, which may
   cause change in the LSP state.  Note that an operator may choose to
   use an infinite State Timeout Interval if he wishes to maintain the
   PCE state indefinetely.  Note also that flushing the state should be
   implemented using make-before-break to avoid traffic loss.

   If there is a standby PCE, the Redelegation Timeout may be set to 0
   through policy on the PCC, causing the LSPs to be redelegated
   immediately to the PCC, which can delegate them immediately to the
   standby PCE.  Assuming the State Timeout Interval is larger than the
   Redelegation Timeout, the LSP state will be kept intact.

5.6.  LSP Operations

Crabbe, et al.           Expires April 11, 2014                [Page 19]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

5.6.1.  Passive Stateful PCE Path Computation Request/Response

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
   1) Path computation |----- PCReq message --->|
      request sent to  |                        |2) Path computation
      PCE              |                        |   request received,
                       |                        |   path computed
                       |                        |
                       |<---- PCRep message ----|3) Computed paths
                       |     (Positive reply)   |   sent to the PCC
                       |     (Negative reply)   |
   4) LSP Status change|                        |
      event            |                        |
                       |                        |
   5) LSP Status Report|----- PCRpt message --->|
      sent to all      |            .           |
      stateful PCEs    |            .           |
                       |            .           |
   6) Repeat for each  |----- PCRpt message --->|
      LSP status change|                        |
                       |                        |

     Figure 7: Passive Stateful PCE Path Computation Request/Response

   Once a PCC has successfully established a PCEP session with a passive
   stateful PCE and the PCC's LSP state is synchronized with the PCE
   (i.e. the PCE knows about all PCC's existing LSPs), if an event is
   triggered that requires the computation of a set of paths, the PCC
   sends a path computation request to the PCE ([RFC5440], Section
   4.2.3).

   Upon receiving a path computation request from a PCC, the PCE
   triggers a path computation and returns either a positive or a
   negative reply to the PCC ([RFC5440], Section 4.2.4).

   Upon receiving a positive path computation reply, the PCC receives a
   set of computed paths and starts to setup the LSPs.  For each LSP, it
   sends an LSP State Report carried on a PCRpt message to the PCE,
   indicating that the LSP's status is 'Pending'.

   Once an LSP is up, the PCC sends an LSP State Report carried on a
   PCRpt message to the PCE, indicating that the LSP's status is 'Up'.
   If the LSP could not be set up, the PCC sends an LSP State Report
   indicating that the LSP is "Down' and stating the cause of the
   failure.  Note that due to timing constraints, the LSP status may

Crabbe, et al.           Expires April 11, 2014                [Page 20]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   change from 'Pending' to 'Up' (or 'Down') before the PCC has had a
   chance to send an LSP State Report indicating that the status is
   'Pending'.  In such cases, the PCC may choose to only send the PCRpt
   indicating the latest status ('Up' or 'Down').

   Upon receiving a negative reply from a PCE, a PCC may decide to
   resend a modified request or take any other appropriate action.  For
   each requested LSP, it also sends an LSP State Report carried on a
   PCRpt message to the PCE, indicating that the LSP's status is 'Down'.

   There is no direct correlation between PCRep and PCRpt messages.  For
   a given LSP, multiple LSP State Reports will follow a single PCRep
   message, as a PCC notifies a PCE of the LSP's state changes.

   A PCC sends each LSP State Report to each stateful PCE that is
   connected to the PCC.

   Note that a single PCRpt message MAY contain multiple LSP State
   Reports.

   The passive stateful PCE is the model for stateful PCEs is described
   in [RFC4655], Section 6.8.

5.6.2.  Active Stateful PCE LSP Update

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
   1) LSP State        |-- PCRpt, Delegate=1 -->|
      Synchronization  |            .           |
      or add new LSP   |            .           |2) PCE decides to
                       |            .           |   update the LSP
                       |                        |
                       |<---- PCUpd message ----|3) PCUpd message sent
                       |                        |   to PCC
                       |                        |
                       |                        |
   4) LSP Status Report|---- PCRpt message ---->|
      sent(->Pending)  |            .           |
                       |            .           |
                       |            .           |
   5) LSP Status Report|---- PCRpt message ---->|
      sent (->Up|Down) |                        |
                       |                        |

                       Figure 8: Active Stateful PCE

Crabbe, et al.           Expires April 11, 2014                [Page 21]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   Once a PCC has successfully established a PCEP session with an active
   stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.
   the PCE knows about all PCC's existing LSPs) and LSPs have been
   delegated to the PCE, the PCE can modify LSP parameters of delegated
   LSPs.

   A PCE sends an LSP Update Request carried on a PCUpd message to the
   PCC.  The LSP Update Request contains a variety of objects that
   specify the set of constraints and attributes for the LSP's path.
   Each LSP Update Request has a unique identifier, the SRP-ID-number,
   carried in the SRP (Stateful PCE Request Parameters) Object described
   in Section 7.2.  The SRP-ID-number is used to correlate errors and
   state reports to LSP Update Requests.  A single PCUpd message MAY
   contain multiple LSP Update Requests.

   Upon receiving a PCUpd message the PCC starts to setup LSPs specified
   in LSP Update Requests carried in the message.  For each LSP, it
   sends an LSP State Report carried on a PCRpt message to the PCE,
   indicating that the LSP's status is 'Pending'.  If the PCC decides
   that the LSP parameters proposed in the PCUpd message are
   unacceptable, it MUST report this error by including the LSP-ERROR-
   CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
   parameters" in the LSP object in the PCRpt message to the PCE.  Based
   on local policy, it MAY react further to this error by revoking the
   delegation.  If the PCC receives a PCUpd message for an LSP object
   identified with a PLSP-ID that does not exist on the PCC, it MUST
   generate a PCErr with error-type 19 (Invalid Operation), error-value
   3, (Attempted LSP Update Request for an LSP identified by an unknown
   PSP-ID) (see Section 8.4).

   Once an LSP is up, the PCC sends an LSP State Report (PCRpt message)
   to the PCE, indicating that the LSP's status is 'Up'.  If the LSP
   could not be set up, the PCC sends an LSP State Report indicating
   that the LSP is 'Down' and stating the cause of the failure.  A PCC
   may choose to compress LSP State Reports to only reflect the most up
   to date state, as discussed in the previous section.

   A PCC sends each LSP State Report to each stateful PCE that is
   connected to the PCC.

   PCErr and PCRpt messages triggered as a result of a PCUpd message
   MUST include the SRP-ID-number from the PCUpd.  This provides
   correlation of requests and errors and acknowledgement of state
   processing.  The PCC may choose to compress state when processing
   PCUpd.  In this case, receipt of a higher SRP-ID-number implicitly
   acknowledges processing all the earlier updates for the specific LSP.

   A PCC MUST NOT send to any PCE a Path Computation Request for a

Crabbe, et al.           Expires April 11, 2014                [Page 22]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   delegated LSP.  Should the PCC decide it wants to issue a Path
   Computation Request on a delegated LSP, it MUST perform Delegation
   Revocation procedure first.

5.7.  LSP Protection

   LSP protection and interaction with stateful PCE, as well as the
   extensions necessary to implement this functionality will be
   discussed in a separate draft.

5.8.  Transport

   A permanent PCEP session MUST be established between a stateful PCE
   and the PCC.  In the case of session failure, session reestablishment
   MUST be re-attempted per the procedures defined in [RFC5440].

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 that can
   be either mandatory or optional.  An object is said to be mandatory
   in a PCEP message when the object must be included for the message to
   be considered valid.  For each PCEP message type, a set of rules is
   defined that specify the set of objects that the message can carry.
   An implementation MUST form the PCEP messages using the object
   ordering specified in this document.

6.1.  The PCRpt Message

   A Path Computation LSP State Report message (also referred to as
   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 set to [TBD].

   The format of the PCRpt message is as follows:

Crabbe, et al.           Expires April 11, 2014                [Page 23]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

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

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

   <state-report> ::= [<SRP>]
                      <LSP>
                      <path>
 Where:
   <path>::= <ERO><attribute-list>[<RRO>]

Where:
   <attribute-list> is defined in [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 treats 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 as a result of processing a PCUpd message.

   If the PCRpt message is in response to a PCUpd message, the SRP
   object SHOULD 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 latest one,
   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 mandatory, 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=[TBD] (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 RRO SHOULD be included by the PCC when the path is up, but MAY be
   omitted if the path is down due to a signaling error or another
   failure.

Crabbe, et al.           Expires April 11, 2014                [Page 24]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   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, it MUST send a PCErr message with error-type 19 (invalid
   operation) and error-value 4 (indicating resource limit exceeded) in
   response to the PCRpt message triggering this condition and MAY
   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 set to [TBD].

   The format of a PCUpd message is as follows:

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

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

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

Where:
   <attribute-list> is 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].  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).

   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

Crabbe, et al.           Expires April 11, 2014                [Page 25]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   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 co-exist.  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 PCE 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).

   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 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 which 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

Crabbe, et al.           Expires April 11, 2014                [Page 26]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   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 set-ups 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 unsupported object or 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 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>]  <<<< new
              <error-obj-list>

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

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

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

7.  Object Formats

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

Crabbe, et al.           Expires April 11, 2014                [Page 27]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

7.1.  OPEN Object

   This document defines two new optional TLVs 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=[TBD]      |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Flags                           |U|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 9: STATEFUL-PCE-CAPABILITY TLV format

   The type of the TLV is [TBD] and it has a fixed length of 4 octets.

   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.

   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, PCNtf 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 [TBD].

Crabbe, et al.           Expires April 11, 2014                [Page 28]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   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.  The SYMBOLIC-PATH-NAME TLV MAY be included as one of the
   optional 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 identify 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 may wrap
   around.

   The values 0x00000000 and 0xFFFFFFFF are reserved.

   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 were not as 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.  A PCRpt with state "Pending" is not considered as an
   acknowledgement.

Crabbe, et al.           Expires April 11, 2014                [Page 29]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

7.3.  LSP Object

   The LSP object MUST be present within PCRpt and PCUpd messages.  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 [TBD].

   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                |     Flags |  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 life
   time of a PCEP session.  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
   life time of the PCEP session, during which time for an RSVP-signaled
   LSP there might be a different RSVP identifiers (LSP-id, tunnel-id)
   allocated it.

   Flags (12 bits):

   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

Crabbe, et al.           Expires April 11, 2014                [Page 30]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

      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 PCRpt messages sent from the PCC.

   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.

   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:  signalled.

      2 - ACTIVE:  up and carrying traffic.

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

      4 - GOING-UP:  LSP is being signalled.

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

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

   TLVs that may be included in the LSP Object are described in the
   following sections.

Crabbe, et al.           Expires April 11, 2014                [Page 31]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

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 exmple, in
   a make-before-break scenario, the PCC MUST send a separate PCRpt for
   the old and for the 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=[TBD]          |           Length=12           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Sender Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             LSP ID            |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Extended Tunnel ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Endpoint Address                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 12: IPV4-LSP-IDENTIFIERS TLV format

   The type of the TLV is [TBD] and it has a fixed length of 12 octets.
   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.

Crabbe, et al.           Expires April 11, 2014                [Page 32]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
      Tunnel ID remains constant over the life time of a tunnel.

   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 l 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=[TBD]          |           Length=36           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                  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

Crabbe, et al.           Expires April 11, 2014                [Page 33]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   The type of the TLV is [TBD] and it has a fixed length of 36 octets.
   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.

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
      Tunnel ID remains constant over the life time of a tunnel.
      However, when Global Path Protection or Global Default Restoration
      is used, both the primary and secondary LSPs have their own Tunnel
      IDs.  A PCC will report a change in Tunnel ID when traffic
      switches over from primary LSP to secondary LSP (or vice versa).

   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.

7.3.2.  Symbolic Path Name TLV

   Each LSP (path) MUST have a symbolic name that is unique in the PCC.
   This symbolic path name MUST remain constant throughout a path'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 a path, the PCC MUST auto-generate one.

   The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
   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
   symbolic path name MAY be included in subsequent LSP State Reports
   for the LSP.

   The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object
   and the LSPA Object.

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

Crabbe, et al.           Expires April 11, 2014                [Page 34]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

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

                 Figure 14: SYMBOLIC-PATH-NAME TLV format

   The type of the TLV is [TBD] and it has a variable length, which MUST
   be greater than 0.

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 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=[TBD]          |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LSP Error Code                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 15: LSP-ERROR-CODE TLV format

   The type of the TLV is [TBD] and it has a fixed length of 4 octets.
   The value contains an error code that indicates the cause of the
   failure.

   The following LSP Error Codes are defined:

Crabbe, et al.           Expires April 11, 2014                [Page 35]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

                Value     Meaning
                  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 set up of an LSP fails at
   a downstream node which 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=[TBD]          |            Length (variable)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                RSVP ERROR_SPEC or USER_ERROR_SPEC Object      +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 16: RSVP-ERROR-SPEC TLV format

   The type of the TLV is [TBD] and it has a variable length.  The value
   contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the
   object header.

7.4.  Optional TLVs for the LSPA Object

   TLVs that may be included in the LSPA Object are described in the
   following sections and in separate technology-specific documents.

Crabbe, et al.           Expires April 11, 2014                [Page 36]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

7.4.1.  Symbolic Path Name TLV

   See section Section 7.3.2.

8.  IANA Considerations

   This document requests IANA actions to allocate code points for the
   protocol elements defined in this document.  Values shown here are
   suggested for use by IANA.

8.1.  PCEP Messages

   This document defines the following new PCEP messages:

       Value     Meaning               Reference
         10       Report               This document
         11       Update               This document

8.2.  PCEP Objects

   This document defines the following new PCEP Object-classes and
   Object-values:

   Object-Class Value   Name                               Reference

            32          LSP                                This document
                        Object-Type
                            1
            33          SRP                                This document
                        Object-Type
                            1

8.3.  LSP Object

   This document requests that a registry is created to manage the Flags
   field of the LSP object.  New values are to be assigned by Standards
   Action [RFC5226].  Each bit should be tracked with the following
   qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

Crabbe, et al.           Expires April 11, 2014                [Page 37]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

       Bit    Description           Reference

      25-27   Operational (3 bits)  This document
       28     Administrative        This document
       29     Remove                This document
       30     SYNC                  This document
       31     Delegate              This document

8.4.  PCEP-Error Object

   This document defines new Error-Type and Error-Value for the
   following new error conditions:

    Error-Type  Meaning
       6        Mandatory Object missing
                 Error-value=8:  LSP Object missing
                 Error-value=9:  ERO Object missing
                 Error-value=10: SRP Object missing
                 Error-value=11: LSP-IDENTIFIERS TLV missing
       19       Invalid Operation
                 Error-value=1:  Attempted LSP Update Request for a non-
                                 delegated LSP.  The PCEP-ERROR Object
                                 is followed by the LSP Object that
                                 identifies the LSP.
                 Error-value=2:  Attempted LSP Update Request if active
                                 stateful PCE capability was not
                                 advertised.
                 Error-value=3:  Attempted LSP Update Request for an LSP
                                 identified by an unknown PLSP-ID.
                 Error-value=4:  A PCE indicates to a PCC that it has
                                 exceeded the resource limit allocated
                                 for its state, and thus it cannot
                                 accept and process its LSP State Report
                                 message.
       20       LSP State synchronization error.
                 Error-value=1:  A PCE indicates to a PCC that it can
                                 not process (an otherwise valid) LSP
                                 State Report.  The PCEP-ERROR Object is
                                 followed by the LSP Object that
                                 identifies the LSP.
                 Error-value=5:  A PCC indicates to a PCE that it can
                                 not complete the state synchronization,

8.5.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs:

Crabbe, et al.           Expires April 11, 2014                [Page 38]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

       Value     Meaning                     Reference
         16       STATEFUL-PCE-CAPABILITY    This document
         17       SYMBOLIC-PATH-NAME         This document
         18       IPV4-LSP-IDENTIFIERS       This document
         19       IPV6-LSP-IDENTIFIERS       This document
         20       LSP-ERROR-CODE             This document
         21       RSVP-ERROR-SPEC            This document

8.6.  STATEFUL-PCE-CAPABILITY TLV

   This document requests that a registry is created to manage the Flags
   field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object.  New
   values are to be assigned by Standards Action [RFC5226].  Each bit
   should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

       Bit    Description           Reference

       31     LSP-UPDATE-CAPABILITY This document

8.7.  LSP-ERROR-CODE TLV

   This document requests that a registry is created to manage the value
   of the LSP error code field in this TLV.  This field specifies the
   reason for failure to update the LSP.

                Value     Meaning
                  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

9.  Manageability Considerations

   All manageability requirements and considerations listed in [RFC5440]
   apply to PCEP protocol extensions defined in this document.  In

Crabbe, et al.           Expires April 11, 2014                [Page 39]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   addition, requirements and considerations listed in this section
   apply.

9.1.  Control Function and Policy

   In addition to configuring specific PCEP session parameters, as
   specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST
   allow configuring the stateful PCEP capability and the LSP Update
   capability.  A PCC implementation SHOULD allow the operator to
   specify multiple candidate PCEs for and a delegation preference for
   each candidate PCE.  A PCC SHOULD allow the operator to specify an
   LSP delegation policy where LSPs are delegated to the most-preferred
   online PCE.  A PCC MAY allow the operator to specify different LSP
   delegation policies.

   A PCC implementation which allows concurrent connections to multiple
   PCEs SHOULD allow the operator to group the PCEs by administrative
   domains and it MUST NOT advertise LSP existence and state to a PCE if
   the LSP is delegated to a PCE in a different group.

   A PCC implementation SHOULD allow the operator to specify whether the
   PCC will advertise LSP existence and state for LSPs that are not
   controlled by any PCE (for example, LSPs that are statically
   configured at the PCC).

   A PCC implementation SHOULD allow the operator to specify both the
   Redelegation Timeout Interval and the State Timeout Interval.  The
   default value of the Redelegation Timeout Interval SHOULD be set to
   30 seconds.  An operator MAY also configure a policy that will
   dynamically adjust the Redelegation Timeout Interval, for example
   setting it to zero when the PCC has an established session to a
   backup PCE.  The default value for the State Timeout Interval SHOULD
   be set to 60 seconds.

   After the expiration of the State Timeout Interval, the LSP reverts
   to operator-defined default parameters.  A PCC implementation MUST
   allow the operator to specify the default LSP parameters.  To achieve
   a behavior where the LSP retains the parameters set by the PCE until
   such time that the PCC makes a change to them, a State Timeout
   Interval of infinity SHOULD be used.  Any changes to LSP parameters
   SHOULD be done in make-before-break fashion.

   A PCC implementation SHOULD allow the operator to specify delegation
   priority for PCEs.  This effectively defines the primary PCE and one
   or more backup PCEs to which primary PCE's LSPs can be delegated when
   the primary PCE fails.

   Policies defined for stateful PCEs and PCCs should eventually fit in

Crabbe, et al.           Expires April 11, 2014                [Page 40]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   the Policy-Enabled Path Computation Framework defined in [RFC5394],
   and the framework should be extended to support Stateful PCEs.

9.2.  Information and Data Models

   PCEP session configuration and information in the PCEP MIB module
   SHOULD be extended to include advertised stateful capabilities,
   synchronization status, and delegation status (at the PCC list PCEs
   with delegated LSPs).

9.3.  Liveness Detection and Monitoring

   PCEP protocol extensions defined in this document do not require any
   new mechanisms beyond those already defined in [RFC5440], Section
   8.3.

9.4.  Verifying Correct Operation

   Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP
   protocol extensions defined in this document.  In addition to
   monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP
   implementation SHOULD provide the following parameters:

   o  Total number of LSP updates

   o  Number of successful LSP updates

   o  Number of dropped LSP updates

   o  Number of LSP updates where LSP setup failed

   A PCC implementation SHOULD provide a command to show for each LSP
   whether it is delegated, and if so, to which PCE.

   A PCC implementation SHOULD allow the operator to manually revoke LSP
   delegation.

9.5.  Requirements on Other Protocols and Functional Components

   PCEP protocol extensions defined in this document do not put new
   requirements on other protocols.

9.6.  Impact on Network Operation

   Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP
   protocol extensions defined in this document.

   Additionally, a PCEP implementation SHOULD allow a limit to be placed

Crabbe, et al.           Expires April 11, 2014                [Page 41]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   on the number of LSPs delegated to the PcE and on the rate of PCUpd
   and PCRpt messages sent by a PCEP speaker and processed from a peer.
   It SHOULD also allow sending a notification when a rate threshold is
   reached.

   A PCC implementation SHOULD allow a limit to be placed on the rate of
   LSP Updates to the same LSP to avoid signaling overload discussed in
   Section 10.3.

10.  Security Considerations

10.1.  Vulnerability

   This document defines extensions to PCEP to enable stateful PCEs.
   The nature of these extensions and the delegation of path control to
   PCEs results in more information being available for a hypothetical
   adversary and a number of additional attack surfaces which must be
   protected.

   The security provisions described in [RFC5440] remain applicable to
   these extensions.  However, because the protocol modifications
   outlined in this document allow the PCE to control path computation
   timing and sequence, the PCE defense mechanisms described in
   [RFC5440] section 7.2 are also now applicable to PCC security.

   As a general precaution, it is RECOMMENDED that these PCEP extensions
   only be activated on authenticated and encrypted sessions across PCEs
   and PCCs belonging to the same administrative authority.

   The following sections identify specific security concerns that may
   result from the PCEP extensions outlined in this document along with
   recommended mechanisms to protect PCEP infrastructure against related
   attacks.

10.2.  LSP State Snooping

   The stateful nature of this extension explicitly requires LSP status
   updates to be sent from PCC to PCE.  While this gives the PCE the
   ability to provide more optimal computations to the PCC, it also
   provides an adversary with the opportunity to eavesdrop on decisions
   made by network systems external to PCE.  This is especially true if
   the PCC delegates LSPs to multiple PCEs simultaneously.

   Adversaries may gain access to this information by eavesdropping on
   unsecured PCEP sessions, and might then use this information in
   various ways to target or optimize attacks on network infrastructure.
   For example by flexibly countering anti-DDoS measures being taken to

Crabbe, et al.           Expires April 11, 2014                [Page 42]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   protect the network, or by determining choke points in the network
   where the greatest harm might be caused.

   PCC implementations which allow concurrent connections to multiple
   PCEs SHOULD allow the operator to group the PCEs by administrative
   domains and they MUST NOT advertise LSP existence and state to a PCE
   if the LSP is delegated to a PCE in a different group.

10.3.  Malicious PCE

   The LSP delegation mechanism described in this document allows a PCC
   to grant effective control of an LSP to the PCE for the duration of a
   PCEP session.  While this enables PCE control of the timing and
   sequence of path computations within and across PCEP sessions, it
   also introduces a new attack vector: an attacker may flood the PCC
   with PCUpd messages at a rate which exceeds either the PCC's ability
   to process them or the network's ability to signal the changes,
   either by spoofing messages or by compromising the PCE itself.

   A PCC is free to revoke an LSP delegation at any time without needing
   any justification.  A defending PCC can do this by enqueueing the
   appropriate PCRpt message.  As soon as that message is enqueued in
   the session, the PCC is free to drop any incoming PCUpd messages
   without additional processing.

10.4.  Malicious PCC

   A stateful session also result in increased attack surface by placing
   a requirement for the PCE to keep an LSP state replica for each PCC.
   It is RECOMMENDED that PCE implementations provide a limit on
   resources a single PCC can occupy.  A PCE implementing such a limit
   MUST send a PCErr message with error-type 19 (invalid operation) and
   error-value 4 (indicating resource limit exceeded) upon receiving an
   LSP state report causing it to exceed this threshold.

   Delegation of LSPs can create further strain on PCE resources and a
   PCE implementation MAY preemptively give back delegations if it finds
   itself lacking the resources needed to effectively manage the
   delegation.  Since the delegation state is ultimately controlled by
   the PCC, PCE implementations SHOULD provide throttling mechanisms to
   prevent strain created by flaps of either a PCEP session or an LSP
   delegation.

11.  Acknowledgements

   We would like to thank Adrian Farrel, Cyril Margaria and Ramon
   Casellas for their contributions to this document.

Crabbe, et al.           Expires April 11, 2014                [Page 43]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
   Paul Schultz and Raveendra Torvi for their comments and suggestions.
   Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon
   Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin
   Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin
   Sampath, Calvin Ying and Xian Zhang for helpful comments and
   discussions.

12.  References

12.1.  Normative References

   [I-D.ietf-pce-gmpls-pcep-extensions]
              Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
              GMPLS", draft-ietf-pce-gmpls-pcep-extensions-08 (work in
              progress), July 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.

   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "IS-IS Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5089, January 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

Crabbe, et al.           Expires April 11, 2014                [Page 44]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   [RFC5284]  Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
              RFC 5284, August 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

12.2.  Informative References

   [I-D.ietf-pce-stateful-pce-app]
              Zhang, X. and I. Minei, "Applicability of Stateful Path
              Computation Element (PCE)",
              draft-ietf-pce-stateful-pce-app-01 (work in progress),
              September 2013.

   [I-D.minei-pce-stateful-sync-optimizations]
              Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X.,
              and D. Dhody, "Optimizations of State Synchronization
              Procedures for Stateful PCE",
              draft-minei-pce-stateful-sync-optimizations-00 (work in
              progress), October 2013.

   [I-D.sivabalan-pce-disco-stateful]
              Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
              for Stateful PCE Discovery",
              draft-sivabalan-pce-disco-stateful-02 (work in progress),
              July 2013.

   [MPLS-PC]  Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
              LSP Path Computation using Preemption",  Global
              Information Infrastructure Symposium, July 2007.

   [MXMN-TE]  Danna, E., Mandal, S., and A. Singh, "Practical linear
              programming algorithm for balancing the max-min fairness
              and throughput objectives in traffic engineering",  pre-
              print, 2011.

   [NET-REC]  Vasseur, JP., Pickavet, M., and P. Demeester, "Network
              Recovery: Protection and Restoration of Optical, SONET-
              SDH, IP, and MPLS",  The Morgan Kaufmann Series in
              Networking, June 2004.

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",

Crabbe, et al.           Expires April 11, 2014                [Page 45]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

              RFC 2702, September 1999.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3346]  Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
              Christian, B., and W. Lai, "Applicability Statement for
              Traffic Engineering with MPLS", RFC 3346, August 2002.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC 5394,
              December 2008.

   [RFC5557]  Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
              Computation Element Communication Protocol (PCEP)
              Requirements and Protocol Extensions in Support of Global
              Concurrent Optimization", RFC 5557, July 2009.

Authors' Addresses

   Edward Crabbe
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: edc@google.com

Crabbe, et al.           Expires April 11, 2014                [Page 46]
Internet-Draft      PCEP Extensions for Stateful PCE        October 2013

   Jan Medved
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Email: jmedved@cisco.com

   Ina Minei
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: ina@juniper.net

   Robert Varga
   Pantheon Technologies SRO
   Mlynske Nivy 56
   Bratislava  821 05
   Slovakia

   Email: robert.varga@pantheon.sk

Crabbe, et al.           Expires April 11, 2014                [Page 47]