RFC 8231
Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
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
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 Mapping5.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
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.
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].
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.
+-+-+ +-+-+ |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)
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
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).
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.
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
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.
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".
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
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
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)
