- Resource reservation protocol
The Resource ReSerVation Protocol (RSVP), described in RFC 2205, is a
Transport layerprotocol designed to reserve resources across a network for an integrated services Internet. "RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols" - RFC 2205. RSVP provides receiver-initiated setup of resource reservations for multicast or unicastdata flows with scaling and robustness.
RSVP can be used by either hosts or
routers to request or deliver specific levels of quality of service (QoS) 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 is not itself a
routing protocoland was designed to interoperate with current and future routing protocols.
RSVP by itself is rarely deployed in telecommunications networks today Fact|date=February 2007 but the traffic engineering extension of RSVP, or
RSVP-TE, is becoming more widely accepted nowadays in many QoS-oriented networks.
#RSVP requests resources for simplex flows: a traffic stream in only one direction from sender to one or more receivers.
#RSVP is not a routing protocol but works with current and future routing protocols.
#RSVP is receiver oriented: in that the receiver of a data flow initiates and maintains the resource reservation for that flow.
#RSVP maintains "soft state" (the reservation at each node needs a periodic refresh) of the host and routers' resource reservations, hence supporting dynamic automatic adaptation to network changes.
#RSVP provides several reservation styles (a set of reservation options) and allows for future styles to be added to protocol revisions to fit varied applications.
#RSVP transports and maintains traffic and policy control parameters that are opaque to RSVP.
History and related standards
RSVP is described in a series of RFC documents from the IETF:
* RFC 2205: The version 1 functional specification was described in RFC 2205 (Sept. 1997) by IETF. Version 1 describes the interface to admission (traffic) control that is based "only" on resource availability. Later RFC2750 extended the admission control support.
* RFC 2210 defines the use of RSVP with controlled-load RFC 2211 and guaranteed RFC 2212 QoS control services. More details in
Integrated Services. Also defines the usage and data format of the data objects (that carry resource reservation information) defined by RSVP in RFC 2205.
* RFC 2211 specifies the network element behavior required to deliver Controlled-Load services.
* RFC 2212 specifies the network element behavior required to deliver guaranteed QoS services.
* RFC 2750 describes a proposed extension for supporting generic policy based admission control in RSVP. The extension included a specification of policy objects and a description on handling policy events. (January 2000).
* RFC 3936 describes current best practices, and specifies procedures for modifying the Resource reSerVation Protocol (October 2004).
* RFC 4495(May 2006)
* RFC 4558 Node-ID Based Resource Reservation Protocol (RSVP)
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 MPLS a flow is defined as a LSP. For each flow RSVP also identifies the particular quality of service required by the flow although it does not understand the specific information of the flow QoS. This QoS specific 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:
#Reservation spec - defines the QoS
#Traffic spec - describes the data flow
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:
#Fixed filter - reserves resources for a specific flow.
#Shared explicit - reserves resources for several flows and all share the resources
#Wildcard filter - reserves resources for a general type of flow without specifying the flow; all flows share the resources
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.
There are two primary types of messages:
*Path messages ("path"):The "path" message is sent from the sender host along the data path and stores the "path state" in each node along the path. :The "path state" includes the IP address of the previous node, and some data objects:::#"sender template" to describe the format of the sender data::#"sender tspec" to describe the traffic characteristics of the data flow ::#"adspec" that carries advertising data (see RFC 2210 for more details).
*Reservation messages ("resv"):The "resv" message is sent from the receiver to the sender host along the reverse data path. At each node the IP destination address of the "resv" message will change to the address of the next node on the reverse path and the IP source address to the address of the previous node address on the reverse path. :The "resv" message includes the "flowspec" data object that identifies the resources that the flow needs.
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 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.
When the destination router receives the "path" message it will:
#Make a reservation based on the request parameters. For this the
admission controland policy controlprocess the request parameters and can either instruct the packet classifier to correctly handle the selected subset of data packets or negotiate with the upper layer how the packet handling should be performed.
#Forward the request upstream (in the direction of the sender). At each node the "resv" message "flowspec" can be modified by a forwarding node (e.g. in the case of a multicast flow reservation the reservations requests can be merged).
Each node in the path can either accept or reject the request.
*Encryption - RSVP messages are appended with a message digest created by combining the message contents and a shared key using a message digest algorithm (commonly
MD5). The key can be distributed and confirmed using 2 message types: "integrity challenge request" and "integrity challenge response".
*Error reporting - when a node detects an error, an error message is generated with an error code and is propagated upstream on the reverse path to the sender.
*Information on RSVP flow - two types of diagnostic messages allow a network operator to request the RSVP state information on a specific flow.
* Diagnostic facility - An extension to the standard which allows a user to collect information about the RSVP state along a path. [http://ietfreport.isoc.org/rfc/rfc2745.txt RFC2745 - RSVP Diagnostic Messages]
* "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)
* [http://www.isi.edu/div7/rsvp/rsvp.html RSVP Project] of USC Information Science Institute
* [http://www.cisco.com/en/US/docs/internetworking/technology/handbook/RSVP.html Resource Reservation Protocol] Cisco chapter
* RFC 2205
* RFC 2210
* RFC 2211
* RFC 2212
Wikimedia Foundation. 2010.
См. также в других словарях:
Resource Reservation Protocol — (ou RSVP) est un protocole permettant de réserver des ressources dans un réseau informatique. Liens externes (en) RFC 2205 Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification (en) RFC 2210 The Use of RSVP with IETF Integra … Wikipédia en Français
Resource Reservation Protocol — Resource Reservation Protocol, RSVP … Universal-Lexikon
Resource Reservation Protocol — RSVP (Resource Reservation Protocol) Familie: Internetprotokollfamilie Einsatzgebiet: Signalisierungsprotokoll im Internetprotokollstapel RSVP im TCP/IP Protokollstapel Anwendungsschicht FTP SMTP DNS … … Deutsch Wikipedia
Resource Reservation Protocol — Abbreviated RSVP. An Internet protocol designedtodeliverdataontimeandintheright order over TCP/IP (Transmission Control Protocol/Internet Protocol) networks. RSVP is a control and signaling protocol, not a routing protocol, and it works by… … Dictionary of networking
Resource reservation protocol — … Википедия
Resource Reservation Protocol — … Википедия
Resource Reservation Setup Protocol — protocol that is currently under development and will enable Internet users to reserve Internet channels for high bandwidth broadcasts and transmissions, RSVP (Internet) … English contemporary dictionary
Reservation ALOHA — (R ALOHA) is a Multiple Access schema for wireless transmission which allows uncoordinated users to share a common transmission resource. Reservation ALOHA (and it s parent schema, Slotted ALOHA) is a schema or rule set for the division of… … Wikipedia
Internet Protocol Next Generation — IPv6 im TCP/IP‑Protokollstapel: Anwendung HTTP IMAP SMTP DNS … Transport TCP UDP … Deutsch Wikipedia
Internet Protocol Version 6 — IPv6 im TCP/IP‑Protokollstapel: Anwendung HTTP IMAP SMTP DNS … Transport TCP UDP … Deutsch Wikipedia