Subject: RE: LSP failure detection

From: Adrian Farrel <[email-masked]>
Date: Wed, 1 Nov 2000 22:19:09 -0000

A couple of observations to add to Curtis' good response.

>> Can someone please explain the mechanisms involved to detect 
>> a node or link failure within a particular LSP? How can MPLS 
>> as a technology guarantee < 1 second LSP failure restoration 
>> (contrast to SONET)? I need to understand exactly how a 
>> failure is detected, how the backup path is activated or how 
>> fast re-route directs the LSP around the link or node failure.
>> 
>> I am just a marketing guy who has read the drafts and still 
>> needs the engineers to explain the concepts :-)
>
>MPLS is not a link layer.  MPLS typically runs over POS (PPP over
>SONET).  

"Typically" may be stretching a point :-)

>In this case you have linear SONET, no protection, but you
>have the capability to detect failure.  PPP can also in principle
>provide LQM but in practice no one offers this (yet) because it
>requires (feasible but non-trivial) hardware support to be accurate.
>
>Note that if you run MPLS over 1GbE or 10GbE or other link layer then
>you lose the SONET failure detection.
>
>If you don't have link layer notification of failure then you have IGP
>hello processing and RSVP refresh, both of which are slow.

There is also RSVP Hello, which is somewhat faster.  The "recommended"
value in the draft uses a timer of 5ms and an interval count of 3.5
giving failure detection in 17.5ms.  Not speedy, but not hugely slow.

>The second part of the two part problem is completing restoration
>after an error is detected.  For some implementations of link
>bundling, the bundle of N links now has N-1 capacity and 1) usually no
>immediate restoration is needed, the loss of capacity is signaled and
>any ingress may opt to do a minimally disruptive reroute (using
>make-before-break there is no loss but delay discontinuity and a
>possible brief period of reordering) or 2) if capacity of N-1 is
>insufficient the lowest priority LSP (highest numeric setup priority)
>are preempted.  Here you have 1) local-protect as an MPLS feature
>where immediate restoration is initiated at the point of failure and
>the local-protect bit is dropped in the RESV to indicate that
>protection is no longer available because the restoration path is
>being used, 2) PathError messages and IGP adjacency loss sent as
>feedback to the ingress if local-protect is not in use.  The ingress,
>having received PathError can use a precomputed and presignaled backup
>if this feature is enabled.  The backup should be available if it was
>disjoint and SRLG information was accurate.  IGP adjacency loss
>indicates what link is at fault and is used if either there was no
>precomputed backup or the SRLG information was not accurate and the
>backup went down simultaneously.

Most of this applies only to bundled links, but your second 2) is of
relevance in all cases.  Some people consider that PathErr propagation
may be too slow in this case since the message will be handled by the
RSVP code on each intermediate LSR.  The new Notify message in 
draft-ietf-mpls-generalized-signaling is sent direct to the target 
(ingress) LSR and need not be intercepted by intermediate LSRs (and
need not follow the path of the LSP if this is a sub-optimal route).

This should provide a (slightly?) faster method of propagating LSP
failure information.

Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: "Wayne" <[email-masked]>
Date: Thu, 9 Nov 2000 00:59:49 +0800

I think the RSVP hello is one of the enhancements from a vendor. Not a RFC
as the moment. Is that true? Though the hello packet is small, 17.5ms seems
a bit aggressive for a large network with a lot of RSVP enabled
routers/links.

Any thought?

Wayne

---

From: David Charlap <[email-masked]>
Date: Wed, 08 Nov 2000 13:17:39 -0500

Wayne wrote:
> 
> I think the RSVP hello is one of the enhancements from a vendor. Not a
> RFC as the moment. Is that true? Though the hello packet is small,
> 17.5ms seems a bit aggressive for a large network with a lot of RSVP
> enabled routers/links.

It's not part of the RSVP working group at all.  It's not
vendor-specific, either, however.  It's part of the RSVP-TE draft, and
is part of the MPLS working group.

As for 17.5ms, where do you get that number?  I didn't see it in the
draft anywhere.  I found a 5ms interval, but that's not a requirement -
it's a recommended default value for a user-configurable parameter.

That aside, 17.5ms isn't that terrible.  It's a worst-case of sending 57
hellos per second.  This is substantially less overhead than not using
hellos.

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.

And, of course, the amount of bandwidth consumed by hello traffic won't
increse as the number of LSPs increases.

-- David