The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Question on RSVP Refresh Overhead Reduction (RFC 2961) and the use of ADSPEC
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 |
|