The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] help
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:David.Charlap@marconi.com] > 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. egray@celoxnetworks.com 508 305 7214 |
|