Subject: Questions in RSVP-TE refresh reduction.

From: "Arumugamr" <[email-masked]>
Date: Mon, 5 Aug 2002 12:56:55 +0530

Hi,

I am not sure, whether this is the right forum to ask the question, but
since the RR feature is very much needed for the MPLS-RSVPTE I am posting
this question.

1. RFC 2961 states two methods of refresh overhead reductions namely the
Bundle and SRefresh mechanism. If an implementation supports RR, then it has
to support the both extensions.  SRefresh has an advantage over Bundling in
terms conserving bandwidth and processing overhead.  Is there any specific
scenario, wherein the Bundle message is advantageous over SRefresh message.

2. RFC 3209 section 5 Hello extn states that the Hello message can be
included in the Bundle message. The usage of hello is for rapid node failure
detection, wherein the Bundle message is for reducing the refresh overhead.
Eventhough thousands of refreshes are sent to the neighbour there will be
only one hello message sent to the neighbour.  Also the delay in hello being
sent can result in the other node to assume the peer has reset.   Is there
any specific reason behind the hello messages being bundled.

3.  In RFC 2961 section 4.5 states that

"If a Path
   or Resv message contains the same Message_Identifier value that was
   used in the most recently received message for the same session and,
   for Path messages, SENDER_TEMPLATE then the receiver SHOULD treat the
   message as a state refresh.  "

With respect to the above statement, I have the following questions.

   a)  In Accordance to RFC 3209, assume Refreshes with MsgIds (SRefresh
probably) are going between Ingress/Egress and its immediate neighbour. Also
the refresh messages carry RRO's.  When  RRO too large for MTU error message
is received, the Ingress(In case of PATH msg)/Egress(In case of Resv
message) should have to stop sending RRO's. Now the question being the
Refresh message without RRO will be send with the same MsgId, which was used
for the previous session (or) will be a new one.
         Since an implementation on receiving a message with the same MsgId,
Session and SenderTemplate, if it treats it as the refresh and fails to
updates the RRO removal indication, the node that generated the error will
still retransmit the error msg. Which MsgId should be transmitted Old/New.

  b)  Also in the RRO's flags may toggle because of some local failure
detection & recovery process. In these cases the MsgId Should be a Newly
generated/Old one being retransmitted..

I welcome your comments

Thanks and Regards
Arumugam R

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: David Charlap <[email-masked]>
Date: Mon, 05 Aug 2002 09:52:14 -0400

> scenario, wherein the Bundle message is advantageous over SRefresh message.

The two message types serve different purposes.

Bundle messages reduce IP packet processing overhead in the stack.  On 
some platforms, the act of looking in the IP header to determine whether 
it is to be processed locally or not (by comparing destination address 
and looking for the router alert option) can consume significant CPU 
resources.  Bundling messages together reduces this overhead by reducing 
the number of packets sent/received.

SRefresh, on the other hand, has to do with the CPU and bandwidth 
overhead of having to retransmit all Path and Resv state messages.  IMO, 
this factor contributes much more to the RSVP's scalability issues than 
Bundle messages do.

If you set the "RR capable" bit in your common header, then you must be 
prepared to support both types of incoming messages.  You do not have to 
generate both as outgoing messages, however.

> any specific reason behind the hello messages being bundled.

Just generality.  Any message, other than another Bundle, may be 
bundled.  It doesn't say you have to do this, though.  Personally, I 
agree with you - that you would not be able to get the rapid response 
necessary if Hello messages are bundled.

A router receiving RSVP messages may choose to prioritize messages in 
the IP stack, in order to allow Hellos to be processed ahead of other 
messages.  It may also choose to implement Hello in a line-card's 
firmware, in order to improve response time.  Including Hello in Bundle 
breaks both of these optimizations.

> for the previous session (or) will be a new one.

If the message changes, then you must generate a new message ID. 
Otherwise the neighbor may ignore your changes.  It doesn't matter if 
this is something really significant like a TSpec or something less 
important, like an RRO.

> still retransmit the error msg. Which MsgId should be transmitted Old/New.

No.  An SRefresh does not force the neighbor to re-transmit any errors 
that the original message caused.

If the error message was something serious (like bad TSpec or 
something), then corresponding state was never installed - meaning an 
SRefresh of it will result in a NACK (since the message ID doesn't match 
any installed state), and a normal refresh will result in a re-attempt 
to install that state, since there's no way of knowing that the message 
ID was previously used.

If the error message was something that doesn't prevent state 
installation (like an RRO growing too large), then either kind of 
refresh will simply have no effect.  Which is as it should be - why 
should you be continuously spewing out Notify messages?

> generated/Old one being retransmitted..

Again, if you are changing any part of the message, then you must 
generate a new message ID.  If you don't then your changes may be 
ignored by the router that receives the message.

-- David