During normal operation, a PCC that wishes to delegate the control of an LSP sets the Delegate (D) flag (Section 7.3
of RFC 8231
) to 1 in all PCRpt messages pertaining to the LSP. The PCE confirms the delegation by setting the D flag to 1 in all PCUpd messages pertaining to the LSP. The PCC revokes the control of the LSP from the PCE by setting the D flag to 0 in PCRpt messages pertaining to the LSP. If the PCE wishes to relinquish the control of the LSP, it sets the D flag to 0 in all PCUpd messages pertaining to the LSP.
If a PCE wishes to gain control over an LSP, it sends a PCUpd message with the C flag set to 1 in the SRP object. The LSP for which the PCE requests control is identified by the PLSP-ID in the associated LSP object. A PLSP-ID value of 0 indicates that the PCE wants control over all LSPs originating from the PCC. An implementation of this feature needs to make sure to check for the LSP control feature (C flag set to 1) before any check for PLSP-ID (as per [RFC 8231
]). The D flag and C flag are mutually exclusive in a PCUpd message. The PCE MUST NOT
send a control request for the LSP that is already delegated to the PCE, i.e., if the D flag is set in the PCUpd message, then the C flag MUST NOT
be set. If a PCC receives a PCUpd message with the D flag set in the LSP object (i.e., LSP is already delegated) and the C flag is also set (i.e., PCE is making a control request), the PCC MUST
ignore the C flag. A PCC can decide to delegate the control of the LSP at its own discretion. If the PCC grants or denies the control, it sends a PCRpt message with the D flag set to 1 and 0, respectively, in accordance with stateful PCEP [RFC 8231
]. If the PCC does not grant the control, it MAY
choose to not respond, and the PCE MAY
choose to retry requesting the control, preferably using an exponentially increasing timer. Note that, if the PCUpd message with the C flag set is received for a currently non-delegated LSP (for which the PCE is requesting delegation), this MUST NOT
trigger the error handling as specified in [RFC 8231
] (a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP)).
As per [RFC 8231
], a PCC cannot delegate an LSP to more than one PCE at any time. If a PCE requests control of an LSP that has already been delegated by the PCC to another PCE, the PCC MAY
ignore the request or MAY
revoke the delegation to the first PCE before delegating it to the second. This choice is a matter of local policy.
It should be noted that a legacy implementation of PCC that does not support this extension may receive an LSP control request: a PCUpd message with the C flag set and the D flag unset. The legacy implementation would ignore the C flag and trigger the error condition for the D flag, as specified in [RFC 8231
] (i.e., a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP)). Further, in case of a PLSP-ID value of 0, the error condition, as specified in [RFC 8231
], (i.e., a PCErr with Error-type=19 (Invalid Operation) and error-value 3 (Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID)) would be triggered.
] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. It also specifies how a PCE may obtain control over an orphaned LSP that was PCE-initiated. A PCE implementation can apply the mechanism described in this document in conjunction with those in [RFC 8281