Subject: RE: help

From: "Gray, Eric" <[email-masked]>
Date: Wed, 4 Sep 2002 13:05:52 -0400

To add to what David has said, there is a predictable
transformation that is performed on a received RSVP
Path message before a corresponding Path messages is
sent downstream.  It is up to the implementation to make
the decision as to which is more optimal - storing a
version of the result of this transformation (with at
least some of the values to be re-transmitted), or 
repeating the entire transformation each time.

Optimizations that apply to your implementation may not
apply to others.  Numerous optimizations are not only
possible, but obvious.

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 9:51 AM
> To: IETF MPLS List
> Subject: Re: help
> 
> Harish Kumtakar wrote:
> >
> >    what i understood after reading RFC 2205 and 2209 is that, when a
> > node receives a PATH message it will store or update the info. contained
> > in the message into corresponding PATH state and then forwards the PATH
> > message (the message may be modified) to the next hop.
> 
> Actually, the outgoing message will always be different from the
> incoming message.  At the very least, the HOP object will be different.
> 
> It's misleading to think that a Path/Resv message is forwarded.  It is
> not.  It is intercepted and processed.  A new Path/Resv message may (or
> may not, depending on circumstances) be generated as a result of that
> processing.
> 
> >   my question is will that node stores the info that is modified by
> > it(in case the PATH message is modified) somewhere (i mean, in some
> > state?).
> 
> I'm not sure what you're asking here.
> 
> Every node must (at minimum) store everything from an incoming Path/Resv
> message.  It must compare subsequent messages with the stored data in
> order to determine if the subsequent message is a modification or a
> refresh.
> 
> What additional information it stores in order to generate and send any
> corresponding outgoing message is an implementation detail and is not
> specified by any standard.
> 
> -- David

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214