Resource Reservation Protocol is ...

Resource Reservation Protocol

The Resource Reservation Protocol is a Transport Layer protocol designed to reserve resources across a network for an integrated services Internet. RSVP operates over an IPv4 or IPv6 Internet Layer and provides receiver-initiated setup of resource reservations for multicast or unicast data flows with scaling and robustness. It does not transport application data but is similar to a control protocol, like Internet Control Message Protocol (ICMP) or Internet Group Management Protocol (IGMP). RSVP is described in RFC 2205.
RSVP can be used by either hosts or routers to request or deliver specific levels of quality of service for application data streams or flows. RSVP defines how applications place reservations and how they can relinquish the reserved resources once the need for them has ended. RSVP operation will generally result in resources being reserved in each node along a path.
RSVP isn't a routing protocol and was designed to inter-operate with current and future routing protocols.
RSVP by itself is rarely deployed in telecommunications networks today but the traffic engineering extension of RSVP, or RSVP-TE, is becoming more widely accepted nowadays in many QoS-oriented networks. Next Steps in Signaling is a replacement for RSVP.
The filterspec defines the set of packets that shall be affected by a flowspec. A filterspec typically selects a subset of all the packets processed by a node. The selection can depend on any attribute of a packet (e.g. the sender IP address and port).
An RSVP reservation request consists of a flowspec and a filterspec and the pair is called a flowdescriptor. The effects at the node of each spec are that while the flowspec sets the parameters of the packet scheduler at a node, the filterspec sets the parameters at the packet classifier.
The data objects on RSVP messages can be transmitted in any order. For the complete list of RSVP messages and date objects see RFC 2205.
An RSVP host that needs to send a data flow with specific QoS will transmit an RSVP path message every 30 seconds that will travel along the unicast or multicast routes pre-established by the working routing protocol. If the path message arrives at a router that does not understand RSVP, that router forwards the message without interpreting the contents of the message and will not reserve resources for the flow.
The resv message also has FilterSpec object; it defines the packets that will receive the requested QoS defined in the flowspec. A simple filter spec could be just the sender’s IP address and optionally its UDP or TCP port.

Related Sites for Resource Reservation Protocol

• RSVP WG Charter page - Internet Engineering Task Force (IETF) read Resource Reservation Protocol
• RFC 5824: Requirements for Supporting Customer Resource ... read Resource Reservation Protocol
• RFC 2205 read Resource Reservation Protocol
• 1967 Protocol Relating to the Status of Refugees - Israeli ... read Resource Reservation Protocol

Tweet