The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

Gaitonde Anandprasanna wrote:
> 
> I  carried out some experiments with the hello meesages in RSVP-TE but
> i find that the machines are  sometimes unable to respond fast enough
> to these Helo requrests. Perhaps the packets just get drooped as they
> come very fast.  So though my neighbour is alive and the communication
> is actully  active  the machine reports commmunication falilure. as it
> does not receive response even after 17.5 ms to its hello request.

The draft says that the hello interval and multiplier should be
configurable parameters.  If your neighbor switch can't keep up, then
you should configure a slower interval.

> So i feel that 5ms interval is too fast .

So choose something else.  5ms is not a mandatory value.  It is a
recommended default value for an operator-configurable parameter.

>  Also i went to the mailing list as u said to find out what Mr David
> Charlap had said. Following are a few of the lines from the mail :
> 
> A link with 500 inbound and 500 outbound LSPs, configured with a 30s
> refresh interval will generate 34 refresh messages per second (17 Path
> refresh, and 17 Resv refresh).  Given that refresh messages are around
> 100-150 bytes long, and hello messages are 12 bytes long, we're
> talking about generating 3400-5100 bytes per second for refreshes, vs.
> 684 bytes per second for hellos.  Even with the recommended a 5ms
> interval (worst-case of 200 messages per second), hellos would still
> only generate 2400 bytes per second worth of control traffic.
> 
> Please let me know how u arrived at the figure 17 Path refreshes and
> 17 resv refrwshes for 500 inbound and 500 outbound LSPs.

Simple arithmetic.  There are 500 LSPs in each direction, and the
refresh interval is set to 30s.  Assuming that refreshes are spaced more
or less evenly throughout the 30s, you get:

	500 / 30 = 16.666

I rounded up to 17.  What other figure were you thinking of?

> First point i like to make is that
> i think hello message is 20 bytes long.
> <Common Header> =  8 bytes
> 
> <Object header> = 4 bytes
> 
> <Actual Hello object contents> = 8 bytes
>       Total = 20 bytes.

You're right.  I forgot the common header.

> Also i did  not get how u came to the conclusion that hello messages
> will be 684 bytes per second of traffic. How did u get that value . I
> fail to understand??
>  What is the hello interval u are considering??

Again, arithmetic.  I really shouldn't have to explain this.

Using a 17.5ms interval (what was suggested by the person I was
responding to), you get:

	1 / 0.0175 = 57 hellos per second

At 20 bytes per message, you get

	57 * 20 = 1140 bytes/s

Using my previous (incorrect) figure of 12 bytes/hello, you get:

	57 * 12 = 684

> Yes with 5ms hello interval the control traffic with hello messages
> will be 2400 bytes per second,

Actually, 4000 bytes/s is the worst case.  Keep in mind, however, that
fewer messages will be generated if hellos are received on the
interface.  (You don't generate a hello message if you have received one
within your most recent hello interval).

> but that also is quite conmaprable to the control traffic of other
> Refresh messages that is 3400 bytes per sec .
> Isnt it?? and isnt that large enough????

You miss my point.

You can't replace refreshes with hellos.  Refreshing must continue
regardless.  The RSVP working group has a refresh-reduction draft, but
that is not related to hello processing.

My point is that the overhead from a 5ms hello timer (in terms of bytes
transmitted on the wire) is no worse than the overhead from normal RSVP
operation.

Now, you may not have sufficient CPU power to generate messages this
quickly, but it's not a big deal.  The interval is a configurable
parameter.  If your switch can not reliably process hellos with an
interval that fast, then choose a minimum interval that it can reliably
handle and use that instead.

-- David