Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
updated by
- rfc-2750 — RSVP Extensions for Policy Control
- rfc-3936 — Procedures for Modifying the Resource reSerVation Protocol (RSVP)
- rfc-4495 — A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
- rfc-5946 — Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy
- rfc-6437 — IPv6 Flow Label Specification
- rfc-6780 — RSVP ASSOCIATION Object Extensions
Extracted elements (31)
Both SE and WF styles are included despite SE appearing to subsume WF. A WF reservation allows packet classifiers to wildcard sender address and port with minimal per-flow state; an equivalent SE reservation must explicitly enumerate every sender, resulting in considerably more classifier overhead when sender counts are large.
Reservations downstream of an Admission Control failure are retained rather than deleted for three reasons: the receiver may want partial-path QoS; removing them would impair RSVP's recovery from transient route flaps; and intermittent teardown/restore cycles would degrade user experience.
RSVP makes receivers, not senders, responsible for requesting QoS. This design allows RSVP's reservation overhead to scale logarithmically rather than linearly in the number of receivers and efficiently accommodates heterogeneous receiver requirements in large multicast groups.
RSVP uses a 'soft state' approach: path and reservation state is created and refreshed by periodic Path and Resv messages, and is automatically deleted when no matching refresh arrives before the cleanup timeout (K × refresh period). This supports dynamic group membership and routing changes without explicit distributed synchronization.
RSVP operates correctly through non-RSVP clouds by relying on standard IP routing for Path messages. A Path message traversing a non-RSVP cloud carries the IP address of the last RSVP-capable router before the cloud; the following RSVP node forwards Resv messages directly back to that address, skipping the non-RSVP segment.
RSVP supports both IPv4 and IPv6. IPv6's variable-length Internet-layer headers increase the difficulty and cost of packet classification for QoS; efficient classification of IPv6 data packets could use the Flow Label field, but the details were left for future specification at the time of publication.
IP fragmentation of a data flow for which a resource reservation is desired must be avoided, because intermediate routers must be able to inspect UDP/TCP port fields for packet classification. RFC 2210 specifies a procedure for RSVP applications to compute the minimum MTU across the multicast tree and return it to senders.
Once initiated, a teardown request must be forwarded hop-by-hop without delay. A teardown message deletes the specified state in the node where it is received and the resulting change is propagated immediately to the next node only if there is a net change after merging.
Resv messages must follow exactly the reverse of the path(s) used by data packets, upstream to all sender hosts included in the sender selection, and must finally be delivered to the sender hosts themselves so they can set traffic control parameters for the first hop.
State received through interface I* must never be forwarded out the same interface; state forwarded out I* must be computed using only state that arrived on interfaces different from I*. Additionally, Resv state from outgoing interface Io should be forwarded to incoming interface Ii only if Path messages from Ii are forwarded to Io.
The high-order two bits of the Class-Num field determine what action a node takes when it does not recognize an object class: depending on the bit pattern, a node must ignore the object and continue processing, ignore the entire message, or return an error. This enables forward compatibility with future object definitions.
The IP source address of a Path message must be an address of the sender it describes, and the destination address must be the session DestAddress. This ensures correct routing through non-RSVP clouds where standard IP forwarding is used.
When a stored state update results in modification of state to be forwarded, the corresponding refresh messages must be generated and forwarded immediately so that state changes propagate end-to-end without delay. Propagation stops only where merging causes no net change.
A Logical Interface Handle (LIH) is carried in the RSVP_HOP object of Path messages alongside the previous-hop IP address. It identifies the logical outgoing interface and is stored in path state so that Resv messages can specify the correct interface regardless of which physical interface they arrive on, handling topology ambiguity caused by non-RSVP clouds.
A Path message is sent downstream by each sender along the data path, carrying SENDER_TEMPLATE (sender IP address and optional port), SENDER_TSPEC (traffic characteristics), and optionally an ADSPEC (OPWA advertising data). Each intermediate node stores path state including the previous-hop address used to reverse-route Resv messages.
A Resv message carries reservation requests hop-by-hop from receivers toward senders along the reverse data path. Its format requires SESSION, RSVP_HOP, TIME_VALUES, STYLE, and a flow descriptor list; it optionally carries RESV_CONFIRM, SCOPE, POLICY_DATA, and INTEGRITY objects.
An RSVP session is defined by the triple (DestAddress, ProtocolId [, DstPort]), where DestAddress may be unicast or multicast, ProtocolId is the IP protocol ID, and the optional DstPort is a generalized destination port (UDP/TCP port or application-specific demultiplexing point). All RSVP messages for the same session share this triple.
Flowspec merging computes the effective flowspec as the Least Upper Bound (LUB) of flowspecs received from different next hops for the same session. Because flowspecs are multi-dimensional opaque vectors (containing Tspec and Rspec components), service-specific routines external to RSVP perform the actual LUB and Greatest Lower Bound (GLB) computations.
PathTear and ResvTear messages explicitly remove state immediately without waiting for timeout. PathTear travels downstream deleting path state and all dependent reservation state; ResvTear travels upstream deleting reservation state. Both are unreliable; a lost teardown causes the downstream router to eventually time out and initiate a new teardown.
The ADSPEC object carries OPWA (One Pass With Advertising) information in Path messages. Each node's traffic control updates the Adspec as it travels downstream, collecting path characteristics so receivers can predict end-to-end QoS and construct or dynamically adjust reservation requests before committing to a Resv.
The POLICY_DATA object carries opaque policy data (credentials, account numbers, limits, quotas) for policy control modules to decide whether a reservation is administratively permitted. It may appear in Path, Resv, PathErr, or ResvErr messages; merging policy data is the responsibility of the policy control mechanism, not RSVP.
The RESV_CONFIRM object carries the IP address of a receiver requesting confirmation. When a node finds that the incoming Resv request is equal to or smaller than the reservation in place, it does not forward the Resv further and sends a ResvConf message back to the receiver. Receipt of ResvConf is a high-probability but not guaranteed indication of end-to-end reservation.
The SCOPE object carries an explicit list of sender hosts toward which a Resv, ResvErr, or ResvTear message is to be forwarded, used to prevent forwarding loops in wildcard-style reservations. A SCOPE object appearing in a ResvTear message is ignored.
Three mutually incompatible reservation styles are defined: Wildcard-Filter (WF, shared reservation + wildcard sender selection), Fixed-Filter (FF, distinct reservations + explicit sender selection), and Shared-Explicit (SE, shared reservation + explicit sender selection). Shared and distinct reservation modes cannot be merged, nor can wildcard and explicit sender selection.
Appendix A defines RSVP object Class-Num values (NULL=0, SESSION, RSVP_HOP, TIME_VALUES, STYLE, FLOWSPEC, FILTER_SPEC, SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC, ERROR_SPEC, POLICY_DATA, INTEGRITY, SCOPE, RESV_CONFIRM, and others) and their C-Type subtypes. Appendix B defines error codes and values for PathErr and ResvErr messages.
Carrying per-receiver policy data (credentials) in Resv messages creates a scaling problem for large multicast groups where it is impossible or undesirable to carry all receivers' policy data upstream. Policy data must be administratively merged near the receivers to avoid excessive overhead.
Spoofed or corrupted reservation requests could enable theft of service or denial of service by locking up network resources. RSVP protects against such attacks with hop-by-hop INTEGRITY objects using a keyed cryptographic digest (shared secret between RSVP neighbors) as specified in [Baker96]; until key management infrastructure is available, manual key configuration is required.
When IPsec encrypts transport and higher-level headers in the data stream, RSVP's generalized port numbers cannot be used to define a session or sender. The extension in [RFC 2207] resolves this by using the IPsec Security Parameter Index (SPI) in place of generalized ports.
Blockade state is created in each node a ResvErr message passes through when Admission Control fails. While active, blockade state causes the node to omit the offending (blockaded) flowspec from the merge computation, allowing a smaller competing reservation to be forwarded and established. This solves the second killer-reservation problem (KR-II).
Every RSVP object begins with a 4-byte header: Length (16 bits, total object length in bytes, must be a multiple of 4 and at least 4), Class-Num (8 bits, identifies object class), C-Type (8 bits, unique within Class-Num). Maximum object content is 65528 bytes.
The RSVP common header is 8 bytes: Vers (4 bits, currently 1), Flags (4 bits), Msg Type (8 bits, 1=Path through 7=ResvConf), RSVP Checksum (16 bits, one's complement sum), Send_TTL (8 bits), Reserved (8 bits), RSVP Length (16 bits, total message length including header and objects).