Quality of Service

Resource Reservation Protocol

Resource Reservation Protocol (RSVP) is an IETF-defined (RFC 2205) signaling protocol that uses Integrated Services (Intserv) to convey QoS requests to the network. The Intserv architecture specifies extensions to the best-effort traffic model – the standard delivery model used in most IP networks and the Internet. Intserv provides for special handling of priority-marked traffic, and a mechanism by which QoS-aware applications can choose service levels for traffic delivery: controlled load or guaranteed service. Windows 2000 supports an extension of the standard Intserv service types in the form of the qualitative service type. The qualitative service type is designed for applications that require QoS but cannot quantify their QoS requirements due to the intermittent or burst-like nature of their traffic. Integrated Services also defines QoS signaling (RSVP) for the purpose of making resource reservations across a network.

RSVP is a layer 3 protocol, making it independent of the underlying network media. Customer networks generally include heterogeneous media, including Ethernet or token ring local area network (LAN) media, WANs made up of low and high-speed leased lines, modem links, and ATM technology. RSVP bridges the gap between applications, the operating system, and media-specific QoS mechanisms. This enables RSVP to send QoS messages structured in media-independent terms, making it an effective signaling protocol for end-to-end QoS over networks that combine different types of low-layer media. For example, end nodes can exchange RSVP messages across a network comprised of 802-type LANs, routers, ATM and WAN regions, with each making the appropriate admission control decisions and providing QoS if approved.

RSVP is well-suited to both mission-critical applications, such as Enterprise Resource Planning software, and session-oriented applications, such as IP telephony and video conferencing. Both applications exchange QoS data between fixed end nodes for some degree of persistence. These types of applications tend to stream data. QoS-enabled connections are unidirectional. To enable a connection with service guarantees for both sending and receiving from a host, two individual QoS-enabled connections are required.

RSVP is primarily for use with IP traffic, operating on top of IPv4 or IPv6, whereas a transport protocol resides in the protocol stack. However, it is a signaling protocol, not a routing protocol. Routing protocols determine where packets get forwarded; RSVP configures reservations for data flows along a data path predetermined by the network routing protocol.

The RSVP protocol is installed as part of the Windows 2000 installation of Windows Sockets 2.0. The RSVP protocol does the following:

Works with any current-generation network routing protocol and supports a number of network layer protocols, including TCP/IP.
Supports multicast and unicast transmissions.
Carries the bandwidth reservation request to each network device or hop (routers, switches, or proxies) responsible for managing resources in the data path between the sender and receiver (end nodes).
Maintains the reservation at each hop by caching that information in the hop, creating a reservation soft-state or state.
Passes transparently through devices that do not support RSVP.

If a network device does not support RSVP, QoS is not truly guaranteed along that particular network segment. The messages simply pass through each hop, and since they are not recognized, no priority bandwidth or handling is allocated. Throughout that segment, traffic is handled best-effort, meaning that end-to-end and low-delay guarantees for the requested service level are not available. This situation can arise in areas of the network where there is an abundance of bandwidth or where the network elements themselves are the resource constraint. Currently, some high-end routers and switches are RSVP-compliant.

The RSVP Service Provider (RSVP SP), which invokes and facilitates QoS and RSVP signaling, enables application developers to directly interact with RSVP. For additional information about the RSVP Service Provider, see the Software Development Kit link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

Direct interaction with RSVP by an application or service enables fine-tuning or special service requests. However, most application programmers find that enabling an application or service to use the RSVP SP, which initiates and maintains RSVP signaling on behalf of applications or services, is sufficient to enable their application or service to take advantage of QoS capabilities.

The QoS API is the programmatic interface to the RSVP SP. Under most circumstances, the QoS API is the only interface that programmers require to create QoS-aware or QoS-enabled applications.