A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
updates
- rfc-2205 — Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
Extracted elements (24)
ECN was considered but deemed insufficient for inelastic applications: it signals that an endpoint must reduce transmission but does not convey by how much, forcing multiple retry attempts. This extension provides an explicit bandwidth ceiling so the application can select an appropriate codec in a single step.
Without a bandwidth indication in the ResvErr, a deaggregator re-establishing after full preemption must guess how much bandwidth to request, risking either re-preemption (too much) or unnecessary microflow disruption (too little). The error flow descriptor solves this by communicating the available ceiling directly.
Without this extension, adding one flow to a higher-priority aggregate causes the entire lower-priority aggregate to be preempted, disrupting all individual flows and causing packet loss during re-reservation. Partial preemption takes only the minimum required bandwidth, minimizing disruption.
Backwards compatibility is preserved: a downstream router not supporting this extension processes the ResvErr according to RFC 2205 and understood extensions only, ignoring the partial-preemption semantics. The reservation degrades to standard full-preemption behavior with no protocol violation.
RSVP aggregation with IPsec tunnels (being defined in a separate work-in-progress) is intended to leverage the bandwidth reduction mechanism defined in this specification without modification.
This extension updates RFC 2205 by modifying the behaviors of ResvErr and ResvTear indications. A router that does not support this extension will generate both ResvErr and ResvTear per RFC 2205, effectively performing a full preemption rather than a partial one. The extension does not cause ill effects when mixed with non-supporting routers.
A ResvErr error message generated at the router with the congested interface MUST be able to indicate that a specific reservation (individual or aggregate) is to be reduced in bandwidth.
Bandwidth SHOULD NOT be reduced across multiple reservations simultaneously in reaction to the same reduction event, as doing so may cause more widespread ill effects than necessary.
Retransmitted reduction indications MUST NOT further reduce the bandwidth of a reservation. Any additional reduction MUST be signaled in a new message to avoid compounding errors from duplicate messages.
RSVP implementations MUST have the ability to differentiate one reservation from another. In the case of aggregates, the mechanism MUST distinguish one aggregate from other flows.
The flowspec contained in the ResvErr error flow descriptor SHOULD indicate a bandwidth less than the original reservation request, representing the highest average and peak rates the preempting system can accept in the next RESV message.
The ResvErr error message MUST be able to indicate the new maximum amount of bandwidth available to the existing reservation. This prevents ambiguity about how much the endpoint may request.
This document RECOMMENDS that ResvErr messages be made reliable by implementing the mechanisms in RFC 2961 (RSVP Refresh Overhead Reduction Extensions), since RSVP messages are otherwise unreliable.
When a reservation is only to be reduced (not fully removed), routers compliant with this specification MUST NOT send a ResvTear message upstream. A ResvTear is only generated when the reservation is to be completely removed.
Wherever this specification mentions an individual reservation flow, the same rules of bandwidth reduction and preemption MUST apply to RSVP flows involving IPsec tunnels (per RFC 2207).
A new error subcode ERR_PARTIAL_PREEMPT (ErrSubCode = 102) is defined under Errcode = 2 (Policy Control Failure) in the ERROR_SPEC object to signal partial reservation failure, distinguishing it from full preemption (ErrSubCode = 5, ERR_PREEMPT).
An IPsec-tunneled RSVP flow (per RFC 2207) is treated as an individual reservation flow for purposes of bandwidth reduction and partial preemption. The identification method differs from non-encrypted flows, but the reduction mechanism is identical.
For individual reservation flow reduction, the router sends a ResvErr downstream with the ERR_PARTIAL_PREEMPT subcode. The requesting endpoint uses this to negotiate a lower bandwidth (e.g., via SIP codec renegotiation) and then both endpoints re-issue PATH and RESV with the new lower bandwidth.
In an aggregation reduction scenario, the deaggregator receives a ResvErr with the reduction indication and chooses to: (a) partially fail one or more individual flows with reduced bandwidth, (b) fully preempt a single individual flow via ResvErr+ResvTear, or (c) fully preempt multiple individual flows. In all cases the aggregate Resv bandwidth is lowered accordingly.
The error flow descriptor (defined in RFC 2205 and RFC 2210) is used in partial failure scenarios to carry a flowspec indicating the highest average and peak rates the preempting router can accept in the next RESV message. The deaggregator must reduce its reservation to at or below that value.
The PREEMPTION_PRI object error code value of 1 (admitted flow preempted) is reused for the partial preemption case; no new value is needed in that object.
IANA has assigned ErrSubCode = 102 (ERR_PARTIAL_PREEMPT) under Errcode = 2 (Policy Control Failure) in the ERROR_SPEC object registry for RSVP. This is the sole IANA action defined by this document.
If a compliant router mistakenly transmits a ResvTear upstream simultaneously with the partial-preemption ResvErr, all upstream routers will tear down the entire reservation. This inadvertently frees all bandwidth and may prevent re-establishment, with the most severe impact on large aggregates.
This extension inherits RSVP's existing vulnerability to premature termination of valid reservations by rogue flows that lack authentication. Usage of RSVP authentication mechanisms (RFC 2747, RFC 3097) is encouraged to mitigate this risk.