Resource Reservation Protocol: Difference between revisions
imported>Howard C. Berkowitz mNo edit summary |
mNo edit summary |
||
| Line 20: | Line 20: | ||
==References== | ==References== | ||
{{reflist|2}} | {{reflist|2}}[[Category:Suggestion Bot Tag]] | ||
Latest revision as of 11:01, 11 October 2024
As one of the many technologies to provide a guaranteed quality of service over Internet Protocol networks,[1] the Resource Reservation Protocol (RSVP) is an end-to-end control protocol for path setup, as distinct from data transfer. It is a Proposed Standard in the Internet Engineering Task Force standards track. [2] It is supported by most router implementations.
A resource reservation request is sent from one edge of the "network cloud" to the other, and is confirmed if and only if each router along the path can allocate the necessary bandwidth (or other resource). To guarantee quality of service for a bidirectional session such as a Voice over Internet Protocol call, RSVP reservations need to be confirmed in both directions.
In addition to its role in setting up end-to-end IP paths for specific user sessions, it is, when given traffic engineering extensions, also used as a path setup protocol for Multiprotocol Label Switching. [3]
References
- ↑ Information Sciences Institute, University of Southern California, RSVP ReSerVation Protocol
- ↑ R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin (September 1997), RFC2205
- ↑ D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow (December 2001), RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC3209