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
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 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. 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. 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. 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]).
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.
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).
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). +-+-+ +-+-+ |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.
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.
+-+-+ +-+-+ |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. 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. +-+-+ +-+-+ |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. RFC5440].