Subject: Re: LSP failure detection

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Nov 2000 11:07:18 -0500

In message <[email-masked]>, "Charles Smith" writes:
> MPLS list:
> 
> 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 :-)
> 
> Cheers.
> 
> Chas

MPLS is not a link layer.  MPLS typically runs over POS (PPP over
SONET).  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.

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.

Curtis

---

From: Chris Flores <[email-masked]>
Date: Wed, 8 Nov 2000 13:31:16 -0600

---Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: Wednesday, November 08, 2000 12:18 PM
To: [email-masked]
Subject: Re: LSP failure detection

--<snip>
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.
--<snip>

from section 5.3 of 'draft-ietf-mpls-rsvp-lsp-tunnel-07.txt', the default
interval for periodically generating Hello messages is 5ms. Furthermore, a
node must presume that it cannot communicate with another neighbor if it has
not received 3.5 instances of a Request or ACK. Thus, 5ms * 3.5 = 17.5ms.

Best regards.

Chris

---

From: [email-masked]
Date: Thu, 9 Nov 2000 16:35:34 -0000

Hi Glen,

	You wrote <snipped>:
>   We want to run VoIP across this link, so we need sub-second
> restoration.
	NH=>  Voice is one application that certainly does not need a sub-1s
restoration time.  Think about it.  If a call goes dead are you really going
to hang-up in less than 1s?  This was indeed the historical background as to
why the unavailable state threshold was specified as 10 consectutive SES
(severely errored seconds) in the ITU about 15 years ago (G.821).  There may
be PSTN *signalling protocols* that require faster restoration (I believe
some old USA systems have 100ms timers?...but I am not sure).......but the
answer here is to fix the application if possible rather than spending huge
effort/cost of getting unecessarily fast restoration.  If we really need
these restoration speeds, then before blindly going for them can we please
make sure we have captured the *real* application requirements that are
driving them.  So let's see them listed.

	neil

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 9 Nov 2000 10:45:05 -0800 (PST)

Hi Glen, Neil,

> > What is the defect entry criteria on these rapid Hellos?  I would strongly
> > suggest that if anyone is thinking of trying to get very fast reactions
> > times to be used for restoration they should be very careful.  In my view
> > restoration times above the L1 (ie PDH/SDH/OTN) should not be faster than
> > somewhere in the region of 2-3s.....otherwise you are going to get a lot of
> > unecessary hits when the event would of have self-healed.  And if anyone is
> > using some multi-level priority bumping scheme then (esp at highish
> > utilisations) this can lead to significant network disruptions felt far
> > beyoind the initial event source.

Two related points: first, if an LSP (for whatever reason) runs over
unprotected links (say GigE), you would want it to recover as fast as
possible, because L1 just cannot recover.

Second, a unified control plane and a common view of the topology is
needed to make these kinds of decisions.  Say the above LSP runs over
4 segments, two of which are SONET rings, one of which has link local
protection (a la LMP) and the last is unprotected.  The ideal solution
is to protect the last segment with MPLS fast reroute, and to leave
recovery on the other segments to L1 mechanisms.  But to get such fine
grain protection schemes, and to *not* get the "unnecessary hits" from
double protection (as well as the network inefficiency) requires that
MPLS knows what L1 is doing.

I agree with the high order bit, though: having fast protection at
multiple layers is asking for trouble.

> One of the reasons for improving the reaction time, and the OAM performance
> in general, is to dispense with protection at the SDH layer and move protection
> into MPLS.

Absolutely.

> MPLS also allows a wider range of topologies -- SDH is quite limited and
> can't implement all the desirable layer two topologies without having
> huge amounts of idle bandwidth.

Also a wider selection of L1/L2 (what if some of the hops were GigE?).

On a different note:

> restoration time.

Don't know about this.  I do know that we (and other vendors) have
a lot of customers asking us for sub-second (even 50ms) MPLS fast
reroute.  Even if (big if) voice doesn't need sub-second recovery,
there will be applications that do, and many find the option to use
MPLS fast reroute over GigE or unprotected SONET/SDH gear appealing.

Kireeti.

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 9 Nov 2000 13:47:35 -0800

[..]

> MPLS fast reroute over GigE or unprotected SONET/SDH gear appealing.

Is this 50 ms for a source-based restoration of an end-to-end LSP
or for local repair at the point of failure?  If it is for the 
former, it seems unrealistic, since the failure notification needs
to propagate all the way to the source (could be several hops
away) and the source needs to act on it.  50 ms is not a whole
lot of time.

-Anoop

---

From: [email-masked]
Date: Fri, 10 Nov 2000 17:16:29 -0000

> [email-masked] wrote:
> 
> > Every time we have studied prot-sw in BT we come to the same
> > conclusions......minimise the layers at which prot-sw is
> deployed....ideally
> > just 2:  L1 and fast, applications interfacing and (relatively) slow.
> And
> > as I said in a few prior mails on this topic.....don't go too fast at
> the
> > application interfacing level.
> 
> Hi Neil,
> 
> I hope you don't mean "application".
	NH=> No, I didn't....I meant the network layer that interfaces with
the application.  So, for POTS (ie PSTN) that would be a 64k cct-sw network,
FR and ATM are two other examples, and so is IP.
	BTW - these have to be minimised to avoid same application I/W
between different native technology bases.

> We've tried modifying BIND, a DNS application, to rapidly detect
> a failing upstream server and to select an alternative.  The
> statistics are complex, so the implementation is dense.  We've
> had a professor design the statistics and the code is solid, but
> we've still had endless trouble in the 5 months that we have
> been using the code.
> 
> 'Rapidly' above means 'more than 0.5s late', the idea being
> that a failed DNS server shouldn't add more than 1s to a DNS
> lookup.
> 
> Pushing protection up to the Application Layer, if this is
> what you mean, is too high up the protocol stack.
	NH=> Wherever possible the end applications should take note of the
typical behaviour of networks and (the code) be written to live with normal
imperfections......so this is loss, errors, delay.  If the application
cannot live with these 'normal' imperfections then there are 2 options:
	-	upgrade the whole network
	-	do something for *that* application by special treatment
within the network, eg provide several routes and select on integrity of
rx'd data.
	The answer depends on the how frequent that application is against
other types of (application) traffic.  If maybe 90% of traffic types can
live with the normal network behaviour, then the answer is to take the 2nd
option....otherwise the operator goes out of business.  Basic ecomonics at
play.