Subject: Doubts regarding RSVP

From: "Rajesh Advani" <[email-masked]>
Date: Tue, 19 Jun 2001 17:32:58 +0500

Hi ,

I have a few (perhaps preliminary) doubts about the operation of RSVP .

1. RFC 2205 mentions that a session consists of multiple senders and 
receivers . And also , that a session is identified by dest address , 
port and protocol id . Are these things sufficient to identify all the 
hosts involved in the session , or is there a higher layer of session 
management involved above RSVP , which first establishes all the 
participants in the session before the QOS signalling is done ? 

2. I am not sure if RSVP is a good idea , if the transport layer offers 
connection-less service . Since RSVP is per-flow , and the packets of a 
flow in this case can take any path through the network , a large 
numbers of routers will maintain state information . Also since every 
packet may take a different path , and assuming every packet somehow 
does take a different path thru the network , a new path message will 
be sent over every new path taken , which I guess is a lot of 
overhead . 
Please let me know if this issue is addressed in any available 
documentation . 

Thanx in advance ,
Rajesh Advani . 

Sr Systems Engineer , 
Wipro Technologies ,
Bangalore , India .

---

From: Steven Berson <[email-masked]>
Date: Tue, 19 Jun 2001 07:22:52 -0700 (PDT)

> participants in the session before the QOS signalling is done ?

You are asking two separate questions.  The first is whether IP
destination address, destination port, and IP protocol is sufficient
to indentify a session.  The answer is yes.  The second question is
how do session participants organize themselves.  The answer is (as
you suspect) that there is a session layer.

> Please let me know if this issue is addressed in any available

RSVP has mechanisms to adapt to route changes. But as with, say TCP,
there is an implicit assumption that routes are stable in the short
term.  If in your network routes change with every packet then RSVP
will not be very effective.

Regards,
Steve