Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels
Extracted elements (29)
MPLS TE tunnels function as Type 2 tunnels (per RFC 2746 nomenclature) — they can promise aggregate resource availability but not allocate resources to individual flows — making them structurally analogous to aggregate RSVP reservations.
The IP Protocol number in E2E Path messages is left as 'RSVP' rather than being changed to 'RSVP-E2E-IGNORE' (as required by RFC 3175), because the absence of Router Alert already renders the message invisible to transit LSRs without needing a protocol number change.
This document assumes pre-established TE tunnels (rather than dynamically established ones) to simplify aggregation boundary inference and reduce security risks; procedures for dynamic tunnel establishment are left for further study.
Unlike RFC 3175 (RSVP-AGG) where the Deaggregator controls aggregate reservations, RSVP aggregation over TE tunnels assigns primary responsibility to the Aggregator (tunnel Head-end), because MPLS TE tunnels are inherently controlled by the Head-end rather than the Tail-end.
E2E reservations may be per-flow (5-tuple), aggregate RSVP reservations per RFC 3175 or Generic Aggregate RSVP (<source, destination, DSCP>), or IPsec-protected flow reservations per RFC 2207 (<source, destination, SPI>).
The procedures support four IPv4/IPv6 combinations: IPv4 E2E over IPv4 TE, IPv6 E2E over IPv6 TE, IPv6 E2E over IPv4 TE (requires a mechanism such as 6PE), and IPv4 E2E over IPv6 TE (requires an equivalent IPv4-over-IPv6 MPLS mechanism).
This specification differs from RFC 2746 (RSVP over IP Tunnels) in four key ways: it targets MPLS tunnels (requiring PHP handling), the tunnels inherently reserve resources, exactly one aggregate reservation exists per tunnel, and tunnels carry only reserved traffic.
E2E PathTear and ResvConf messages MUST be forwarded by the Aggregator to the Deaggregator exactly like Path messages.
If sufficient bandwidth is available on the final TE tunnel, the Aggregator MUST update its internal accounting of TE tunnel usage and MUST forward the E2E Resv to the corresponding PHOP; if insufficient, it MUST send a ResvError back toward the receiver.
The Aggregator MUST address the E2E Path message directly to the Deaggregator by setting the IP header destination address to the Deaggregator address, and MUST NOT set the Router Alert option.
The Aggregator MUST follow traditional RSVP procedures for processing the E2E Path message and MUST first attempt to map the E2E reservation onto a TE tunnel based on routing information and local policy.
The Aggregator MUST forward the E2E Path message to the Deaggregator using an IF_ID RSVP_HOP object instead of a plain RSVP_HOP object; the data interface identification MUST identify the TE tunnel.
The Aggregator SHOULD use 'make-before-break' procedures as described in RFC 3209 (RSVP-TE) when altering TE tunnel bandwidth to reduce disruptions.
The Deaggregator MUST forward the E2E Path downstream, setting the IP header destination to the Session object's destination address and setting the Router Alert.
The Deaggregator MUST NOT perform the IP TTL vs. RSVP TTL check, as it is informed by the presence of the IF_ID RSVP_HOP object that this check is not applicable.
The Deaggregator MUST support operations in environments where the IF_ID RSVP_HOP validity checks (verifying that the data interface terminates on the Deaggregator and that the PHOP belongs to the correct node) cannot be made.
The IP Protocol number in E2E Path messages MUST be left as 'RSVP' and MUST NOT be changed to 'RSVP-E2E-IGNORE', because the absence of Router Alert already hides the message from transit LSRs.
When an E2E reservation is removed, the Aggregator MUST update its local view of resources available on the corresponding TE tunnel.
When the Aggregator and Deaggregator also act as IPsec Security Gateways, the Aggregator MUST send the E2E Path message into the relevant IPsec tunnel terminating on the Deaggregator.
When the Aggregator receives a data packet belonging to an E2E reservation mapped over a TE tunnel, it MUST encapsulate the packet into that TE tunnel.
A PathErr sent by the Deaggregator in response to a Path message containing an IF_ID RSVP_HOP object SHOULD itself contain an IF_ID RSVP_HOP object.
The Aggregator SHOULD update the ADSPEC inside the E2E Path message before forwarding to reflect the impact of the MPLS TE cloud on achievable QoS; this may be based on configured information, TE topology database, tunnel path, or RSVP-TE signaling data.
The IF_ID RSVP_HOP object replaces the standard RSVP_HOP object in E2E Path messages traversing the aggregation region; its data interface identification field identifies the specific TE tunnel used for aggregation.
Compromise of an aggregate TE tunnel reservation has a multiplying security impact, potentially undermining QoS for all E2E reservations mapped onto it; administrators should limit the domain over which TE tunnels can be established using RSVP message filtering based on MPLS labels.
Dynamic Aggregator resizing of TE tunnels risks resource hogging in the core (preventing other tunnels from being established) and excessive signaling churn; these risks can be mitigated via configuration limits on maximum tunnel size and resizing frequency, and through TE preemption.
RSVP integrity mechanisms from RFC 2747 and RFC 3097 can be applied hop-by-hop to protect E2E RSVP messages transiting the MPLS region, using a pre-shared secret between the Aggregator and Deaggregator, which act as RSVP neighbors for E2E flows.
The implicit binding between data interface and control message interface assumed in standard RSVP is broken when IF_ID RSVP_HOP is used; the security considerations of RFC 4206 (LSP-HIER) regarding this decoupling apply equally here.
Aggregator tunnel-mapping state: on E2E Path arrival the Aggregator makes a tentative mapping to a TE tunnel; on E2E Resv arrival it finalizes the mapping. If the final tunnel differs from the tentative one, the Aggregator MUST resend an E2E Path with the updated IF_ID RSVP_HOP before processing the Resv.
TE tunnel removal triggers Aggregator to act like a conventional RSVP router facing link failure: it attempts to reroute Path messages onto another tunnel if routing and policy permit, or sends PathError messages to the sender; stale Deaggregator reservation state times out without refresh.