Subject: Question on RSVP Refresh Overhead Reduction (RFC 2961) and the us e of ADSPEC

From: "Uzunalioglu, Huseyin (Huseyin)" <[email-masked]>
Date: Tue, 26 Mar 2002 17:19:54 -0500

Hi all

I have a question about RFC 2961 and the use of ADSPEC object in the RSVP
Path message.

RFC 2961 describes a number of mechanisms that can be used to reduce the
processing overhead of RSVP refresh messages. One basic idea, to my
understanding, is that if there is no change in the state of an RSVP
reservation, use the so-called "summary refresh (Srefresh) extension" to
refresh the RSVP state. The Srefresh consists of a MessageID that is
basically an index to an RSVP state advertised earlier. This way, the RSVP
message does not need to carry all the objects for the RSVP state, and the
receiving node of the RSVP message does not need to process all these
objects. The receiver just assumes that the "state" is valid and refreshes
the state. However, if there is a change in the RSVP state, the sending RSVP
node refreshes the whole state by using all the objects related to the RSVP
state.

One of these RSVP objects is the ADSPEC object which might be used in a PATH
message to figure out the characteristics of the end-to-end path. The
characteristics include "available bandwidth", some Intserv Guaranteed
Service parameters, etc. After looking at RFC 2215, it wasn't clear to me
what exactly is "Available BW" advertised in the ADSPEC. At a given node, is
this the physical available bandwidth like link capacity? or is it the
amount of bandwidth not allocated to RSVP flows so far? Or is it some
"measured" available bandwidth?
(For a given definition, the value in the ADSPEC object is updated at every
hop along the RSVP path using the "min" operation.)

Then here comes my queston that relates RSVP Refresh Reduction to the ADSPEC
object. Assume that the information advertised in the ADSPEC changes quite
often. This can happen if the available BW or the other Intserv parameters
represents a "measured" quantity. It can also happen due to a large number
of LSP set-up/resize activity going on at a large bandwidth link. So, if the
ADSPEC object value changes too often, will the Summary Refresh extension be
still beneficial? I mean, if the ADSPEC object changes very often, than
Srefresh may not be used much since the router need to use a trigger message
rather than a refresh message. Is there a way to update only the ADSPEC
object but don't advertise the objects that did not change?

I would appreciate any information/comments on this.

Huseyin Uzunalioglu

Huseyin Uzunalioglu
Performance Modeling
Bell Labs
Lucent Technologies