The Resource Reservation Protocol (RSVP) is a transport layer [1] protocol designed to reserve resources across a network using the integrated services model. RSVP operates over an IPv4 or IPv6 and provides receiver-initiated setup of resource reservations for multicast or unicast data flows. 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 hosts and routers to request or deliver specific levels of quality of service (QoS) for application data streams. RSVP defines how applications place reservations and how they can relinquish the reserved resources once no longer required. RSVP operations will generally result in resources being reserved in each node along a path. RSVP is not a routing protocol but was designed to interoperate with current and future routing protocols.
In 2003, development effort was shifted from RSVP to RSVP-TE for teletraffic engineering. Next Steps in Signaling (NSIS) was a proposed replacement for RSVP.
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
The basic concepts of RSVP were originally proposed in 1993. [2]
RSVP is described in a series of RFC documents from the IETF:
The two key concepts of RSVP reservation model are flowspec and filterspec.
RSVP reserves resources for a flow. A flow is identified by the destination address, the protocol identifier, and, optionally, the destination port. In Multiprotocol Label Switching (MPLS) a flow is defined as a label-switched path (LSP). For each flow, RSVP also identifies the particular quality of service (QoS) required by the flow. This QoS information is called a flowspec and RSVP passes the flowspec from the application to the hosts and routers along the path. Those systems then analyse the flowspec to accept and reserve the resources. A flowspec consists of:
The filterspec defines the set of packets that shall be affected by a flowspec (i.e. the data packets to receive the QoS defined by the 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).
The currently defined RSVP reservation styles are:
An RSVP reservation request consists of a flowspec and a filterspec and the pair is called a flowdescriptor. The flowspec sets the parameters of the packet scheduler at a node and the filterspec sets the parameters at the packet classifier.
There are two primary types of messages:
The data objects on RSVP messages can be transmitted in any order. For the complete list of RSVP messages and data 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.
Those who want to listen to them send a corresponding resv (short for reserve) message which then traces the path back to the sender. The resv message contains a flowspec. The resv message also has a 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. When a router receives the RSVP resv message it will:
If nothing is heard for a certain length of time the reservation will time out and will be canceled. This solves the problem if either the sender or the receiver crash or are shut down without first canceling the reservation.
The Resource Reservation Protocol (RSVP) is a transport layer [1] protocol designed to reserve resources across a network using the integrated services model. RSVP operates over an IPv4 or IPv6 and provides receiver-initiated setup of resource reservations for multicast or unicast data flows. 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 hosts and routers to request or deliver specific levels of quality of service (QoS) for application data streams. RSVP defines how applications place reservations and how they can relinquish the reserved resources once no longer required. RSVP operations will generally result in resources being reserved in each node along a path. RSVP is not a routing protocol but was designed to interoperate with current and future routing protocols.
In 2003, development effort was shifted from RSVP to RSVP-TE for teletraffic engineering. Next Steps in Signaling (NSIS) was a proposed replacement for RSVP.
Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
The basic concepts of RSVP were originally proposed in 1993. [2]
RSVP is described in a series of RFC documents from the IETF:
The two key concepts of RSVP reservation model are flowspec and filterspec.
RSVP reserves resources for a flow. A flow is identified by the destination address, the protocol identifier, and, optionally, the destination port. In Multiprotocol Label Switching (MPLS) a flow is defined as a label-switched path (LSP). For each flow, RSVP also identifies the particular quality of service (QoS) required by the flow. This QoS information is called a flowspec and RSVP passes the flowspec from the application to the hosts and routers along the path. Those systems then analyse the flowspec to accept and reserve the resources. A flowspec consists of:
The filterspec defines the set of packets that shall be affected by a flowspec (i.e. the data packets to receive the QoS defined by the 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).
The currently defined RSVP reservation styles are:
An RSVP reservation request consists of a flowspec and a filterspec and the pair is called a flowdescriptor. The flowspec sets the parameters of the packet scheduler at a node and the filterspec sets the parameters at the packet classifier.
There are two primary types of messages:
The data objects on RSVP messages can be transmitted in any order. For the complete list of RSVP messages and data 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.
Those who want to listen to them send a corresponding resv (short for reserve) message which then traces the path back to the sender. The resv message contains a flowspec. The resv message also has a 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. When a router receives the RSVP resv message it will:
If nothing is heard for a certain length of time the reservation will time out and will be canceled. This solves the problem if either the sender or the receiver crash or are shut down without first canceling the reservation.