RSVP Operation Over IP Tunnels
Extracted elements (26)
End-to-end RSVP control messages forwarded through the tunnel are encapsulated with only the normal tunnel IP header (not UDP), so they traverse the tunnel identically to best-effort data and are correctly decapsulated at Rexit even if Rentry does not yet know whether Rexit supports RSVP tunneling.
Rather than supporting both plain IP-in-IP and IP+UDP encapsulations for reserved packets, the design requires all reserved-packet tunneling to use IP+UDP to eliminate special-case handling. This simplifies implementations at the cost of minor extra overhead.
RSVP is applied recursively over the tunnel: Rentry acts as a PATH message source and Rexit as a RESV source for a tunnel-level session that parallels each end-to-end session. This lets the tunnel appear as a single logical RSVP-controllable link to the wider network.
Three binding mechanisms were considered for associating end-to-end sessions with tunnel sessions. Option 2—a new SESSION_ASSOC object attached to end-to-end PATH messages—was chosen over a new RSVP message type (Option 1) and UDP-encapsulating PATH messages (Option 3) because it is simpler and allows Rexit to pass on end-to-end PATHs transparently if it does not support tunneling.
Whether to support type 3 (dynamic per-flow) tunnels is explicitly left as a local policy decision; the protocol design supports both type 2 (aggregate) and type 3 tunnels, and a single tunnel may combine both behaviors for different end-to-end sessions simultaneously.
For IPSEC ESP tunnel-mode tunnels, the tunnel session uses GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC objects as defined in RFC 2207; data packets are not UDP-encapsulated because the SPI value can be used by intermediate nodes for classification. User-oriented keying between Rentry and Rexit is required to assign different SPIs to reserved vs. best-effort packets.
If Rentry does not support RSVP tunneling, Rexit will have no PATH state for the tunnel and simply sets the global break bit in the decapsulated end-to-end PATH message and forwards it, ensuring correct non-RSVP link signaling for unupgraded equipment.
All tunnel RSVP sessions between the same Rentry–Rexit pair use the same source IP, destination IP, and destination UDP port; individual sessions are distinguished solely by the source UDP port chosen by Rentry. The destination UDP port for tunnel sessions is IANA-assigned port 363.
Because UDP-encapsulated packets MUST NOT be fragmented, tunnel entry routers must support tunnel MTU discovery as defined in RFC 2003 Section 5.1, or alternatively use the Path MTU Discovery mechanism from RFC 2210.
Data packets requiring resource reservations within a tunnel MUST be encapsulated with an outer IP header and a UDP header; the UDP port numbers distinguish packets of different RSVP sessions so that intermediate routers can apply standard filterspec handling.
Rentry MUST UDP-encapsulate an arriving data packet only if a corresponding tunnel session reservation is actually in place (not merely PATH state); if no reservation exists, the packet is forwarded using the normal IP-in-IP tunnel encapsulation.
The first RESV message of an end-to-end session determines its mapping to a tunnel session; this mapping cannot change for the lifetime of the reservation. Rentry bases the mapping on some or all of the end-to-end PATH contents, the RESV flowspec, and local policy.
The RSVP daemon must be able to learn, via the RSVP/Routing interface, which local interfaces are IP-in-IP tunnels with RSVP-over-tunnel capability; this information may be obtained by querying the network layer directly or via an extended routing protocol interface.
Tunnel endpoints MUST NOT make wildcard reservations over multipoint tunnels. Each tunnel endpoint participates as both a PATH source and an FF or SE RESV source for the shared session, creating a single shared reservation for the entire logical medium.
When a tunnel session PATH message encounters an error, Rentry MUST relay the error to the original end-to-end session source; when a tunnel RESV fails, Rexit MUST forward the error (using the ERROR_SPEC code and value) to the end-to-end RESV originator.
A 'hard pipe' tunnel uses a fixed tunnel reservation that is never adjusted regardless of changing end-to-end sessions; a 'soft pipe' tunnel dynamically adjusts the tunnel reservation up or down as end-to-end sessions arrive or depart, optionally using hysteresis.
A tunnel may participate in an RSVP-aware network in one of three ways: type 1 (best-effort, no QoS support), type 2 (aggregate reservation configured statically), or type 3 (dynamic per-flow reservations created and torn down as end-to-end sessions come and go).
When multiple end-to-end sessions map to a single tunnel session, Rentry computes an aggregate Tspec (e.g., by summing individual Tspecs as specified in RFC 2211/RFC 2212) for the tunnel PATH; similarly, Rexit computes an aggregate flowspec from the arriving end-to-end RESVs.
IANA is requested to assign a Class number in the 10bbbbbb range (proposed value 128) for the NODE_CHAR object defined in Section 2.3.2. This class encoding means an unrecognized node drops the object silently rather than generating an error.
The introduction of RSVP over tunnels raises no new security issues beyond those of RSVP itself (controlled access to QoS, addressed by RFC 2205) and IP-in-IP tunnels (addressed by RFC 2003 and RFC 2473). Integrity of RSVP messages carrying SESSION_ASSOC and NODE_CHAR objects is protected by the mechanism in RFC 2747.
At Rentry, when an end-to-end PATH message arrives: if it refreshes a known session already mapped to a tunnel session, Rentry adds a SESSION_ASSOC object and encapsulates the PATH; if it is a new session not yet mapped, Rentry creates Path state and encapsulates without SESSION_ASSOC; if a PATH TEAR arrives and the tunnel session is now empty, Rentry sends a tunnel PATH TEAR.
At Rentry, when an end-to-end RESV arrives: if a NODE_CHAR T-bit is present on the first RESV, Rentry initiates session mapping based on PATH/RESV contents and local policy, either binding to a configured tunnel session, creating a new dynamic tunnel session with an adjusted Tspec, or denying the mapping entirely.
At Rexit, an encapsulated end-to-end PATH message is decapsulated; if it contains no SESSION_ASSOC object, the Non_RSVP flag is set and the global break bit may be raised in the ADSPEC; if SESSION_ASSOC is present, Rexit records the binding, performs ADSPEC composition using the tunnel session's composed parameters as the logical-link characterization, and forwards the PATH downstream.
At Rexit, when an end-to-end RESV arrives: if no bound tunnel session exists the tunnel is treated as a non-RSVP link and NODE_CHAR (T bit set) is appended; if a bound session exists and is a refresh, NODE_CHAR is appended and the RESV is forwarded; if it triggers a flowspec change, a tunnel RESV with RESV_CONFIRM is sent; on hard-pipe overflow an admission-control error (code 01) is returned.
The NODE_CHAR object (proposed class 128, in the 10bbbbbb range, c-type 0, length 8) carries a single T bit indicating that the sending node supports RSVP-over-tunnels; all other bits are reserved. If an RSVP node does not understand this object, it drops it without error.
The SESSION_ASSOC object (class 192, c-type 0) contains a fixed-length header (length, class, c-type), a SESSION object identifying the end-to-end session to be mapped, and a Sender FILTER-SPEC identifying the tunnel session (distinguished primarily by source UDP port).