The MPLS WG Archive

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

neil.2.harrison@bt.com wrote:
> David Charlap wrote 19 July 2002 15:19
>>
>> If you do all of these, then you can no longer detect or 
>> handle failures that don't cause carrier to be lost in the data-plane.
> 
> Can you elaborate what you mean by this please David, and against which
> particular user-plane framing structure you are referring to (ie MPLS or SDH
> or OTN) and whether you are referring to cases where the signalling is
> in-band or out-of-band wrt to the traffic's user-plane.

Simple.

Layer-1 protection features will continue to work.  If someone pulls a 
fiber, carrier will be lost and the interface will go down, and RSVP 
will handle that.

But soft-state also detects software failures.

Suppose the RSVP protocol crashes on a box.  The interface remains up. 
Packets continue to arrive, but they aren't processed.

Classical RSVP will detect the loss of refresh messages and will start 
deleting state as it times out.  If you increase the refresh interval or 
multiple, then that amount of time will be much greater.  With a default 
interval of 30 seconds and a default multiple of 3, state will time out 
in 1.5 minutes.  This is already too slow for many situations.

The other thing that soft-state gets is reliable delivery.  If a Path 
message is sent and lost, it will be retransmitted at the next refresh 
interval, and the LSP should continue coming up at that point.  If the 
interval is greatly increased, it will take a long time before this 
retransmission happens.

The Hello part of RSVP-TE solves the first problem.  When Hellos are 
used, a failure will be rapidly detected regardless of the refresh interval.

The Refresh Reduction RFC solves the second problem.  The Message ID 
part of that RFC will cause trigger messages to be rapidly retransmitted 
until they are acknowledged (according to an exponential backoff algorithm.)

Which means it is safe to use a large refresh interval when both Hellos 
and Refresh Reduction are in use.  But not if they aren't.

-- David