You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 44.200.0.0/16 has been blocked (disabled) by ‪Blablubbs‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider or colocation provider. To prevent abuse, web hosts and colocation providers may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host or colocation provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a colocation provider's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a colocation web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host or colocation provider (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host or colocation provider.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and requests should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 16:45, 10 February 2025.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪AntiCompositeNumber‬. The reason given is Open proxy/Webhost: Visit the FAQ if you are affected .
- Start of block: 13:55, 18 August 2022
- Expiry of block: 13:55, 18 March 2025
Your current IP address is 44.200.254.7. The blocked range is 44.200.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((Short description|Computer network protocol))
((Use American English|date=September 2020))

The '''Resource Reservation Protocol''' ('''RSVP''') is a [[transport layer]]<ref>((cite book|url=https://books.google.com/books?id=pIIu7IbUwIcC&pg=PA583 |title=Juniper Networks Field Guide and Reference|page=583|first1=Aviva|last1=Garrett|first2=Gary|last2=Drenan|first3=Cris|last3=Morris|year=2002|publisher=Addison-Wesley Professional |isbn=9780321122445))</ref> [[Communications protocol|protocol]] designed to reserve resources across a [[Computer networking|network]] using the [[integrated services]] model. RSVP operates over an [[IPv4]] or [[IPv6]] and provides receiver-initiated setup of resource reservations for [[IP multicast|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 ((IETF RFC|2205)).

RSVP can be used by [[host (network)|hosts]] and [[router (computing)|routers]] to request or deliver specific levels of [[quality of service]] (QoS) for application [[Stream (computing)|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.

((IPstack))

==Main attributes==
((unsourced section|date=October 2019))
#RSVP requests resources for [[Simplex communication|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 (computer science)|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 in protocol revisions to fit varied applications.
#RSVP transports and maintains traffic and policy control parameters that are opaque to RSVP.((elucidate|date=October 2019))

==History and related standards==
The basic concepts of RSVP were originally proposed in 1993.<ref name="RSVP93">Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, September 1993</ref>

RSVP is described in a series of RFC documents from the IETF:

* ((IETF RFC|2205|link=no)): The version 1 functional specification was described in RFC 2205 (Sept. 1997) by [[Internet Engineering Task Force|IETF]]. Version 1 describes the interface to admission (traffic) control that is based "only" on resource availability. Later [[#RFC2750|RFC2750]] extended the admission control support.
* ((IETF RFC|2210|link=no)) 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.
* ((IETF RFC|2211|link=no)) specifies the network element behavior required to deliver Controlled-Load services.
* ((IETF RFC|2212|link=no)) specifies the network element behavior required to deliver guaranteed QoS services.
* ((IETF RFC|2750|link=no)) describes a proposed extension for supporting generic [[policy|policy based]] admission control in RSVP. The extension included a specification of policy objects and a description on handling policy events. (January 2000).
* ((IETF RFC|3209|link=no)), "RSVP-TE: Extensions to RSVP for LSP Tunnels" (December 2001).
* ((IETF RFC|3473|link=no)), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (January 2003).
* ((IETF RFC|3936|link=no)), "Procedures for Modifying the '''R'''esource re'''S'''er'''V'''ation '''P'''rotocol (RSVP)" (October 2004), describes current best practices and specifies procedures for modifying RSVP.
* ((IETF RFC|4495|link=no)), "A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow" (May 2006), extends RSVP to enable the bandwidth of an existing reservation to be reduced instead of tearing down the reservation.
* ((IETF RFC|4558|link=no)), "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement" (June 2006).

==Key concepts==
The two key concepts of RSVP reservation model are ''flowspec'' and ''filterspec''.

===Flowspec===
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:
#Service class
#Reservation spec - defines the QoS
#Traffic spec - describes the data flow

===Filterspec===
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 ''flowspec'' sets the parameters of the packet scheduler at a node and the ''filterspec'' sets the parameters at the packet classifier.

==Messages==
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 in the form of a Filterspec<ref>((cite IETF |rfc=2205 |date=September 1997 |url=https://tools.ietf.org/html/rfc2205#section-2 |page=19 |title=Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification |first1=Zhang |last1=Lixia |first2=Berson |last2=Steve |first3=Herzog |last3=Shai |first4=Jamin |last4=Sugih))</ref>
::#''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 data objects see RFC 2205.

==Operation==
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:
#Make a reservation based on the request parameters. [[Admission control]] processes 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. If the cannot be supported, a reject message is sent to let the listener know.
#Forward the request upstream (in the direction of the sender). At each node the ''flowspec'' in the ''resv'' message can be modified by a forwarding node (e.g. in the case of a multicast flow reservation the reservations requests can be merged).
#The routers then store the nature of the flow and optionally set up [[Traffic policing (communications)|policing]] according to the flowspec for it. 

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.

==Other features==
;Integrity
: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 two 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.<ref>((cite IETF |rfc=2745 |title=RSVP Diagnostic Messages))</ref>

===RFCs===
* ((IETF RFC|2205|link=no))
* ((IETF RFC|2210|link=no))
* ((IETF RFC|2211|link=no))
* ((IETF RFC|2212|link=no))

==References==
((Reflist))
((refbegin))
* ((cite book |title=Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice |author1=John Evans |author2=Clarence Filsfils |publisher=Morgan Kaufmann |year=2007 |isbn=978-0-12-370549-5))
((refend))

== External links ==
* ((cite web |url=http://docwiki.cisco.com/wiki/Resource_Reservation_Protocol |archive-url=https://web.archive.org/web/20170705125333/http://docwiki.cisco.com/wiki/Resource_Reservation_Protocol |archive-date=2017-07-05|title=Resource Reservation Protocol |publisher=Cisco |access-date=2011-02-16 |url-status=dead))
* ((cite magazine |url=http://www.networkworld.com/news/tech/2002/0617tech.html |title=RSVP provides quality of service |author=Naveen Joy |magazine=Network World |date=2002-06-17 |access-date=2012-02-14 |url-status=dead |archive-url=https://web.archive.org/web/20130629071118/http://www.networkworld.com/news/tech/2002/0617tech.html |archive-date=2013-06-29 ))
* ((cite web |url=http://www.isi.edu/div7/rsvp/rsvp.html |title=RSVP Project |publisher=USC Information Science Institute |archive-url=https://web.archive.org/web/20170427101224/https://www.isi.edu/div7/rsvp/rsvp.html |archive-date=2017-04-27 |url-status=dead))

((DEFAULTSORT:Resource Reservation Protocol))
[[Category:Internet architecture]]
[[Category:Internet protocols]]
[[Category:Transport layer protocols]]

Pages transcluded onto the current version of this page (help):

Resource Reservation Protocol (edit)
Template:Ambox (view source) (template editor protected)
Template:Catalog lookup link (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation (view source) (protected)
Template:Cite IETF (view source) (semi-protected)
Template:Cite IETF/doctypes (view source) (semi-protected)
Template:Cite IETF/makelink (view source) (semi-protected)
Template:Cite book (view source) (protected)
Template:Cite magazine (view source) (protected)
Template:Cite web (view source) (protected)
Template:DMCA (view source) (template editor protected)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:Elucidate (view source) (semi-protected)
Template:Explain (view source) (extended confirmed protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:Hlist/styles.css (view source) (protected)
Template:IETF RFC (view source) (template editor protected)
Template:IPstack (edit)
Template:Ifeq (view source) (template editor protected)
Template:Internet protocol suite (edit)
Template:Main other (view source) (protected)
Template:Ns has subpages (view source) (protected)
Template:P2 (view source) (protected)
Template:Pagetype (view source) (protected)
Template:Refbegin (view source) (template editor protected)
Template:Refbegin/styles.css (view source) (template editor protected)
Template:Refend (view source) (template editor protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Sidebar (view source) (template editor protected)
Template:Unreferenced (view source) (template editor protected)
Template:Unreferenced section (view source) (template editor protected)
Template:Unsourced section (view source) (semi-protected)
Template:Use American English (view source) (template editor protected)
Template:Yesno (view source) (protected)
Template:Yesno-no (view source) (template editor protected)
Template:Yesno-yes (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Catalog lookup link (view source) (template editor protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Navbar (view source) (protected)
Module:Navbar/configuration (view source) (protected)
Module:Navbar/styles.css (view source) (protected)
Module:Ns has subpages (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:Sidebar (view source) (template editor protected)
Module:Sidebar/configuration (view source) (template editor protected)
Module:Sidebar/styles.css (view source) (template editor protected)
Module:String (view source) (protected)
Module:Template wrapper (view source) (template editor protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Resource Reservation Protocol.

Retrieved from "https://en.wikipedia.org/wiki/Resource_Reservation_Protocol"