| Internet-Draft | PCEP Recovery Admission | November 2026 |
| Zhao & Zhang | Expires 6 May 2027 | [Page] |
Following a disruptive event, multiple Path Computation Element (PCE)-controlled Label Switched Paths (LSPs) may need to recover over the same limited remaining resources. Individually feasible paths do not necessarily remain feasible when competing recovery updates are activated concurrently.¶
This document proposes PCEP extensions to carry explicit conditional recovery admission decisions, correlate their installation outcomes, and reconcile their admission state after failures or PCEP session loss. Coordination is limited to consistent accounting of shared recovery resources by one active stateful PCE.¶
The extension does not specify path computation algorithms, guarantee end-to-end service performance, or replace local fast protection.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Path Computation Element Communication Protocol (PCEP) [RFC5440] and stateful PCEP [RFC8231] support the computation, reporting, and update of traffic-engineered LSPs. PCE-initiated LSPs are specified in [RFC8281]. Existing mechanisms also cover global concurrent optimization [RFC5557], LSP associations [RFC8697], path protection associations [RFC8745], and automatic bandwidth adjustments [RFC8733]. After a correlated failure, several LSPs may require restoration over one constrained set of alternative links.¶
Computing paths in isolation can lead to competing recovery operations whose combined demand exceeds the remaining capacity. The active stateful PCE can apply a local admission policy and sequence updates, but existing PCEP messages do not explicitly convey the lifecycle of a recovery admission: which traffic demand was admitted, which action consumed a pending share of a recovery resource budget, and whether that admission remains active after a session reset or an uncertain update outcome. This specification proposes a limited extension to existing stateful PCEP operations.¶
The active PCE makes the admission decision and serializes resource accounting; the PCC validates and reports the decision associated with an LSP operation.¶
A separate persistent admission state report supports re-synchronization. No new PCEP message type or end-to-end reservation signaling protocol is defined. A single active stateful PCE can maintain a recovery resource ledger, serialize competing updates, and use existing PCUpd, PCInitiate, and PCRpt messages without this extension. Such local computation and bookkeeping do not, by themselves, require PCEP standardization. The motivation for this extension is narrower: the PCC needs to understand and validate an explicitly conditional admission, and the admission context may need to survive loss of the PCE's volatile state and be reconstructed from interoperable LSP reports.¶
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals.¶
Consider LSP-A and LSP-B whose primary paths fail at the same time. Both could use an alternative path with 10 Gbit/s remaining capacity.¶
Their recovery policy provides the following demand:¶
| LSP | Normal Demand | Minimum Demand | Candidate Admission |
|---|---|---|---|
| LSP-A | 6 Gbit/s | 6 Gbit/s | 6 Gbit/s |
| LSP-B | 6 Gbit/s | 4 Gbit/s | 4 Gbit/s |
The combined normal demand (12 Gbit/s) exceeds the available 10 Gbit/s. If the service policy for LSP-B explicitly permits a degraded 4 Gbit/s operation, and the PCC can honor the corresponding bandwidth and traffic-control parameters, the PCE may admit A at 6 Gbit/s and B at 4 Gbit/s. Otherwise the PCE does not admit B using this candidate path.¶
A path computation result alone does not indicate whether the two operations have been admitted against the same current resource budget. Nor does an LSP Up report, by itself, prove that a previous admission is no longer consuming resources after another operation.¶
In a deployment with one active stateful PCE, the PCE can evaluate shared recovery resources, decide which LSPs to update, sequence their PCUpd or PCInitiate operations, and retain pending resource claims in a local database. Existing PCEP procedures already support reporting the resulting LSP state and synchronizing that state after a session restart RFC8231 [RFC8281].¶
If the admission decision is entirely internal to the PCE, the PCC only needs to install an ordinary path and bandwidth request, and the PCE can reconstruct all necessary resource use from existing LSP and traffic-engineering state, no new PCEP extension is required.¶
The algorithms and internal reservation ledger remain implementation-specific.¶
A PCEP extension becomes relevant only when the admission decision itself must be interpreted or retained by both peers, rather than remaining private state of the PCE.¶
This draft targets three specific behaviors:¶
Explicit conditional-demand semantics: The PCE may authorize an LSP at an Admitted Demand below its Normal Demand, provided that this still meets the Minimum Demand. The PCC needs to distinguish this intentional degraded-service admission from an ordinary bandwidth change and determine whether its local policy and traffic-control capabilities can honor it. An ordinary BANDWIDTH object conveys the requested LSP bandwidth but does not, by itself, convey the Normal Demand, Minimum Demand, or the fact that the operation is a conditional recovery admission.¶
Peer-visible admission outcome: The PCE needs to know whether the PCC applied the particular conditional admission, not merely whether an LSP with some operational attributes exists. Existing SRP correlation and PCRpt state reporting are reused for the LSP operation; the proposed admission information binds its result to the same recovery decision. This distinction matters when a PCC rejects a reduction required by the PCE's recovery plan.¶
Reconstruction of admission-specific context: Stateful PCEP synchronization reports current LSP state. It does not necessarily preserve why an LSP was admitted at reduced demand, which admission generation authorized it, or whether an earlier recovery operation is still relevant to the recovery accounting policy. The proposed admission-state information allows a supporting PCC to report this context after loss of the PCE's volatile ledger or a session reset. The PCE MUST still reconcile actual LSP and resource state; an admission record is not evidence of reserved capacity.¶
These requirements are conditional. A deployment in which the PCE already has durable admission state, existing LSP reports are sufficient to reconstruct occupied resources, and no PCC interpretation of degraded-service admission is required can continue to use ordinary stateful PCEP without this extension. The extension therefore standardizes admission intent, PCC validation, and admission-context reporting.¶
It does not standardize the PCE's capacity-accounting algorithm, the order in which candidate LSPs are selected, or a distributed lock for shared network resources. One active PCE remains the authority for local admission serialization in the initial deployment model.¶
Suppose LSP-B has a Normal Demand of 6 Gbit/s and an operator-authorized Minimum Demand of 4 Gbit/s. A PCE computes a recovery path and sends an ordinary PCUpd requesting 4 Gbit/s. Without additional recovery-admission information, the PCC can process the requested bandwidth, but it cannot determine from that request alone whether 4 Gbit/s represents normal operation or a policy-authorized degraded-service recovery. Nor can a restarted PCE always reconstruct that distinction from the installed bandwidth alone.¶
With the proposed extension, the PCE signals ND=6, MD=4, and AD=4 Gbit/s with an Admission ID. A supporting PCC checks the conditional admission against its local capability and policy, rejects it if the required reduced operation is not supported, and reports the admission context with the LSP state.¶
This creates an observable difference in inter-vendor behavior; it is not merely a way to expose the PCE's internal accounting. If the PCC does not need to validate the conditional service policy and the PCE can recover the same context using existing mechanisms, this example does not justify deploying the extension.¶
The key interoperability question is whether two independent PCE/PCC implementations can reach the same meaning for an admitted degraded operation and can recover that meaning after session loss.¶
If existing PCEP bandwidth attributes, ordinary LSP synchronization, and externally available policy already meet those requirements in a particular deployment, the extra TLVs have no demonstrated benefit for that deployment and need not be used.¶
For each recovery resource r, the admission authority maintains:¶
U[r]: Residual bandwidth according to a specified resource snapshot, after subtracting allocations represented by that snapshot.¶
H[r]: Incremental capacity claims not yet reflected in U[r]. These include both pending admissions and applied admissions whose resource occupation has not yet been incorporated into the resource snapshot.¶
M[r]: An operator-defined safety margin.¶
D[o,r]: Peak incremental demand on resource r for candidate recovery operation o, accounting for path overlap where relevant.¶
A candidate is admitted only if the admission authority determines that the following holds for every resource on the candidate path:¶
D[o,r] + H[r] + M[r] <= U[r]
¶
The PCE MUST NOT use the same uncommitted residual capacity to admit two competing operations. Before sending a recovery update, it MUST account for the operation's incremental claim on every affected resource. The mechanism used to serialize internal PCE admission decisions is implementation-specific and is not a PCEP interoperability requirement.¶
D[o,r] is incremental: if existing resource consumption is already deducted from U[r], the PCE MUST NOT count that consumption again. Conversely, a new reservation or applied update that has not yet appeared in U[r] remains accounted for in H[r]. When an advertisement or other resource snapshot incorporates an applied operation, the PCE updates the baseline and its outstanding claims without temporarily releasing that capacity or counting it twice.¶
During make-before-break, resources consumed by both old and new paths may temporarily coexist. The admission calculation MUST cover the peak overlapping consumption. It cannot assume that old allocations were released simply because an update was issued.¶
The available capacity must be assessed with a consistent resource and reservation model, including any applicable reservation priority and existing local protection traffic. A positive admission depends on the PCE's current resource view; it is not a guarantee of data-plane congestion freedom. If the relevant capacity information is missing, stale beyond locally acceptable limits, or inconsistent, the PCE MUST NOT claim a positive recovery admission for those resources.¶
This section specifies the consistency requirements of an admission decision, not a path computation algorithm, network-wide reservation protocol, or mandatory internal PCE database design.¶
For each admitted operation the following conditions apply:¶
0 < MD <= AD <= ND, unless the policy explicitly defines an operation without degraded-service support; then AD = ND.¶
An Admission ID identifies exactly one candidate LSP operation and is not reused for another path or admitted demand in the same epoch.¶
Only one recovery-admission operation for a particular LSP is outstanding at a time. This avoids ambiguity from per-LSP PCUpd request compression or supersession.¶
A confirmed or uncertain admission continues to consume the authority's accounting budget until its resource use is known to have ended or has been accounted for elsewhere.¶
No admission record implies that all traffic belonging to a service is guaranteed to comply with the specified demand.¶
Within an epoch, an Admission ID is bound to one LSP and one recovery operation, including its intended path and bandwidth parameters and the ND/MD/AD tuple. It MUST NOT be reused for a materially different operation.¶
The PCE tracks the following conceptual admission states. These states describe admission accounting and are not new PCEP LSP operational states.¶
CANDIDATE
|
+-- infeasible ----------------> NOT ADMITTED
|
+-- admitted and accounted ----> PENDING
|
+---------------+----------------+
| | |
installed/applicable rejected outcome unknown
| | |
v v v
ACTIVE FAILED UNCERTAIN
| | |
confirmed removal confirmed no reconciliation
| resource use |
v v +----+-----+
RELEASED RELEASED | |
ACTIVE RELEASED
ACTIVE indicates that the corresponding LSP operation is reported as installed and the admitted demand remains accounted for. This does not prove that service performance objectives have been met. FAILED does not automatically mean that all resources were released: an operation with ambiguous residual allocation MUST be treated as UNCERTAIN until reconciled.¶
A PCE MUST NOT free an ACTIVE or UNCERTAIN claim merely because a PCEP session is lost, the admission epoch changes, or a response timer expires. A claim may become RELEASED only after its resource occupation has been confirmed absent or has been reconciled into the current baseline resource state as appropriate. A reconciling PCE must distinguish removing an outstanding hold from H[r] from releasing the resource allocated to the LSP.¶
This extension uses the following existing PCEP messages:¶
| Message | Direction | Function under this specification |
|---|---|---|
| Open | Both peers | Negotiate recovery-admission capability and PCE epoch |
| PCUpd | PCE to PCC | Apply an admitted update to a delegated LSP |
| PCInitiate | PCE to PCC | Instantiate an admitted PCE-initiated LSP |
| PCRpt | PCC to PCE | Report operation result and current admission-bearing LSP state |
| PCErr | PCC to PCE | Reject malformed, stale, or locally unacceptable admission |
The PCUpd and PCInitiate object grammars in [RFC8231] and [RFC8281] are unchanged. The SRP object identifies an individual update operation using the existing SRP-ID-number. The admission identity defined here has a separate lifetime and MUST NOT be confused with the SRP-ID-number, which is scoped to a PCEP session. The initial -00 encoding proposals below are provisional.¶
The TLV types are unassigned (TBA) and require PCE Working Group review and IANA allocation. The proposed lengths specify the wire format; they are not claims that any allocated value exists.¶
A PCEP speaker advertises support with a RECOVERY-ADMISSION-CAPABILITY TLV in the OPEN object.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Epoch (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Flags (32 bits): Reserved. Set to zero on transmission and ignored on receipt.¶
Recovery Epoch (64 bits): A PCE configured as the admission authority supplies a non-zero epoch. A PCC acting only as the receiver of admitted operations sets this field to zero.¶
Both PCEP speakers MUST advertise the capability before RECOVERY-ADMISSION information is used. The relevant stateful PCE capabilities defined by [RFC8231] and, if applicable, [RFC8281] also need to be negotiated. The authority MUST generate a new unpredictable or durably monotonic epoch after a restart or loss of admission-accounting state. The epoch advertised in OPEN remains unchanged on that session.¶
The PCC binds admitted operations to the negotiated epoch and MUST reject a new operation carrying another epoch.¶
A change of recovery epoch does not remove old LSPs or invalidate their forwarding state. Their admission records are reconciled before their occupied capacity can be reassigned.¶
This specification does not support epoch changes within an established PCEP session. If the admission authority loses its admission ledger while the PCEP session remains up, the PCE MUST treat all prior recovery admission state as UNCERTAIN and MUST NOT issue new recovery admissions until the session is reset and a new epoch is negotiated.¶
The RECOVERY-ADMISSION TLV (Type = TBA, Length = 44) is carried inside the SRP object of PCUpd or PCInitiate. It can also be included in the SRP object of the PCRpt that reports the corresponding operation. The 44-byte value has the following structure:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 1 | Disposition | Flags (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recovery Epoch (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admission ID (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Normal Demand (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Demand (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admitted Demand (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: Initially 1. Other versions are unsupported.¶
Disposition: 1=ADMIT (PCE operation), 2=APPLIED (PCC response), 3=NOT-APPLIED (PCC response), 4=IN-PROGRESS (optional interim PCC response).¶
Flags: Bit 0, D, indicates that the admitted demand is below the normal demand. Other bits are reserved.¶
Recovery Epoch / Admission ID: Together identify the authorized operation independently of SRP-ID-number.¶
ND / MD / AD: Unsigned 64-bit integers in bits per second. MD and AD MUST be non-zero, with MD <= AD <= ND.¶
An ADMIT TLV with the D flag set MUST have AD < ND. An ADMIT TLV without D MUST have AD = ND. A PCC MUST reject inconsistent demand and flag values. A sending PCE MUST NOT include more than one RECOVERY-ADMISSION TLV for the same LSP operation.¶
A PCC receiving an admitted operation MUST verify the epoch, uniqueness, demand consistency, supported version, and local policy before applying any resulting LSP change. The existing BANDWIDTH and path objects retain their normal PCEP meaning. AD is an upper bound used in the recovery admission ledger and MUST NOT be interpreted as an independently established data-plane reservation.¶
When the operation uses an RSVP-TE bandwidth reservation, the PCE MUST request path bandwidth consistent with the admitted amount; the PCC MUST reject an incompatible combination. If a degradation (AD < ND) requires ingress shaping, traffic admission control, or other local service enforcement not available at the PCC, the PCC MUST reject the admission rather than report success.¶
A PCRpt carrying the SRP-ID-number that correlates to the admitted operation MUST include this TLV with the appropriate APPLIED, NOT-APPLIED, or IN-PROGRESS disposition.¶
As permitted by [RFC8231], subsequent PCRpt reports for the same operation may carry an SRP-ID-number of zero. The PCE therefore uses the RECOVERY-ADMISSION-STATE TLV in the LSP object to determine the later installed admission state.¶
A PCErr is used for validation errors that prevent applying the operation; its SRP-ID-number enables correlation under existing stateful PCEP procedures. A PCRpt APPLIED disposition asserts only that the specified LSP operation was accepted and its requested path state was installed as reported. It does not assert that user traffic was measured at the admitted rate or that the service achieved its SLA.¶
An SRP object is tied to a particular update. After a session restart, unsolicited PCRpt synchronization reports may not contain that original SRP-ID-number. For this reason a separate RECOVERY-ADMISSION-STATE TLV is proposed for the LSP object in PCRpt messages. The proposed Length = 28 value is:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 1 | State | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recovery Epoch (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admission ID (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admitted Demand (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The State field is 1=ACTIVE, 2=INSTALLING, or 3=UNKNOWN. This TLV describes the admission context associated with the currently reported LSP state. It does not replace the LSP operational status in [RFC8231].¶
A supporting PCC MUST include this TLV in PCRpt LSP state reports for an LSP that still has an associated recovery admission, including reports sent during state synchronization.¶
When an earlier recovery admission no longer describes the installed LSP state, the PCC MUST update or remove its admission context. For PCE-initiated instantiation, the PCE initially uses the symbolic path name and SRP-ID-number to correlate the operation; the PCC-assigned PLSP-ID is used after establishment in accordance with [RFC8281]. A synchronization report MAY legitimately contain an admission context from a previous Recovery Epoch when the LSP has continued forwarding across a PCE restart. The PCE MUST distinguish reporting such retained state from accepting a new operation under an obsolete epoch.¶
The previous epoch is therefore valid as historical state information, but not as authorization for a new PCUpd or PCInitiate. If the PCC retained the LSP but cannot recover its former admission context, it MUST NOT invent an Admission ID or claim that admission state is known. The PCE then applies conservative resource-state reconciliation.¶
Absence of an expected admission-state TLV following session failure does not by itself prove that its resources were released. In that case, the PCE MUST retain the relevant accounting as UNCERTAIN until the LSP and resource state are reconciled.¶
If the PCC cannot validate a recovery admission before making the requested LSP change, it sends a PCErr correlated with the SRP-ID-number of the operation, as specified by [RFC8231] and [RFC8281]. The request MUST NOT be reported as APPLIED.¶
This document proposes a Recovery Admission Error error category (Type = TBA) with the following candidate values:¶
| Error Value (TBA) | Condition |
|---|---|
| Unsupported Admission Version | The TLV version or format is not supported. |
| Invalid or Stale Recovery Epoch | The operation epoch does not match the current authority. |
| Inconsistent Admission Parameters | Demand relationships, flags, or path parameters are inconsistent. |
| Admission Policy Not Satisfied | The PCC cannot accept or enforce the requested degraded operation. |
| Admission Identity Conflict | The Admission ID is reused with conflicting operation content. |
The PCE WG needs to determine whether existing PCEP errors can express some of these conditions before allocating a new error category. Existing PCEP errors continue to apply to malformed generic objects, invalid LSP identifiers, or signaling failures.¶
A failure after signaling has begun is different from rejection before processing. The PCC reports actual LSP state, and the PCE retains uncertain resource claims until allocation status is reconciled. Receipt of an error MUST NOT by itself cause the PCE to assume that occupied resources have been freed.¶
Both peers advertise RECOVERY-ADMISSION-CAPABILITY during PCEP session establishment. The extension is disabled unless support is negotiated on both sides. The PCE also advertises its current non-zero Recovery Epoch. Before issuing new recovery admissions after first connect or reconnect, the PCE MUST complete the applicable stateful PCEP LSP synchronization procedures [RFC8231] and reconcile previously active and pending admission records, including those for LSPs retained by a PCC after the previous session failed. The PCE MUST NOT assume that loss of delegation, loss of the PCEP session, or creation of a new epoch caused the old forwarding state to disappear. This specification does not change the orphaned LSP behavior defined in [RFC8231] and [RFC8281].¶
A link failure, resource exhaustion event, or service degradation may cause the PCE to assess recovery candidates. Event detection and selection of candidate LSPs are outside the scope of this protocol extension. The PCE obtains the LSP's Normal Demand and Minimum Demand from authorized policy input. It obtains candidate path and bandwidth constraints from existing path computation inputs. It determines which resources each candidate may occupy and the latest resource state for those resources. If no candidate can meet MD, the PCE does not issue an admitted recovery operation. This draft does not define a new PCEP denial message for a recovery decision made locally by the PCE.¶
Upon receipt of a recovery operation, the PCC:¶
Verifies that recovery-admission support was negotiated and that the specified Recovery Epoch matches the epoch from the authority's OPEN.¶
Checks the Admission ID for duplicate or conflicting use and validates ND, MD, AD, and the D flag.¶
Confirms that the normal PCEP operation is allowed for the delegated or PCE-initiated LSP and that the local bandwidth and degraded-service policy can honor AD.¶
If validation fails before applying the LSP operation, sends correlated PCErr and makes no admission-dependent LSP change.¶
If validation succeeds, processes the PCUpd or PCInitiate according to the ordinary stateful PCEP LSP procedures and sends a correlated PCRpt with the admission result.¶
Includes current RECOVERY-ADMISSION-STATE information in subsequent relevant LSP state reports, including state synchronization.¶
A repeated Admission ID with the same epoch, LSP identity, intended path, bandwidth parameters, and ND/MD/AD tuple refers to the same admission operation, not an additional capacity claim. A repeated Admission ID with different operation contents MUST be rejected. Repetition does not authorize the PCC to disregard the normal SRP-ID-number request and reporting rules of [RFC8231].¶
A correlated PCRpt carrying APPLIED and an LSP state report consistent with the requested operation moves the admission from PENDING to ACTIVE. This acknowledges the reported LSP operation; it does not certify measured service throughput or a recovered SLA. The PCE MUST continue to account for any resource consumption not yet reflected in its baseline resource snapshot.¶
A request-validation failure is reported by PCErr according to the procedures in [RFC8231] and [RFC8281]. If an operation was accepted but subsequently could not be installed, the PCC reports the resulting LSP state through PCRpt. The PCC MUST NOT report a final APPLIED admission if it cannot support the required reduced operation. A negative result does not by itself prove the absence of resource occupation after partial signaling.¶
When an operation fails, the PCE may remove its capacity hold only after it confirms that the operation left no allocations that remain unaccounted for. An ambiguous outcome becomes UNCERTAIN.¶
A PCRpt containing IN-PROGRESS, or a PCRpt whose SRP-ID-number is zero under the existing reporting rules, does not necessarily provide a final admission result. The PCE correlates the current LSP and its admission context using the existing SRP and LSP reporting procedures.¶
The PCE MUST NOT issue a second conditional recovery operation for the same LSP while a previous such operation remains unresolved. Operations for different LSPs may proceed concurrently when the authority has already accounted for all their competing claims.¶
During resource reconciliation, the PCE MUST update its baseline and unreflected claims without creating a double-counting or unaccounted-capacity interval. Reconciliation of internal accounting does not authorize removal of an operating LSP.¶
A timer expiry indicates that the PCE lacks a confirmed result; it does not establish that the recovery operation failed. The PCE moves the admission to UNCERTAIN and keeps its resource claims accounted for. After session re-establishment, the PCE reconstructs the current LSP state using PCRpt synchronization and the RECOVERY-ADMISSION-STATE TLV.¶
It also obtains fresh resource-state information. It then reconciles its old ledger with the observed LSP state before using the remaining capacity for another competing recovery operation. For example:¶
An LSP report with the same Admission ID, epoch, and installed bandwidth supports recovery of the prior ACTIVE admission state.¶
A report showing an LSP still installed but with different or missing admission context does not justify automatic release; the PCE revalidates its resource use.¶
A confirmed LSP removal and corresponding resource reconciliation permit the associated budget to be released.¶
If synchronization cannot determine whether a candidate still occupies resources, its admission remains UNCERTAIN. No conflicting new admission is authorized against that capacity.¶
A new Recovery Epoch makes new admission decisions distinguishable from previous generations; it does not act as a lease expiry or free capacity.¶
Local FRR and existing protection mechanisms operate independently of the recovery-admission process. This extension MUST NOT delay or block those local protection functions. If local protection moves traffic before the PCE acts, the PCE's resource view should account for that traffic. When the amount of displaced traffic is unknown, the PCE cannot claim guaranteed feasibility on the affected resources. Reducing AD from ND is permitted only if the operator's service policy allows degraded operation and the PCC can honor the resulting bandwidth and traffic-control constraints. This extension does not itself configure QoS schedulers, policers, or application-level adaptation. If they are required, their provisioning is outside the scope of this document.¶
The following exchange uses the 10 Gbit/s alternative resource described in the competing-recovery-demand example. Epoch E7 and admission identifiers A1 and B1 are illustrative symbols, not proposed on-wire encodings.¶
PCC-A Active PCE PCC-B | | | |---- Open(epoch=0) ------>|<------ Open(epoch=0) --------| |<--- Open(epoch=E7) ------|------- Open(epoch=E7) ------>| |---- PCRpt: sync -------->|<--------- PCRpt: sync -------| | | | | Correlated failures detected | | | | | Residual = 10 Gbit/s | | Admit A: 6 Gbit/s | | Hold A1 = 6 Gbit/s | | Admit B: 4 Gbit/s | | Hold B1 = 4 Gbit/s | | | | |<---- PCUpd(SRP,A1,AD=6) --|---- PCUpd(SRP,B1,AD=4) ---->| | | | |---- PCRpt(A1,APPLIED) --->|<---- PCRpt(B1,APPLIED) ----| | | | | Reconcile installed LSPs | | with resource snapshot | | | | |==== PCEP connection loss ===| | | | | |<--------- Reconnect / synchronization ------------------| |---- PCRpt(LSP,A1,ACTIVE) -->|<-- PCRpt(LSP,B1,ACTIVE) ---| | | | | Reconstruct admission state |
At the decision point, the PCE accounts for 6 + 4 = 10 Gbit/s before either update is sent. If PCC-B cannot honor the requested reduced demand of 4 Gbit/s, it rejects the operation. The PCE does not use the rejected 4 Gbit/s for another LSP until it confirms that no resources remain allocated by the failed operation.¶
A second example concerns temporary overlap during reoptimization. Suppose an existing LSP occupies 3 Gbit/s on resource R and its new path needs an additional 5 Gbit/s on R before the old path can be removed. The admission calculation must account for the peak total 8 Gbit/s use during the transition.¶
If the baseline residual capacity has already deducted the old 3 Gbit/s allocation, the incremental claim for this candidate is 5 Gbit/s, not 8 Gbit/s. This avoids both premature release and double counting.¶
A single PCE's path selection, admission calculations, capacity holds, and ordering of recovery updates are local implementation matters. This specification does not claim that PCEP needs new objects to perform those functions. The proposed protocol additions are justified only by the information that crosses the PCE/PCC boundary:¶
| Local PCE function (no extension needed) | Proposed peer-visible behavior |
|---|---|
| Compute recovery paths and resource budgets | Convey the admitted ND/MD/AD decision to the PCC |
| Serialize competing recovery candidates | Let the PCC validate and explicitly report that conditional admission |
| Maintain pending allocations in a local ledger | Associate the admitted decision with subsequent LSP reports |
| Rebuild TE utilization from existing LSP reports | Reconcile admission-specific context when that context cannot be inferred from ordinary LSP attributes |
Global Concurrent Optimization (GCO) [RFC5557] allows multiple paths to be jointly computed and includes mechanisms for handling dependencies in their setup or teardown. This specification does not replace GCO and does not require a new path computation algorithm. Its added semantics concern the admission and subsequent accounting of recovery operations that consume limited resources, including those whose application state is uncertain. The generic association mechanism [RFC8697] and Path Protection Association [RFC8745] describe relationships among LSPs. They may help a PCE identify the relevant recovery candidates, but they do not define the per-operation Admission ID, ND/MD/AD semantics, or the restart reconciliation described here.¶
This draft does not define a new LSP Association Type. Auto-bandwidth [RFC8733] can adjust RSVP-TE LSP bandwidth based on traffic demand. This proposal does not redefine bandwidth measurement or adjustment policy. It applies an independent admission-accounting decision when multiple recovery actions compete for a constrained budget. The individual draft on resource-sharing-based path computation [I-D.zhang-pce-resource-sharing] addresses cases where one path can reuse resources of another, particularly where the paths are not simultaneously active. The present proposal addresses the complementary issue of simultaneous recovery demand and the outcome of its admission. The use of shared resources between nonconcurrent LSPs remains outside this document.¶
TBD.¶