Subject: RE: [NSIS] Requirements draft and RSVP analysis draft

From: [email-masked]
Date: Thu, 22 Nov 2001 10:11:10 +0200

Marc,

You wrote:
> > - About soft state: I think it needs to be reworded to imply 
> > that RSVP uses "explicit" refresh messages. This can actually 
> > be done implicitly. "Soft" state is not a problem in my 
> > opinion. If any protocol creates a state for the transient 
> > packet session inside the network, the state has to be soft. 
> 
> I'm not sure which definition of soft state you are using. I 
> define soft
> state as state which needs to be explicitly refreshed, or otherwise it
> will expire, i.e. the wording "soft state" already implies that RSVP
> uses explicit refresh messages. That is also the definition 
> used in RFC
> 2205. Everything else is hard state in my opinion.
> 

One option is to mandate implicit state refresh based on the forwarding
plane traffic. Maybe earlier this has been thought to be a burden for the
forwarding plane. But if we agree that for accounting reasons the forwarding
plane will need to count the bytes/packets received/forwarded on a
reservation anyway, implicit refresh becomes very cheap option. All the
control plane will need to do is to check if there has been any activity on
a flow since last checked before discarding the state.

Anyway, IMO soft state is defined by the fact that the state is
automatically discarded unless refreshed. The refresh need not be an
explicit signaling message. However, the endpoints could inject explicit
refresh signaling messages is they have not sent any packets recently, but
still want to keep the reservation.

Regards,

	Jarno

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Nemeth Krisztian <[email-masked]>
Date: Thu, 22 Nov 2001 15:44:06 +0100 (CET)

Hi Jarno,

What you'd lose this way is the protection agains route changes. With
"explicit refreshes" the same reservation message is repeated, as the
first one. Thus if the route changes, at the next refresh period QoS
guarantees will be back (if there are enough resources there). This is not
possible with the implicit method. (Well, on the other hand RSVP currently
handles route changes explicitely.)

Best regards,
Krisztian