Subject: RE: Soft State

From: "Ramesh Pabbati (Exchange)" <[email-masked]>
Date: Tue, 30 Nov 1999 09:40:08 -0800

In Winsock implementation the receiver state is kept in the RSVP service
(daemon). As long as there is a matching PATH state RSVP service on the
receiver system will send out a RESV message with no further action from the
receiving application. So if the PATH state times out on receiving machine
RSVP service tears down the PATH state and sends a notification to the
receiving application that there are no senders in the session. 

But when the PATH message is received again by the receiver, RSVP service
will send out a RESV message at once. Also RSVP service notifies the
receiving application that there is a sender.

I am quite sure the ISI implementation has done the above all along.

Ramesh
-----Original Message-----
From: Ashok Narayanan [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 12:16 AM
To: Andreas Terzis
Cc: Maria Elena Villapol; RSVP
Subject: Re: Soft State 

Andreas Terzis writes:
 > 
 > 
 > On Tue, 30 Nov 1999, Maria Elena Villapol wrote:
 > 
 > > Hi everyone,
 > > 
 > > I am modeling RSVP. My model is based on RFC 2205. I found a possible
 > > problem of soft state approach in RSVP.
 > > Given the following scenario:

<snip> 

 > I would say that this is an issue regarding the RSVP's API to 
 > applications rather than the protocol itself. In any case, in the
 > scenario you described the API could report the loss of reservation
 > to the application when the Path state expires in the first place 
 > and would later report the re-establishment of Path state so if
 > the application is still interest it could once again reserve 
 > resources.

The other way in which an implementation could handle this is to have
RSVP state for all locally requested paths/reservations. If an
application requests a reservation from the RSVP API, this can be
stored in the RSVP daemon/process/whatever for future processing. When 
the path in question comes in, this can trigger the waiting
reservation which can then be installed and forwarded. This way, the
client API is simplified and (more importantly) the headache of
synchronization is hidden in the API and is not exposed to the client.

-Ashok

-- 
--- Asok the Intern ----------------------------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387