Transcript Overview of RSVP

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