Professional Documents
Culture Documents
Resource Reservation Protocol Resource Reservation Protocol (RSVP)
Resource Reservation Protocol Resource Reservation Protocol (RSVP)
RSVP Documents
RFC 2205 Resource ReSerVation Protocol (RSVP) -Functional Specification RFC 2209 Resource ReSerVation Protocol (RSVP) -Message Processing Rules RFC 2210 The Use of RSVP with IETF Integrated Services RFC 2211 Specification of Controlled-Load Network Controlled Load Element Service RFC 2212 Specification of Guaranteed Quality Service p Q y RFC 2215 General Characterization Parameter for Integrated Service Network Elements RFC 2216 Network Element Service Specification Template 3
Introduction of RSVP
RSVP makes resource reservations for both unicast and pp , p g y y g g multicast applications, adapting dynamically to changing group membership and routes. A resource reservation setup protocol designed for an integrated services Internet. Used by a host to request a specific QoS from the network. Also used by the routers to deliver QoS requests to all nodes along the path(s) of the data stream and to establish and maintain state to provide the requested service service.
Introduction of RSVP
RSVP reserve resources for simplex data streams (only one direction). Operates on top of IP (either IPv4 or IPv6), like ICMP, IGMP. Not a routing protocol, but designed to operate with current and future unicast and multicast routing protocol, like DVMRP (Distance Vector Mu t cast out g otoco ), CBT (Co e Based Multicast Routing Protocol), C (Core ased Tree), PIM (Protocol Independent Multicast), etc. An RSVP daemon consults the local routing database(s) to obtain routes.
5
Introduction of RSVP
In the multicast case, a host sends IGMP messages to join a multicast group and then sends RSVP Resv messages to reserve resources along the delivery p g y path(s) of that group. g p Incoming packets are passes through a packet classifier which determines the route and the QoS class for each packet. On outgoing interface, a packet scheduler then g g , p makes forwarding decisions for every packet, to achieve the promised QoS on the particular linklayer medium.
6
Introduction of RSVP
Admission control determines whether resources are sufficient to support the requested QoS. Policy P li control d l determines whether the user i h h h is allowed to make the reservation. Uses soft state in the routers. RSVP sends periodic refresh messages to maintain the state along the reserved path(s); in absence of refreshes, the state will automatically time out and be deleted.
7
Router
RSVP RSVP daemon Policy Control Admis Control Packet Scheduler Packet Scheduler Data Data
11 Receive R i (Ipa,PID,Port)
R2
path
Data Flows
RSVP defines a session to be a data flow with a particular destination and transport-layer protocol (TCP/UDP). The destination of a session is defined by
DstAddr, the IP destination address of the , data packets. Protocol ID, DstPort, a generalized destination port (some further demultiplexing point in the transport or application protocol layer).
10
Reservation Model
An elementary RSVP reservation request consists of a flow descriptor = (flowspec, filter spec). The flowspec defines a desired QoS and is used to set parameters in the nodes packet scheduler. The filter spec defines the set of data packets (flow) to receive the QoS defined by the flow spec, and is used to set parameters in the nodes node s packet classifier.
11
Reservation Model
The flow spec includes a service class and two sets of numeric parameters: an Rspec (R for reserve) that defines the QoS, and d a Tspec (T for Traffic) that describes the data flow. fl The filter specs may select arbitrary subsets of the packets in a given session. The one used in present RSVP consisting of sender IP addr and optionally the th UDP/TCP port number SrcPort. t b S P t
12
Reservation Styles
A reservation request includes a set of options that are collectively called the reservation style style.
One concerns the treatment of reservations for different senders within the same session : establish a distinct reservation for each upstream sender, or else make a single reservation that is shared among all packets of selected senders. l d d Another controls the selection of senders; an explicit list of all selected senders, or a wildcard that implicity senders selects all the senders to the session.
13
Reservation Styles
Fixed-Filter (FF) Style Shared-Explicit (SE) Style Wildcard Filter Wildcard-Filter (WF) Style
Sender Selection Explicit Wildcard Reservation Distinct Fixed-Filter (FF) Style (None defined) Shared Shared-Explicit (SE) Style Wildcard-Filter (WF) Style
14
Reservation Styles
Wildcard-Filter Wild d Filt (WF) St l Style Shared reservation and wildcard sender selection. Creates a single reservation shared by all upstream senders. WF ( *{Q} ) Fixed-Filer (FF) Style Distinct reservation and explicit sender selection. Creates a distinct reservation for data packets from a particular sender. FF ( S {Q} ) <= a flow descriptor FF ( S1 {Q1} S2 {Q2} ... ) : The total reservation is {Q1}, {Q2}, the sum of Q1, Q2, ...
15
Reservation Styles
Shared Explicit (SE) Style Shared reservation and explicit sender selection. Creates a single reservation shared by g y selected upstream senders. SE ( {S1,S2,...}, {Q} )
16
Reservation Styles
These styles are all mutually incompatible. Shared reservations, created b WF and SE reser ations by styles, are appropriate for those multicast applications in which multiple data sources are unlikely to transmit simultaneously (packetized audio). ) Distinct reservation (FF style) is appropriate for the flows from different senders (video signals).
17
Example of Styles
S1 S2,S3 a b
Router
c d
R1
Router
R2 R3
LAN
Router
( { } WF (*{4B} )
S1 S2,S3
WF (*{4B} )
R1
WF (*{3B} ) ( { } Router
R2 R3
*{3B}
WF (*{2B} )
LAN
Router
Example of Styles
Router FF (S1{4B} ) FF (S1{4B},S2{5B} )
S1 S2,S3
FF (S2{5B},S3{B} )
R1
FF (S1{3B},S3{B} ) (S1{3B} S3{B} FF (S1{B} ) Router Router
R2 R3
LAN
SE (S1{3B} )
S1 S2,S3
SE ((S2,S3){3B} )
SE ((S1,S2){B} )
R1
SE( (S1,S3){3B} ) (S1 S3){3B} Router
R2 R3
LAN
SE (S2{2B} ) Router
Example of Styles
S1 S2,S3 a b
Router
c d
R1
Router
R2 R3
LAN
Router
S1 S2,S3 S2 S3
*{4B}
R1
Router
R2 R3
*{3B}
LAN
Router
Each receiver host sends Rsev messages upstream towards the senders. These messages follow exactly the reverse of the path(s) the data packets will use, to all the selected senders. Each node along the path(s) creates and maintains the reservation state. th( ) t d i t i th v ti t t
21
23
24
Object Formats
0 1 Length (bytes) 2 Class-Num 3 C-Type
(Object contents)
25
Path Message
RSVP_Hop: IP address of previous RSVP node Sender Template :
Describes the format of the data packets that the sender will originate.
Sender Tspec
Defines the traffic characteristics of the data flow that the sender will generate. Used by traffic control to prevent over-reservation. r : Token Bucket Rate (32-bit IEEE Floating Point number) b : Token Bucket Size (32-bit IEEE Floating Point number) p : Peak Data Rate (32-bit IEEE Floating Point number) m : Minimum Policed U it (32-bit i t Mi i P li d Unit (32 bit integer) ) M : Maximum Packet Size (32-bit integer)
28
p>r M<b M
min[pT, rT+b] min[pT+M, min[pT+M rT+b] b : Maximum burst size (packetize version) x <= (rT+b)
29
Resv Message
<Resv Message> ::= <Common Header> [<Integrity>] <Session> <RSVP_Hop> <Time_Values> [<Resv_Confirm>] [ <Scope>] [<Policy_Data>...] [<Style> <flow descriptor list>] <flow descriptor list> ::= <empty> | p p <flow descriptor list> <flow descriptor>
30
Host Model
Before a session can be created, the session ID must be assigned and communicated to all the g senders and receivers by some out-of-band mechanism. When an RSVP session is being set up, the following events happen at the end systems:
31
Host Model
A receiver joins the multicast group specified by DstAddr (Multicast), using IGMP. A potential sender starts sending RSVP Path messages to the DstAddr. A receiver application receives a Path message. A receiver starts sending appropriate Resv i t t di i t R messages, specifying the desired flow descriptors. descriptors A sender application receives a Resv message. A sender starts sending data packets.
32
RSVP Attributes
RSVP makes reservations for both unicast and multicast applications, adapting dynamically changing of group membership and routes. h i f b hi d t RSVP is simplex, it makes reservations for unidirectional d t fl idi ti l data flows. RSVP is receiver-oriented. The receiver of a data flow initiates and maintains the resource reservation used for that flow. RSVP maintains soft state in the routers, providing graceful support for dynamic membership changes and automatic adaptation to b hi h d t ti d t ti t routing changes. 33
RSVP Attributes
RSVP is not a routing protocol but depends upon present and future routing protocols. RSVP transports and maintains opaque state for traffic control and policy control control. RSVP provides several reservation models to fit a variety of applications applications. RSVP provides transparent operation through routers that do not support it it. RSVP supports both IPv4 and IPv6.
34