Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8231

 
 
 

Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

Part 2 of 4, p. 10 to 24
Prev Section       Next Section

 


prevText      Top      ToC       Page 10 
5.  Overview of Protocol Extensions

5.1.  LSP State Ownership

   In PCEP (defined in [RFC5440]), LSP state and operation are under the
   control of a PCC (a PCC may be a Label Switching Router (LSR) or a
   management station).  Attributes received from a PCE are subject to
   PCC's local policy.  The PCEP extensions described in this document
   do not change this behavior.

   An active stateful PCE may have control of a PCC's LSPs that were
   delegated to it, but the LSP state ownership is retained by the PCC.
   In particular, in addition to specifying values for LSP's attributes,
   an active stateful PCE also decides when to make LSP modifications.

   Retaining LSP state ownership on the PCC allows for:

   o  a PCC to interact with both stateless and stateful PCEs at the
      same time

   o  a stateful PCE to only modify a small subset of LSP parameters,
      i.e., to set only a small subset of the overall LSP state; other
      parameters may be set by the operator, for example, through CLI
      commands

   o  a PCC to revert delegated LSP to an operator-defined default or to
      delegate the LSPs to a different PCE, if the PCC gets disconnected
      from a PCE with currently delegated LSPs

Top      Up      ToC       Page 11 
5.2.  New Messages

   In this document, we define the following new PCEP messages:

   Path Computation State Report (PCRpt):  a PCEP message sent by a PCC
      to a PCE to report the status of one or more LSPs.  Each LSP State
      Report in a PCRpt message MAY contain the actual LSP's path,
      bandwidth, operational and administrative status, etc.  An LSP
      Status Report carried on a PCRpt message is also used in
      delegation or revocation of control of an LSP to/from a PCE.  The
      PCRpt message is described in Section 6.1.

   Path Computation Update Request (PCUpd):  a PCEP message sent by a
      PCE to a PCC to update LSP parameters, on one or more LSPs.  Each
      LSP Update Request on a PCUpd message MUST contain all LSP
      parameters that a PCE wishes to be set for a given LSP.  An LSP
      Update Request carried on a PCUpd message is also used to return
      LSP delegations if at any point PCE no longer desires control of
      an LSP.  The PCUpd message is described in Section 6.2.

   The new functions defined in Section 4 are mapped onto the new
   messages as shown in the following table.

         +----------------------------------------+--------------+
         | Function                               | Message      |
         +----------------------------------------+--------------+
         | Capability Advertisement (E-C,C-E)     | Open         |
         | State Synchronization (C-E)            | PCRpt        |
         | LSP State Report (C-E)                 | PCRpt        |
         | LSP Control Delegation (C-E,E-C)       | PCRpt, PCUpd |
         | LSP Update Request (E-C)               | PCUpd        |
         +----------------------------------------+--------------+

                 Table 1: New Function to Message Mapping

5.3.  Error Reporting

   Error reporting is done using the procedures defined in [RFC5440] and
   reusing the applicable error types and error values of [RFC5440]
   wherever appropriate.  The current document defines new error values
   for several error types to cover failures specific to stateful PCE.

5.4.  Capability Advertisement

   During the PCEP initialization phase, PCEP speakers (PCE or PCC)
   advertise their support of PCEP Stateful PCE extensions.  A PCEP
   speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in
   Section 7.1.1, in the OPEN object to advertise its support for PCEP

Top      Up      ToC       Page 12 
   Stateful PCE extensions.  The STATEFUL-PCE-CAPABILITY TLV includes
   the 'LSP Update' flag that indicates whether the PCEP speaker
   supports LSP parameter updates.

   The presence of the STATEFUL-PCE-CAPABILITY TLV in PCC's OPEN object
   indicates that the PCC is willing to send LSP State Reports whenever
   LSP parameters or operational status changes.

   The presence of the STATEFUL-PCE-CAPABILITY TLV in PCE's OPEN message
   indicates that the PCE is interested in receiving LSP State Reports
   whenever LSP parameters or operational status changes.

   The PCEP extensions for stateful PCEs MUST NOT be used if one or both
   PCEP speakers have not included the STATEFUL-PCE-CAPABILITY TLV in
   their respective OPEN message.  If the PCEP speaker on the PCC
   supports the extensions of this specification but did not advertise
   this capability, then upon receipt of a PCUpd message from the PCE,
   it MUST generate a PCEP Error (PCErr) with Error-type=19 (Invalid
   Operation) and error-value 2 (Attempted LSP Update Request if the
   stateful PCE capability was not advertised)(see Section 8.5), and it
   SHOULD terminate the PCEP session.  If the PCEP Speaker on the PCE
   supports the extensions of this specification but did not advertise
   this capability, then upon receipt of a PCRpt message from the PCC,
   it MUST generate a PCErr with Error-type=19 (Invalid Operation) and
   error-value 5 (Attempted LSP State Report if stateful PCE capability
   was not advertised) (see Section 8.5), and it SHOULD terminate the
   PCEP session.

   LSP delegation and LSP Update operations defined in this document may
   only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag
   in the STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)'.
   If this is not the case and LSP delegation or LSP Update operations
   are attempted, then a PCErr with Error-type=19 (Invalid Operation)
   and error-value 1 (Attempted LSP Update Request for a non-delegated
   LSP) (see Section 8.5) MUST be generated.  Note that, even if one of
   the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its
   STATEFUL-PCE-CAPABILITY TLV, a PCE can still operate as a passive
   stateful PCE by accepting LSP State Reports from the PCC in order to
   build and maintain an up-to-date view of the state of the PCC's LSPs.

5.5.  IGP Extensions for Stateful PCE Capabilities Advertisement

   When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
   are either LSRs or servers also participating in the IGP, an
   effective mechanism for PCE discovery within an IGP routing domain
   consists of utilizing IGP advertisements.  Extensions for the
   advertisement of PCE Discovery Information are defined for OSPF and
   for IS-IS in [RFC5088] and [RFC5089], respectively.

Top      Up      ToC       Page 13 
   The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional
   sub-TLV used to advertise PCE capabilities.  It MAY be present within
   the PCE Discovery (PCED) sub-TLV carried by OSPF or IS-IS.  [RFC5088]
   and [RFC5089] provide the description and processing rules for this
   sub-TLV when carried within OSPF and IS-IS, respectively.

   The format of the PCE-CAP-FLAGS sub-TLV is included below for easy
   reference:

   Type:  5

   Length:  Multiple of 4.

   Value:  This contains an array of units of 32-bit flags with the most
      significant bit as 0.  Each bit represents one PCE capability.

   PCE capability bits are defined in [RFC5088].  This document defines
   new capability bits for the stateful PCE as follows:

                  Bit    Capability
                  ---    -------------------------------
                  11     Active stateful PCE capability
                  12     Passive stateful PCE capability

   Note that while active and passive stateful PCE capabilities may be
   advertised during discovery, PCEP speakers that wish to use stateful
   PCEP MUST negotiate stateful PCEP capabilities during PCEP session
   setup, as specified in the current document.  A PCC MAY initiate
   stateful PCEP capability negotiation at PCEP session setup even if it
   did not receive any IGP PCE capability advertisements.

5.6.  State Synchronization

   The purpose of State Synchronization is to provide a
   checkpoint-in-time state replica of a PCC's LSP state in a PCE.
   State Synchronization is performed immediately after the
   initialization phase [RFC5440].

   During State Synchronization, a PCC first takes a snapshot of the
   state of its LSPs, then it sends the snapshot to a PCE in a sequence
   of LSP State Reports.  Each LSP State Report sent during State
   Synchronization has the SYNC flag in the LSP object set to 1.  The
   set of LSPs for which state is synchronized with a PCE is determined
   by the PCC's local configuration (see more details in Section 9.1)
   and MAY also be determined by stateful PCEP capabilities defined in
   other documents, such as [RFC8232].

Top      Up      ToC       Page 14 
   The end of the synchronization marker is a PCRpt message with the
   SYNC flag set to 0 for an LSP object with PLSP-ID equal to the
   reserved value 0 (see Section 7.3).  In this case, the LSP object
   SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the
   LSP-IDENTIFIERS TLV with the special value of all zeroes.  The PCRpt
   message MUST include an empty Explicit Route Object (ERO) as its
   intended path and SHOULD NOT include the optional Record Route Object
   (RRO) for its actual path.  If the PCC has no state to synchronize,
   it SHOULD only send the end of the synchronization marker.

   A PCE SHOULD NOT send PCUpd messages to a PCC before State
   Synchronization is complete.  A PCC SHOULD NOT send PCReq messages to
   a PCE before State Synchronization is complete.  This is to allow the
   PCE to get the best possible view of the network before it starts
   computing new paths.

   Either the PCE or the PCC MAY terminate the session using the PCEP
   session termination procedures during the synchronization phase.  If
   the session is terminated, the PCE MUST clean up the state it
   received from this PCC.  The session re-establishment MUST be
   re-attempted per the procedures defined in [RFC5440], including use
   of a backoff timer.

   If the PCC encounters a problem that prevents it from completing the
   LSP State Synchronization, it MUST send a PCErr message with
   error-type 20 (LSP State Synchronization Error) and error-value 5
   (indicating an internal PCC error) to the PCE and terminate the
   session.

   The PCE does not send positive acknowledgments for properly received
   synchronization messages.  It MUST respond with a PCErr message with
   Error-type=20 (LSP State Synchronization Error) and error-value 1
   (indicating an error in processing the PCRpt) (see Section 8.5) if it
   encounters a problem with the LSP State Report it received from the
   PCC, and it MUST terminate the session.

   A PCE implementing a limit on the resources a single PCC can occupy
   MUST send a PCEP Notify (PCNtf) message with Notification Type 4
   (Stateful PCE resource limit exceeded) and Notification Value 1
   (Entering resource limit exceeded state) in response to the PCRpt
   message triggering this condition in the synchronization phase and
   MUST terminate the session.

   The successful State Synchronization sequence is shown in Figure 1.

Top      Up      ToC       Page 15 
                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |-----PCRpt, SYNC=1----->| (Sync start)
                       |                        |
                       |-----PCRpt, SYNC=1----->|
                       |            .           |
                       |            .           |
                       |            .           |
                       |-----PCRpt, SYNC=1----->|
                       |            .           |
                       |            .           |
                       |            .           |
                       |                        |
                       |-----PCRpt, SYNC=0----->| (End of sync marker
                       |                        |  LSP State Report
                       |                        |  for PLSP-ID=0)
                       |                        | (Sync done)


                Figure 1: Successful State Synchronization

   The sequence where the PCE fails during the State Synchronization
   phase is shown in Figure 2.

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |-----PCRpt, SYNC=1----->|
                       |                        |
                       |-----PCRpt, SYNC=1----->|
                       |            .           |
                       |            .           |
                       |            .           |
                       |-----PCRpt, SYNC=1----->|
                       |                        |
                       |-PCRpt, SYNC=1          |
                       |         \    ,-PCErr   |
                       |          \  /          |
                       |           \/           |
                       |           /\           |
                       |          /   `-------->| (Ignored)
                       |<--------`              |

           Figure 2: Failed State Synchronization (PCE Failure)

Top      Up      ToC       Page 16 
   The sequence where the PCC fails during the State Synchronization
   phase is shown in Figure 3.

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |-----PCRpt, SYNC=1----->|
                       |                        |
                       |-----PCRpt, SYNC=1----->|
                       |            .           |
                       |            .           |
                       |            .           |
                       |-------- PCErr=? ------>|
                       |                        |

           Figure 3: Failed State Synchronization (PCC Failure)

   Optimizations to the synchronization procedures and alternate
   mechanisms of providing the synchronization function are outside the
   scope of this document and are discussed elsewhere (see [RFC8232]).

5.7.  LSP Delegation

   If during capability advertisement both the PCE and the PCC have
   indicated that they support LSP Update, then the PCC may choose to
   grant the PCE a temporary right to update (a subset of) LSP
   attributes on one or more LSPs.  This is called "LSP delegation", and
   it MAY be performed at any time after the initialization phase,
   including during the State Synchronization phase.

   A PCE MAY return an LSP delegation at any time if it no longer wishes
   to update the LSP's state.  A PCC MAY revoke an LSP delegation at any
   time.  Delegation, Revocation, and Return are done individually for
   each LSP.

   In the event of a delegation being rejected or returned by a PCE, the
   PCC SHOULD react based on local policy.  It can, for example, either
   retry delegating to the same PCE using an exponentially increasing
   timer or delegate to an alternate PCE.

5.7.1.  Delegating an LSP

   A PCC delegates an LSP to a PCE by setting the Delegate flag in the
   LSP State Report to 1.  If the PCE does not accept the LSP
   delegation, it MUST immediately respond with an empty LSP Update
   Request that has the Delegate flag set to 0.  If the PCE accepts the
   LSP delegation, it MUST set the Delegate flag to 1 when it sends an

Top      Up      ToC       Page 17 
   LSP Update Request for the delegated LSP (note that this may occur at
   a later time).  The PCE MAY also immediately acknowledge a delegation
   by sending an empty LSP Update Request that has the Delegate flag set
   to 1.

   The delegation sequence is shown in Figure 4.

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |---PCRpt, Delegate=1--->| LSP delegated
                       |                        |
                       |---PCRpt, Delegate=1--->|
                       |            .           |
                       |            .           |
                       |            .           |
                       |<--(PCUpd,Delegate=1)---| Delegation confirmed
                       |                        |
                       |---PCRpt, Delegate=1--->|
                       |                        |

                        Figure 4: Delegating an LSP

   Note that for an LSP to remain delegated to a PCE, the PCC MUST set
   the Delegate flag to 1 on each LSP State Report sent to the PCE.

5.7.2.  Revoking a Delegation

5.7.2.1.  Explicit Revocation

   When a PCC decides that a PCE is no longer permitted to modify an
   LSP, it revokes that LSP's delegation to the PCE.  A PCC may revoke
   an LSP delegation at any time during the LSP's lifetime.  A PCC
   revoking an LSP delegation MAY immediately remove the updated
   parameters provided by the PCE and revert to the operator-defined
   parameters, but to avoid traffic loss, it SHOULD do so in a
   make-before-break fashion.  If the PCC has received but not yet acted
   on PCUpd messages from the PCE for the LSP whose delegation is being
   revoked, then it SHOULD ignore these PCUpd messages when processing
   the message queue.  All effects of all messages for which processing
   started before the revocation took place MUST be allowed to complete,
   and the result MUST be given the same treatment as any LSP that had
   been previously delegated to the PCE (e.g., the state MAY immediately
   revert to the operator-defined parameters).

Top      Up      ToC       Page 18 
   If a PCEP session with the PCE to which the LSP is delegated exists
   in the UP state during the revocation, the PCC MUST notify that PCE
   by sending an LSP State Report with the Delegate flag set to 0, as
   shown in Figure 5.

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
                       |---PCRpt, Delegate=1--->|
                       |                        |
                       |<--(PCUpd,Delegate=1)---| Delegation confirmed
                       |            .           |
                       |            .           |
                       |            .           |
                       |---PCRpt, Delegate=0--->| PCC revokes delegation
                       |                        |

                      Figure 5: Revoking a Delegation

   After an LSP delegation has been revoked, a PCE can no longer update
   an LSP's parameters; an attempt to update parameters of a
   non-delegated LSP will result in the PCC sending a PCErr message with
   Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP
   Update Request for a non-delegated LSP) (see Section 8.5).

5.7.2.2.  Revocation on Redelegation Timeout

   When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC
   MUST wait the time interval specified in the 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 re-established 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, and the PCC does not succeed in redelegating its LSPs,
   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 MUST flush any LSP state set by
   the PCE upon expiration of the State Timeout Interval and revert to
   operator-defined default parameters or behaviors.  This operation
   SHOULD be done in a make-before-break fashion.

Top      Up      ToC       Page 19 
   The State Timeout Interval MUST be greater than or equal to the
   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.7.3.  Returning a Delegation

   In order to keep a delegation, a PCE MUST set the Delegate flag to 1
   on each LSP Update Request sent to the PCC.  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 that has the
   Delegate flag set to 0.  If a PCC receives an LSP Update Request with
   the Delegate flag set to 0 (whether the LSP Update Request is empty
   or not), it MUST treat this as a delegation return.

                     +-+-+                    +-+-+
                     |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 timeout 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 and revert to operator-defined default
   parameters or behaviors.

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

Top      Up      ToC       Page 20 
   redundant PCE all LSPs that had been previously delegated to the
   failed PCE.  Assuming that the State Timeout Interval had been
   configured to be greater than the Redelegation Timeout Interval (as
   MANDATORY), and assuming that the primary and redundant PCEs take
   similar decisions, this delegation change will not cause any changes
   to the LSP parameters.

5.7.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 behavior 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 removed and the LSP
   reverts to operator-defined parameters, which may cause a 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
   indefinitely.  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 that the PCC can redelegate the LSP to the
   standby PCE within the State Timeout Interval, and assuming the
   standby PCE takes similar decisions as the failed PCE, the LSP state
   will be kept intact.

Top      Up      ToC       Page 21 
5.8.  LSP Operations

5.8.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 state change |                        |
      event            |                        |
                       |                        |
   5) LSP State Report |----- PCRpt message --->|
      sent to all      |            .           |
      stateful PCEs    |            .           |
                       |            .           |
   6) Repeat for each  |----- PCRpt message --->|
      LSP state 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 of the 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).  The PCReq message MAY contain the LSP object to
   identify the LSP for which the path computation is requested.

   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 set up the LSPs.  For each LSP,
   it MAY send an LSP State Report carried on a PCRpt message to the
   PCE, indicating that the LSP's status is "Going-up".

Top      Up      ToC       Page 22 
   Once an LSP is up or active, the PCC MUST send an LSP State Report
   carried on a PCRpt message to the PCE, indicating that the LSP's
   status is 'Up' or 'Active', respectively.  If the LSP could not be
   set up, the PCC MUST send 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 change from 'Going-up' to 'Up'
   (or 'Down') before the PCC has had a chance to send an LSP State
   Report indicating that the status is 'Going-up'.  In such cases, the
   PCC MAY choose to only send the PCRpt indicating the latest status
   ('Active', 'Up', or 'Down').

   Upon receiving a negative reply from a PCE, a PCC MAY resend a
   modified request or take any other appropriate action.  For each
   requested LSP, it SHOULD also send 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 MUST send 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 model for stateful PCEs is described in
   [RFC4655], Section 6.8.

5.8.2.  Switching from Passive Stateful to Active Stateful

   This section deals with the scenario of an LSP transitioning from a
   passive stateful to an active stateful mode of operation.  When the
   LSP has no working path, prior to delegating the LSP, the PCC MUST
   first use the procedure defined in Section 5.8.1 to request the
   initial path from the PCE.  This is required because the action of
   delegating the LSP to a PCE using a PCRpt message is not an explicit
   request to the PCE to compute a path for the LSP.  The only explicit
   way for a PCC to request a path from the PCE is to send a PCReq
   message.  The PCRpt message MUST NOT be used by the PCC to attempt to
   request a path from the PCE.

   When the LSP is delegated after its setup, it may be useful for the
   PCC to communicate to the PCE the locally configured intended
   configuration parameters, so that the PCE may reuse them in its
   computations.  Such parameters MAY be acquired through an out-of-band
   channel, or MAY be communicated in the PCRpt message delegating the
   LSPs, by including them as part of the intended-attribute-list as

Top      Up      ToC       Page 23 
   explained in Section 6.1.  An implementation MAY allow policies on
   the PCC to determine the configuration parameters to be sent to the
   PCE.

5.8.3.  Active Stateful PCE LSP Update

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

                       Figure 8: Active Stateful PCE

   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 of the PCC's existing LSPs).  After LSPs have
   been delegated to the PCE, the PCE can modify LSP parameters of
   delegated LSPs.

   To update an LSP, a PCE MUST send the PCC an LSP Update Request using
   a PCUpd message.  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 MUST have a unique identifier,
   the SRP-ID-number, carried in the SRP 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 set up LSPs
   specified in LSP Update Requests carried in the message.  For each
   LSP, it MAY send an LSP State Report carried on a PCRpt message to
   the PCE, indicating that the LSP's status is 'Going-up'.  If the PCC

Top      Up      ToC       Page 24 
   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.5).

   Once an LSP is up, the PCC MUST send 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 MUST send an LSP State Report
   indicating that the LSP is 'Down' and stating the cause of the
   failure.  A PCC MAY compress LSP State Reports to only reflect the
   most up to date state, as discussed in the previous section.

   A PCC MUST send 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 compress the state when processing PCUpd.
   In this case, receipt of a higher SRP-ID-number implicitly
   acknowledges processing all the updates with a lower SRP-ID-number
   for the specific LSP (as per Section 7.2).

   A PCC MUST NOT send to any PCE a path computation request for a
   delegated LSP.  Should the PCC decide it wants to issue a Path
   Computation Request on a delegated LSP, it MUST perform the
   Delegation Revocation procedure first.

5.9.  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 document.

5.10.  PCEP Sessions

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


Next Section