Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations
Extracted elements (30)
Multiple generic aggregate reservations for the same PHB are needed, for example, to enforce different preemption priorities (per RFC 3181) within the aggregation region, allowing more efficient resource management and sustaining more high-priority reservations during shortage.
PHB-ID (RFC 3140) is used instead of DSCP in the SESSION object to explicitly indicate whether resources belong to a single PHB or a set of PHBs, and to facilitate reservations that span multiple Diffserv domains using different DSCP values for the same PHB.
The VDstPort concept is borrowed from RFC 2207 (RSVP Extensions for IPsec) and Extended VDstPort is borrowed from the Extended Tunnel ID in RFC 3209 (RSVP-TE). Together they allow multiple generic aggregate reservations for the same PHB between the same source-destination pair, which RFC 3175 aggregate reservations cannot support.
Generic aggregate reservations reuse the RSVP-AGGREGATE-IP4 and RSVP-AGGREGATE-IP6 FILTER_SPEC, SENDER_TEMPLATE objects defined in RFC 3175. The present document only specifies the new SESSION and SESSION-OF-INTEREST objects; RFC 3175 procedures apply unless explicitly overridden.
When identifying themselves to real RSVP neighbors (not on the other side of the aggregation region), Aggregators and Deaggregators SHOULD continue using interface-dependent addresses per standard RSVP procedures, ensuring regular RSVP operation at domain boundaries.
A sender or Aggregator wishing to use a shared reservation across senders MUST set Extended vDstPort to all zeros; a sender wishing to narrow scope to the sender-receiver pair SHOULD place its IP address in Extended vDstPort as a globally unique identifier.
Aggregators and Deaggregators SHOULD use interface-independent addresses (e.g., loopback) when communicating their respective identities to each other, to ensure identification is not impacted by interface state changes and to reduce RSVP signaling churn.
If multiple generic aggregate reservations share the same <DestAddress, SrcAddress, PHB-ID> but differ only in VDstPort/Extended VDstPort, a router using a classifier for policing MUST program the policing rate to the sum of reserved rates across all such reservations.
It is RECOMMENDED that implementations only support modification of the IP protocol number for RSVP Path, PathTear, and ResvConf messages. A general facility for modification of the IP protocol number SHOULD NOT be made available.
On receipt of an E2E PathErr with NEW-AGGREGATE-NEEDED containing a SESSION-OF-INTEREST, the Aggregator MUST trigger establishment of a generic aggregate reservation and MUST start sending aggregate Path messages with the GENERIC-AGGREGATE SESSION from the SOI object.
Reserved fields in the SESSION objects MUST be set to 0 on transmit and MUST be ignored on receipt.
RSVP routers supporting generic aggregate IPv4 or IPv6 reservations MUST support the GENERIC-AGGREGATE-IP4 SESSION or GENERIC-AGGREGATE-IP6 SESSION object, respectively. Routers supporting aggregation MUST support GENERIC-AGG-IP4-SOI or GENERIC-AGG-IP6-SOI accordingly.
The Deaggregator MUST include the SESSION-OF-INTEREST object in E2E Resv messages to indicate to the Aggregator which generic aggregate session to map the E2E reservation onto. The Aggregator MUST NOT include the SOI object when forwarding E2E Resv upstream towards the sender.
The PHB-ID field MUST be encoded as specified in Section 2 of RFC 3140 (Per Hop Behavior Identification Codes). This applies to both the IPv4 and IPv6 SESSION objects.
When a Deaggregator determines an aggregate reservation is no longer needed, it MUST send an aggregate ResvTear. On receipt, the Aggregator SHOULD send an aggregate PathTear unless policy instructs otherwise.
When a RESV message contains an RSVP-AGGREGATE FILTER_SPEC, the session MUST be defined using either the RSVP-AGGREGATE or GENERIC-AGGREGATE SESSION object. Failure to meet this MUST be treated as a message formatting error.
When a session is defined using the GENERIC-AGGREGATE SESSION object, only the RSVP-AGG RSVP-AGGREGATE SENDER_TEMPLATE may be used. A violation in a PATH message received by a router MUST be treated as a message formatting error.
When an RSVP Signaled Preemption Priority Policy Element is in the received E2E PathErr, the Aggregator MUST include it in the aggregate Path for the corresponding reservation. The Aggregator MUST use as Source Address the address it uses to identify itself as PHOP when forwarding E2E Path messages.
When requesting a new aggregate reservation, the Deaggregator MUST include a SESSION-OF-INTEREST object containing the GENERIC-AGGREGATE SESSION in the E2E PathErr message with error code NEW-AGGREGATE-NEEDED. The DCLASS object is no longer needed since PHB-ID is in the SESSION.
When the RSVP-AGGREGATE FILTER_SPEC is used with a GENERIC-AGGREGATE SESSION, Diffserv classification MUST rely on the DSCP associated with the PHB-ID of the generic aggregate reservation. Fine-grain classification MUST use the 3-tuple <DestAddress, SrcAddress, DSCP>.
SESSION-OF-INTEREST (SOI) Class (Class=132) carries a copy of a GENERIC-AGGREGATE SESSION object inside E2E RSVP messages. GENERIC-AGG-IP4-SOI (C-Type=1) and GENERIC-AGG-IP6-SOI (C-Type=2) embed the full SESSION object of the aggregate reservation associated with an E2E reservation. It is not a replacement for the SESSION object.
VDstPort is a 16-bit identifier in the SESSION that remains constant over the life of the reservation. Extended vDstPort is a 32-bit (IPv4) or 128-bit (IPv6) identifier; together they allow multiple generic aggregate reservations for the same PHB between the same Aggregator and Deaggregator pair.
IANA assigned a new SESSION-OF-INTEREST class (Class Number 132) with two C-Types: C-Type 1 = GENERIC-AGG-IP4-SOI and C-Type 2 = GENERIC-AGG-IP6-SOI, per RFC 4860. Allocated per BCP 96 (RFC 3936).
IANA assigned two new C-Types under SESSION Class (Class Number 1): C-Type 17 = GENERIC-AGGREGATE-IP4 and C-Type 18 = GENERIC-AGGREGATE-IP6, per RFC 4860.
Compromising a single generic aggregate reservation can cause all aggregated E2E flows to operate unreserved, amplifying the impact of a denial-of-service compared to compromising a single E2E reservation. RSVP Authentication is recommended to mitigate this.
Malicious modification of the IP protocol number in a Path message traversing an aggregation region would cause the message to be ignored by all subsequent RSVP devices, preventing reservations. Implementations SHOULD restrict this facility to Path, PathTear, and ResvConf messages only.
RSVP Authentication does not provide confidentiality or traffic analysis protection. IPsec ESP (RFC 4303) may be used for confidentiality. Generic aggregate reservations carry more traffic analysis risk than E2E reservations since RSVP messages collectively represent a whole set of users.
RSVP Authentication (RFC 2747, RFC 3097) may be used to protect message integrity hop-by-hop, providing node authentication and replay protection against corruption and spoofing. These mechanisms protect both generic aggregate and E2E RSVP messages, including E2E messages transiting the aggregation region.
GENERIC-AGGREGATE-IP4 SESSION object (Class=1, C-Type=17): 16 bytes total. Fields: IPv4 DestAddress (4 bytes), 8-bit Reserved, 8-bit Flags, 16-bit PHB-ID, 16-bit Reserved, 16-bit vDstPort, 32-bit Extended vDstPort.
GENERIC-AGGREGATE-IP6 SESSION object (Class=1, C-Type=18): IPv6 DestAddress (16 bytes), 8-bit Reserved, 8-bit Flags, 16-bit PHB-ID, 16-bit Reserved, 16-bit vDstPort, 128-bit Extended vDstPort.