Resource ReserVation Protocol

Description

The Resource ReserVation Protocol (RSVP) is a transport layer protocol defined by IETF (RFC 2205) and adopted in 3GPP specifications for QoS management. It operates as a signaling mechanism to set up and maintain resource reservations for unicast or multicast data flows in IP networks. RSVP does not transport application data but communicates reservation requests between network nodes (routers and hosts) to ensure that resources like bandwidth, buffer space, and processing capacity are allocated along the path.

Architecture: RSVP uses a soft-state approach, where reservations must be periodically refreshed to remain active, allowing dynamic adaptation to changing network conditions. Key messages include PATH messages, sent from the data source toward the destination to establish the route and specify traffic characteristics (TSpec), and RESV messages, sent back from the receiver toward the source to reserve resources at each intermediate node. Each node performs admission control based on available resources and policy checks before committing the reservation.

How it works: When an application requires QoS, the sender issues a PATH message that traverses routers, storing path state. The receiver responds with a RESV message that follows the reverse path, requesting resources such as guaranteed or controlled-load service. Routers along the path reserve resources using classifiers (to identify packets belonging to the flow) and schedulers (to prioritize packet forwarding). RSVP supports different reservation styles (e.g., fixed-filter, shared-explicit) to accommodate various multicast scenarios.

In 3GPP networks, RSVP is referenced in the context of IP Multimedia Subsystem (IMS) and end-to-end QoS provisioning. It integrates with policy control functions (PCRF) to enforce network policies. Although newer mechanisms like DiffServ and MPLS have supplemented RSVP in some areas, it remains relevant for explicit per-flow reservations in scenarios requiring precise QoS control, such as dedicated bearer establishment in mobile cores or inter-domain resource management.

Purpose & Motivation

RSVP was created to address the best-effort nature of early IP networks, which lacked mechanisms to guarantee QoS for real-time applications. As multimedia services like video conferencing and VoIP emerged, they required predictable latency, jitter, and bandwidth, which traditional IP routing could not assure. RSVP provides a standardized way for applications to signal their QoS needs to the network, enabling resource reservation end-to-end.

The inclusion of RSVP in 3GPP standards, starting from R99, was driven by the need for QoS in mobile networks supporting rich media services. It solved limitations of static QoS configurations by allowing dynamic, per-flow reservations that adapt to user sessions. RSVP facilitates interworking between cellular and fixed IP networks, ensuring consistent service quality across heterogeneous domains.

Historically, prior approaches like IntServ (Integrated Services) required per-flow state in routers, raising scalability concerns. RSVP's soft-state design mitigates this by allowing state timeout without explicit teardown, though scalability remains a challenge in large networks. Its creation was motivated by the growth of multicast applications (e.g., live streaming) where resource reservations are complex. In 3GPP, RSVP supports critical functions like emergency service prioritization and IMS session management, aligning with regulatory and service requirements.

Key Features

• Signals resource reservations for unicast and multicast flows
• Uses PATH and RESV messages for bidirectional setup
• Supports soft-state reservations requiring periodic refresh
• Performs admission control and policy enforcement at nodes
• Integrates with IntServ model for guaranteed QoS
• Enables reservation styles for flexible multicast resource sharing

Evolution Across Releases

Defining Specifications