Subject: LSP failure detection

From: "Charles Smith" <[email-masked]>
Date: Tue, 24 Oct 2000 01:09:53 GMT

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
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

---

From: [email-masked]
Date: Tue, 24 Oct 2000 11:51:32 +0100

Chas, you asked:

> failure within a particular LSP?
	NH=> There are 3 main areas that need defect detection:
	-	nodal internal failures (which may or may not be traffic
affecting)
	-	user-plane failures (which are invariably traffic affecting)
	-	control-plane failures (which may or may not be traffic
affecting)

	1st is usually a proprietary issue for the manufacturer and is
usually not subject to standardisation (2nd and 3rd are however, since we
need to interwork).

	2nd has not really been addressed yet for the MPLS layers (each
nested LSP is a layer network in its own right)  Defects deteceted in server
layers below the lowest LSP (eg SDH) would result in AIS being passed, as
the Forward Defect Indicator (FDI), to the MPLS layers.  However, as yet the
MPLS layers do not have a method of recursing the FDI through their own
stack and on the ultimate client.  Some potential failure modes here are:
simple LSP breaks, swapped LSPs, mismerged LSPs (various scenarios) and
self-mismerged LSPs.  Hopefully some of these should(?) be rare, but if they
occur have implications ranging from simple avail/QoS SLA violation through
security (ie leaking VPN traffic into Internet say), censorship and
misbilling.  I am looking at definitions for these at present and the
entry/exit criteria and consequent actions.

	3rd has been addressed in some detail within the signalling (eg LDP,
RSVP) and discovery/routing (ie IGP) protocols.

	To date IETF has majored only on control-plane failures since a 1:1
routing congruence has been assumed with the user-plane.  This congruence
should not always be assumed however at the routing level (esp for flexible
solutions , and almost forced when considering technologies like the OTN),
and in any case different internal nodal processing is used so the user and
control planes can have different failure mechanisms where one plane is not
aware of failures in the other.  Further, when considering restoration,
user-plane detected defects need a close association with the control-plane
to instigate prot-sw actions. 

>  How can MPLS as a technology guarantee < 1 
	NH=> Why do you want restoration so fast?  The basic rule is that
the further you are aware from the duct the slower the restoration
required......if not, then the whole thing becomes not only unmanageable,
but not cost-effective and may be counter-productive.  For protocols
interfacing with applications one first needs to ask about the tolerance of
the applications.  I know of few applications that really need sub-1s
restoration (nice, but certainly not essential).  This is certainly true if
humans involved.  If data devices involved, then one should seriously
question the robustness of the application protocol....much cheaper to fix
this than to try and engineer faster and faster restoration as one moves
down the stack to the duct.  Further, the speed at which one can prot-sw is
also a function of the resolution of the defect detection mechanism
employed.  These can be very fast at the lower layer transport networks, eg
line level (such as loss of electrical or optical signal), but can be quite
slow at the higher layers nearer to applications, eg if a keepalive with a 1
second period was used then the best detection period one could
realistically use would be about 3 seconds (to have any sort of confidence
in avoiding false triggering). 
	Note:  When I studied the error distributions in networks (albeit
some time ago) I was amazed to learn how many 1-3s events there were and
from which the network self-recovered.  Not sure if still true today, but
(as I said) restoration at the top level should be determined by *real*
application needs......then one has to get faster as we move towards the
duct.  So don't start too fast at the top if you want nested prot-sw schemes
to work in a sensible/cost-effective manner.

---

From: [email-masked]
Date: Thu, 26 Oct 2000 20:11:27 +0100

Glen,

I, and few others, are working on an ID for MPLS user-plane OAM functions.
Progress has been slowed for several reasons.....not least of which is an
ITU SG13/Q6 mtg next month which will be looking at MPLS user-plane OAM
requirements.  I have prepared some papers for this which are the same
(though cut-up to suit ITU needs) since I want to try and keep ITU/IETF as
aligned as possible....or at least from our perspective wrt requirements.

If anyone wants a copy please let me know........note they have to get
formal BT approval (as indeed do all papers submitted to any stds fora), and
this will take about 1 week if all goes OK. 

Neil

> -----Original Message-----
> From:	Glen Turner [SMTP:[email-masked]]
> Sent:	Thursday, October 26, 2000 8:51 AM
> To:	[email-masked]'
> Subject:	Re: LSP failure detection
> 
> 
> > Detection:
> > 
> >         # Hardware notifies you of a failure
> >         # Software detects a failure through keep-alives, time-outs,
> etc...
> 
> As far as I can tell, currently defined IP keepalives don't really
> cut it.  For example most vendors have a minimum keepalive
> interval of 1 second and require 3 lost keepalives before
> marking the link as down.  Similarly for OSPF HELLOs.
> 
> Is there a special MPLS keepalive defined that allows subsecond
> detection of a forwarding failure?  Or is such a beast yet to
> be engineered?
> 
> -- 
>  Glen Turner                                 Network Engineer
>  (08) 8303 3936      Australian Academic and Research Network
>  [email-masked]          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised