RSVP The ReSerVation Protocol by Sujay koduri copyright: IPv6@BITS RSVP, Is it required? QOS Requirements?? Real-time applications Interactive applications are sensitive to packet delays (telephone) Non-interactive applications can adapt to a wider range of packet delays (audio, video broadcasts) Guarantee of maximum delay is useful copyright: IPv6@BITS QOS Required?? What is the problem? Different applications have different delay, bandwidth, and jitter needs Some applications are very sensitive to changing network conditions: the packet arrival time distribution is important Solutions Make applications adaptive Build more flexibility into network copyright: IPv6@BITS What is RSVP? Protocol that guarantees QoS It reserves resources in the internet (resources include BW and router buffers) Can also be used by routers to forward BW reservation requests copyright: IPv6@BITS Definition RSVP: It is a network control protocol that allows data receiver to request a special end to end quality of service for its data flows. Although it sits on top of the IP protocol stack, it is not a routing protocol It is rather an internet control protocol It is designed to operate with current and future unicast and multicast routing copyright: IPv6@BITS Principal characteristics Reservations for BWs in multicast trees Unicast is handled as a degenerate case of multicast It is receiver oriented ie… receiver of data initiates the process copyright: IPv6@BITS session Similar to RTP here also session consists of multiple multicast data flows Each sender is a source of one or more data flows Each data flow in a session has a same multicast address copyright: IPv6@BITS What RSVP is not? It does not specify how the network provide the reserved BW to the data flows Routers will actually provide the reserved BW (via priority scheduling etc). It is not a routing protocol (it does not determine the links) Also referred as signaling protocol. copyright: IPv6@BITS Heterogeneous receivers Some receivers can receive at 30 Kbps others at 128 Kbps and others at 10Mbps Suppose if a sender is multicasting a video to a group of heterogeneous receivers ,should the sender encode the video for 30,128Kbps or 10Mbps? copyright: IPv6@BITS solution Layered encoding is often suggested Sender need not know the receiving rates of all the receivers Only need to know the maximum speed of the receivers RSVP mainly deals with the heterogeneous receivers copyright: IPv6@BITS Reservation Merging (3) 50Kbs (7) 100 Kbs R1 Reservations merge as they travel up tree. (6) 100 Kbs R3 (2) 50Kbs (9) 60Kbs R4 (1) 50Kbs Receiver #1 R6 (8) 60Kbs Receiver #2 copyright: IPv6@BITS (5) 100 Kbs R7 (4) 100 Kbs Receiver #3 Call admission BW reserved by the router should not exceed the links capacity So a router first determines its down stream links can accommodate the reservation or not. RSVP do not define this admission tests. copyright: IPv6@BITS Local decision modules Admission control Policy control Proceeded only when these two are verified If either check fails RSVP will return an error. copyright: IPv6@BITS Soft state There is a timer associated with every reservation of BW stored in a router It should be periodically refreshed. Same principle is used for routing tables where the entries are refreshed by newly arriving data packets copyright: IPv6@BITS Reservation styles 1.Wildcard Filter (WF) Style: It creates a single reservation shared by flows from all upstream senders WF(*(Q)) *- represents the wildcard sender selection Q-flow spec 2. Fixed Filter (FF): It creates a distinct reservation for data packets from a particular sender. FF(S(Q)) copyright: IPv6@BITS 3. Shared Explicit (SE): It creates a single RSVP Protocol Mechanisms C A Router B B’ D D’ copyright: IPv6@BITS Describing and Identifying a Flow Flow spec defines traffic parameters Traffic parameters: bandwidth, buffering requirements Uses token bucket specification Filter spec identifies packets in flow Simplest filter: Source, Dest address/port pair Data filter: classifies packets according to contents copyright: IPv6@BITS Resource Reservation Senders advertise using PATH message Receivers reserve using RESV message Flowspec + filterspec + policy data Travels upstream in reverse direction of Path message Sender/receiver notified of changes copyright: IPv6@BITS Components of path Each Path message contains the following information: 1.Sender Template: Describes the format of data packets that the sender will originate. 2.Sender T- spec: Defines the traffic characteristics of the data flow. 3.Adspec: Used for OPWA (One Pass with Advertisement) copyright: IPv6@BITS Killer reservation problem It arises when already there is a Q0 in place and if another receiver makes a larger Q1>Q0, the result of merging may be rejected by some intermediate node. Blockade State: A blocked state in a node modifies the merging process to omit the offending flowspec. copyright: IPv6@BITS RSVP:Functional Specifications ---------------------------------------------------------Vers | Flags| Msg Type | RSVP Checksum --------------------------------------------------------| Send_TTL | (Reserved) | RSVP Length --------------------------------------------------- copyright: IPv6@BITS Functional Specifications… 1.Vers: Usually 1. 2. Flags: 4 bits 0x01-0x08:Reserved. 3. Msg Type:8 bits 1=Path 2= Resv and so on. 4. RSVP Checksum:16 bits 5. Send_TTL:IP TTL value with which the message was sent. 6. RSVP Length: 16 bits- includes the common header and variable length objects that follow. copyright: IPv6@BITS •Objects: ---------------------------------------------------Length (bytes) | Class-Num | C-Type ---------------------------------------------------// (Object contents) ---------------------------------------------------- copyright: IPv6@BITS // •Objects… 1. Length: 16 bit containing the total length in bytes. 2. Class-Num:Identifies the object class. 3. C-Type: Object type , unique within each object class. The maximum object content length is 65528 bytes. The Class-Num and the CType fields may be used together as a 16 bit number to define a unique type for each object. copyright: IPv6@BITS RSVP routing problems If route changes, reservation must be made along new route New reservation takes time to setup New reservation might fail Old route could still be working fine Reservation failure Primary route has inadequate bandwidth although secondary has enough copyright: IPv6@BITS