The RSVP protocol is the protocol adopted in the GMPLS architecture for reserving and signaling a path in a switched based network. The RFC2205 from 19971 specifies the original regular version of this protocol before later amendments required to better serve the GMPLS architecture which culminated in the RSVP-TE, the following text refers to the above mentioned document.
The RSVP is a reservation setup protocol. A host (receiver) uses the RSVP to request specific qualities of service for a data flow. RSVP reserves resources on each node along a selected path. It requests resources in only one direction and upstream. After a route is determined by a routing protocol the RSVP accesses the local routing database in order to obtain information on the routes, and therefore to which nodes messages will be sent.
Traffic control state and RSVP state are assumed to be dynamic, therefore RSVP establishes a soft state, it sends periodic refreshing messages tom maintain the
state along the reserved path. If refresh messages are not received the state will eventually time out and be teared down.
Traffic control state and RSVP state are assumed to be dynamic, therefore RSVP establishes a soft state, it sends periodic refreshing messages tom maintain the
state along the reserved path. If refresh messages are not received the state will eventually time out and be teared down.
The Quality of Service for a data flow is implemented by mechanisms called Traffic control: packet classifier, admission control, packet scheduler.
In summary, RSVP has the following attributes:
In summary, RSVP has the following attributes:
- RSVP makes resource reservations for both unicast and many-to- many multicast applications, adapting dynamically to changing group membership as well as to changing routes. o RSVP is simplex, i.e., it makes reservations for unidirectional data flows.
- RSVP is receiver-oriented, i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow.
- RSVP maintains "soft" state in routers and hosts, providing graceful support for dynamic membership changes and automatic adaptation to routing changes.
- RSVP is not a routing protocol but depends upon present and future routing protocols.
- RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP.
- RSVP provides several reservation models or "styles" (defined below) to fit a variety of applications.
- RSVP provides transparent operation through routers that do not support it.
- RSVP supports both IPv4 and IPv6.
1 Braden, R.; Zhang, L.; Berson, S.; Herzog, S. & Jamin, S. (1997), 'RFC2205: Resource ReSerVation Protocol (RSVP)-Version 1 Functional Specification', IETF, September.
No comments:
Post a Comment