Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8231

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

Pages: 57
Proposed Standard
Errata
Updated by:  87869353
Part 2 of 4 – Pages 10 to 24
First   Prev   Next

Top   ToC   RFC8231 - Page 10   prevText

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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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   ToC   RFC8231 - 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 page on part 3)

Next Section