[This is preliminary documentation and subject to change.]
RSVP (Resource Reservation Protocol) is an IETF-draft networking protocol dedicated to being the facilitator and carrier of 'standardized' Quality of Service information and parameters. RSVP carries generic (industry defined) QOS parameters from end nodes (inclusive) to each QOS-aware network device included in the 'hop path' between RSVP session members. In a sentence, RSVP is a means by which end nodes, and network devices, can communicate and negotiate QOS parameters and network usage admission.
RSVP is a multi-faceted protocol; it is active and central to application-driven, network-driven, and policy driven GQOS activities, in that it is the 'container' by which GQOS parameters and information is sent across the network. RSVP has its own objects which can be filled or interrogated to specify or determine the requested QOS parameters that are either requested by the application, required of the network device, or applied for by the user. Since RSVP has its own clearly-defined objects, the implementation of RSVP within Windows NT 5.0 requires GQOS parameters to be 'mapped' into (or on the receiving end of RSVP messages, derived from) RSVP objects. Such mapping (i.e., translation of RSVP into natively understood information) will occur on each QOS-aware network device that RSVP interacts with, allowing, in the end, a protocol that can carry and share industry standard QOS information to any device interested in participation in QOS activities.
From an application-driven perspective, RSVP is the means by which an application's requests are transported through the network (a container, though one with specifically defined compartments). Calls to the GQOS API provide information to the GQOS SP, which then maps such information into pre-defined RSVP objects for transmission across the network.
From a network-driven perspective, RSVP provides network devices a predictable and understandable set of information, from which resource availability-based (and/or policy-based) decisions on whether to offer bandwidth reservation can be made.
From a policy-driven perspective, RSVP provides the necessary user information within industry standard RSVP objects (much like a set of containers, each of which is pre-sized based on its clearly marked contents), that facilitate the exchange of user identity and admission requests.
Although RSVP can be considered responsible for the bulk of GQOS interaction among end-nodes, it is possible to achieve QOS without its inclusion, such as by using Traffic Control facilities available with GQOS.