Aggregation of RSVP for IPv4 and IPv6 Reservations
updated by
- rfc-5350 — IANA Considerations for the IPv4 and IPv6 Router Alert Options
Extracted elements (28)
Aggregate reservation sizing should use predictive policy with hysteresis rather than tracking E2E reservations exactly, to avoid changing the aggregate on every E2E change. The recommended policy takes the larger of a diurnal-cycle a-priori estimate and a 90–99% confidence trend line, updated no more than every few minutes.
DiffServ DSCPs are used for traffic classification within the aggregation region so that classification and scheduling state is per-DSCP class rather than per-aggregate-reservation, making state independent of both E2E reservation count and aggregate reservation count.
Multi-level aggregation is supported by writing the nesting depth (level n+1) into the 2-byte Router Alert option field and using RSVP-E2E-IGNORE for all sub-levels; a deaggregator for level n+1 only processes messages where the router alert carries n+1, forwarding all others unchanged.
Multicast aggregation is limited to aggregating classification and scheduling state only (not full reservation state), because correctly determining per-link resource allocations for heterogeneous multicast receivers would require retaining per-E2E-reservation state, negating the benefit of aggregation.
The mapping decision for which aggregate reservation an E2E flow uses is assigned entirely to the deaggregator, not the aggregator, because the deaggregator is the first node to see the E2E Resv (which contains the receiver-requested IntServ service type). This avoids inconsistent mapping decisions and enables faster aggregate reservation setup.
Tunneling (IP-in-IP, GRE, or MPLS LSPs) is recommended for intra-domain use when equal-cost multipath may exist, because without tunneling the aggregate Path message and E2E data may follow different equal-cost paths, requiring either bandwidth measurement or wasteful over-reservation on every equal-cost path.
For IPv6, Router Alert option values 3–35 are reserved by this specification for aggregation nesting levels 0–31. The IPv6 Router Alert turns the parameter into an option sub-type, so algorithmic use differs from IPv4, requiring IANA-assigned distinct values rather than a single option with a variable field.
Hop-by-hop RSVP integrity (INTEGRITY objects) is preserved for both E2E and aggregate messages: E2E integrity is exchanged directly between aggregator and deaggregator (as logical RSVP neighbors), requiring them to share a secret, while aggregate integrity operates hop-by-hop inside the aggregation region among interior routers.
In inter-domain scenarios, E2E sessions belonging to the same aggregate may enter or leave the aggregation region at different aggregator/deaggregator interfaces due to policy-based routing. The specification recommends summing each such E2E into its appropriate aggregate even if this causes over-reservation.
Aggregate Resv messages SHOULD be reliably delivered using RFC 2961 mechanisms or the CONFIRM object, allowing the deaggregator to determine that requested bandwidth is actually available before committing E2E reservations against it.
Implementations SHOULD NOT provide a general facility for modification of the IP protocol number; only modification for RSVP Path, PathTear, and ResvConf messages is RECOMMENDED to be supported.
Interior routers that receive an RSVP-E2E-IGNORE message destined to another interior interface MUST forward it as a normal IP datagram, storing no reservation state for it.
The aggregating router MUST change the IP Protocol number of E2E Path, PathTear, and ResvConf messages from RSVP (46) to RSVP-E2E-IGNORE (134) when forwarding them onto interior interfaces of the aggregation region.
The aggregating router MUST mark data packets belonging to an established E2E reservation with the correct DSCP as notified by the deaggregator via the DCLASS object, and MUST perform per-E2E-reservation policing (token bucket metering) on those flows. Out-of-compliance packets must be dropped, reshaped, or remarked.
The aggregating router SHOULD always include in the Aggregate Path a SENDER_TSPEC at least as large as the maximum FLOW_SPEC the deaggregator could require, ensuring the deaggregator is not arbitrarily prevented from sizing the aggregate reservation.
The deaggregating router MUST change the E2E Path message's IP Protocol from RSVP-E2E-IGNORE back to RSVP before forwarding it on an exterior interface toward the receiver.
The deaggregating router SHOULD update the ADSPEC of the E2E Path to reflect the aggregation region's QoS impact before forwarding the E2E Path toward the receiver. It should use ADSPEC information from Aggregate Path messages for this update, and may delay forwarding the E2E Path until an Aggregate Path ADSPEC is available.
The deaggregator MAY anticipate current demand and increase aggregate reservation size ahead of actual E2E reservation requirements to minimize delays when new E2E reservations arrive.
When an E2E reservation is removed (via PathTear, ResvTear, timeout, or error), the aggregating and deaggregating routers MUST remove the corresponding FLOWSPEC and SENDER_TSPEC contributions from the aggregate reservation accounting.
A PathErr code NEW-AGGREGATE-NEEDED (RSVP Error Code 26) is defined. It is sent by the deaggregator to the aggregator to signal that a new aggregate Path must be established for a given DSCP, without removing existing path state. The required DSCP is encoded in a DCLASS Object in the error message.
RSVP-E2E-IGNORE is a new IP protocol number (134) used to carry E2E RSVP Path, PathTear, and ResvConf messages through an aggregation region. Interior routers forward these as normal IP datagrams without storing state; deaggregators restore the protocol number to RSVP (46) on exterior egress.
IANA assigned IP protocol number 134 to RSVP-E2E-IGNORE; IPv6 Router Alert option values 3–35 ('Aggregated Reservation Nesting Level') for recording aggregation depth 0–31; RSVP Error Code 26 to NEW-AGGREGATE-NEEDED; and C-Types RSVP-AGGREGATE-IP4 = 9 and RSVP-AGGREGATE-IP6 = 10 for SESSION, SENDER_TEMPLATE, and FILTER_SPEC classes.
Malicious modification of the IP protocol number in an E2E Path message could silently black-hole reservations: interior routers would ignore the message, and the attack might be difficult to detect if the value is restored before reaching the receiver. The loss of an aggregate reservation affects all E2E sessions mapped onto it.
Use of an IPsec Authentication Header is RECOMMENDED to detect malicious modification of the IP protocol number field. Network operators should also use physical security and password protection to prevent routers from being configured to perform malicious protocol number modification.
The E2E reservation lifecycle has three key state transitions: (1) Aggregator receives E2E Path on exterior interface → changes protocol to RSVP-E2E-IGNORE → forwards on interior interface; (2) Deaggregator receives RSVP-E2E-IGNORE on interior → restores RSVP → forwards on exterior; (3) E2E removal (PathTear/ResvTear/timeout) → remove FLOWSPEC and SENDER_TSPEC contributions from aggregate.
The IP4 SESSION object (Class = SESSION, C-Type = RSVP-AGGREGATE-IP4 = 9) contains a 4-byte IPv4 session address followed by a Flags byte and a 6-bit DSCP field in the second word. The DSCP distinguishes multiple aggregate sessions toward the same destination.
The IP6 SESSION object (Class = SESSION, C-Type = RSVP-AGGREGATE-IP6 = 10) contains a 16-byte IPv6 session address followed by a Flags byte and a 6-bit DSCP field. For sessions using paired PHBs (e.g., AF11/AF12), the numerically smallest DSCP (AF11) is used.
The SENDER_TEMPLATE object (C-Types RSVP-AGGREGATE-IP4 = 9 and RSVP-AGGREGATE-IP6 = 10) contains only the IPv4 (4-byte) or IPv6 (16-byte) address of the aggregating router. The FILTER_SPEC object is syntactically identical to SENDER_TEMPLATE.