Subject: MPLS protection switching

From: [email-masked]
Date: Wed, 19 Apr 2000 10:58:58 +0200

Hello folks,
I have to make a study about MPLS protection switching.
Could anyone help me by telling me which are the IETF drafts dealing with this
topic?
I know that there are two drafts:
draft-theimer-mpls-oam-requ-00.txt
draft-makam-mpls-protection-00.txt
Are these the only ones? Which direction is IETF moving to about this topic?
I know there is also a draft Recommendation in progress by ITU-T Q6/SG13
(provisionally numbered Y.17oam). What about that?

Thanks to all in advance.
Cheers,
Luca.

---

From: [email-masked]
Date: Wed, 19 Apr 2000 12:14:06 +0100

Note - I have copied my response to the list since I am sure there will be
others out there, especially operators, who are thinking about OAM issues
that we need to address in MPLS.

Hi Luca,  You wrote 19 April 2000:

	I have to make a study about MPLS protection switching.
	Could anyone help me by telling me which are the IETF drafts dealing
with this
	topic?
	I know that there are two drafts:
	draft-theimer-mpls-oam-requ-00.txt
	draft-makam-mpls-protection-00.txt
	Are these the only ones? Which direction is IETF moving to about
this topic?
	I know there is also a draft Recommendation in progress by ITU-T
Q6/SG13
	(provisionally numbered Y.17oam). What about that?

Some colleagues and I in BT have been studying the OAM requirements for MPLS
and we are aware of the documents you mention above.  Additionally, I would
suggest you need to look at the following IDs (need to check if these are
latest versions):
(i)	draft-ietf-mpls-label-encaps-07.txt
(ii)	draft-owens-te-network-survivability-00.txt
(iii)	draft-chang-mpls-path-protection-00.txt
And as a good general summary of MPLS TE requirements:
(iv)	RFC2702

The ITU (SG13) have not started work on MPLS OAM requirements in earnest
yet, and the kick-off mtg on Y.17oam is scheduled for 26-30 June 2000 in
Ottawa.  In my opinion there are some fundamental problems with SG13's
previous OAM work for ATM (in I.610), and I would like to see better
solutions emerge for MPLS.  For example, there is no OAM tool to detect
certain misbranching defects (ie unintended instances of connectivity such
as swapped connections, mismerging, looping, etc.), the OAM tool to diagnose
misbranching is not completely reliable, the complexities of various CC/PM
OAM cells and their dependency on user-plane traffic activity make the
algorithms to define availablity state changes of trails too complex (and >8
years on are still unsolved), etc.  Hopefully, we can learn from these
'problems' and improve the OAM efficacy of MPLS.

However, to achieve this, our analysis to date has revealed some issues with
MPLS which we believe need addressing.  The 1st thing we ought to do is have
an agreed set of OAM requirements MPLS.  I have drafted such a set of
requirements (mainly for internal discussion at present), which I have
termed 'OAM principles'.  These draw on my experience with dealing with OAM
for other layer networks (and in particular ATM).   I am also already in
discussion with Vishal Sharma (one of the Tellabs authors of some of the
above IDs) on these matters.  I have re-produced the main points from the
OAM principles paper below for anyone else who is interested in this area:

Layer independence:	Each layer network must have its own OAM
functionality to detect failures and abnormal performance that is not
dependent on a specific server or client layer technology.  This is critical
to ensure that layer networks can evolve (or be removed) without impacting
other layer networks.

End-to-end (E2E) and per domain monitoring capability:	It should be
possible to simultaneously measure the E2E and per domain (a specific case
of subnetwork partitioning) performance.
Note - A key point about performance metrics (such as errored-PDUs,
lost-PDUs, PDU temporal arrival variance, etc) is that they are only
relevant when the 'connection' is in the Available State.  Therefore,
connectivity status is the primary in-service metric that must be identified
at all times.

Defects:	All the major defect conditions must be identified with
in-service measurable entry and exit criteria, and all consequent actions
specified.  If possible, the entry and exit criteria should be temporally
harmonised as far as possible to simplify defect state processing at trail
termination points.  Attention should be paid to relating the defect
entry/exit criteria to 'short-breaks', which are generally accepted as a 3-9
periods of gross signal disturbance from which the network may self-recover.
If the event lasts for >=10s this is the normally accepted threshold for
entering the Unavailable State - see next item.

Availability:	The most important performance metric of a trail (or a
subnetwork partition thereof) is availability.  It is therefore critical to
define the entry and exit criteria for the Available State and understand
how these relate to the stopping/starting of the aggregation of available
state performance metrics such as PDU loss (noting that this may be
effectively applied at an earlier point to preserve the integrity of the
available state metrics, eg after 3s say, which marks the onset of (at
least) a short-break).

Decoupling of user behaviour from connectivity assessment:	It is
critical to remove user traffic behaviour from connectivity assessment.  In
practical terms, this means decoupling user behaviour from all defect and
(the dependent) available state entry/exit criteria.

Forward and Backward Defect Indicators:	The node in the layer network which
detects a defect (sourced from within that layer) must apply a well-known
Forward Defect Indication (FDI).  In the majority of current WAN
technologies such a signal has been termed AIS (Alarm Indication Signal).
At the trail termination point (or, if applicable, any subnetwork
termination point) the FDI signal must (i) create a complimentary Backward
Defect Indication (BDI) (which is removed at the upstream trail (or
subnetwork) termination point) and (ii) map the FDI signal from the server
layer to the FDI signal of the client layer(s) as part of the adaptation
process.  The two primary purposes of the FDI are (i) to suppress downstream
and client layer alarms (so that there is not an 'alarm explosion' and so
Operations Personnel can correctly target the real defect location source),
and (ii) to allow correctly targeted restoration actions at the right
network layer (be this between different technology layers (eg SDH/ATM) or
within the same technology layers (eg ATM's VP and VC layers, or 'N' nested
MPLS layers).  Two secondary purposes of FDI (and indeed BDI) are (i) to
allow correct processing of available state performance metrics and (ii) to
inform the ultimate end-system/customer applications that the connection is
no longer functioning correctly and to take appropriate action, eg in the
case of voice perhaps mute the speech path.  From the preceding we should
note that, if possible, the FDI/BDI signals should provide information on
the defect location and type (such information is very useful to the lead
operator for many reasons).

Trail Trace:	A key characteristic of layer networks is that they must
have their own (within layer) globally unique addressing structure that
defines the layer network access points.  However, within the layer network
relative addressing may be used (which only has to be unique per interface)
as a mechanism to provide fast route forwarding of PDUs, eg VPI/VCI of ATM,
DLCI of FR, the 'label' of MPLS.  When relative addressing is used there is
danger of misbranching defects.  These cover a variety of connectivity
failures, including simple loss of continuity, swapped connections,
unintended merging, self-merging (ie routing loops), etc.  Unless detected
and corrected, the consequence of such defects can be very severe for an
operator, ranging from simple SLA availability violation through to more
serious security, censorship and misbilling implications.  The diagnosis (eg
detection and location) of such failures is difficult unless a globally
unique trail trace address is periodically transmitted (from trail source to
trail sink) to detect these failures.

Customers should not be used as defect detectors:		Wherever
possible, the OAM tools should not require that customers have to act as
failure detectors. 

OAM functionality under fault conditions:	Under fault conditions a
layer network cannot be expected to behave in a predictable manner.
Therefore care should be exercised when specifying and using OAM tools that
require a reliable layer network to function in a predicable manner for
fault diagnosis.

Based on the above principles I have drafted further papers which propose
solutions for MPLS.  However, I am not sure whether to publish these
solutions or not since they are dependent on certain changes to the current
MPLS specification.....and I am not sure if these could be accommodated.
For example:

To detect all the defect types that could occur in MPLS we need sort form of
LSP keepalive that contains an absolute trail source address and which is
periodically sent to the LSP trail termination.  But how do I differentiate
such an OAM keepalive pkt from the normal user-plane traffic?  The simplest
and most obvious way was if the MPLS header contained some form of payload
identifier field.  Assuming most of us agreed this was required, then 2
possibilties for this could be:
(i)	parse the 20 bit label field (into say a 16bit 'true' label and a
4bit 'payload ID' field);
(ii)	make some of the TTL codepoints reserved for a payload ID function.
The latter might be more palatable, especially noting that:
-	it is not clear to me that it makes architectural sense to 'guess' a
client number of IP hops in a lower layer network;
-	self-mismerging (eg due to routing loops) is only one type of
misbranching defect that can occur......the others (noted previously) don't
seem to have been recognised as yet, and so we have no OAM techniques to
deal with them.  Note that the IP layer does not have this issue since each
pkt contains an absolute source address which, by definition, protects
against such misbranching defects, and so only self-mismerging defects need
an additional detection mechanism via the TTL function.  However, if we sent
a keepalive containing a trail source addresses on the LSPs then we could
detect all the misbranching defect cases (including self-misbranching).

I will end at this point since I have have covered the main points I wanted
to bring to your attention.  However, there are other issues, such as 'how
to target the correct restoration level when LSPs are nested?' that need to
be considered at some stage.

Best regards, Neil

---

From: Vishal Sharma <[email-masked]>
Date: Wed, 19 Apr 2000 11:13:15 -0400

Hi Luca,

Perhaps in place of draft-makam-mpls-protection-00.txt (which is old, Oct.'99), you should look at 
the later
version of the draft:

(i) draft-makam-mpls-recovery-frmwrk-00.txt,
which merges some earlier drafts from Nortel, and some recommendations from ATT to produce a
more comprehensive document.

In addition, you may also want to look at
(ii) draft-shew-lsp-restoration-00.txt
(iii) draft-swallow-rsvp-bypass-label-00.txt.
(iv) draft-haskin-mpls-fast-reroute-03.txt.
All of these drafts are available from the IETF drafts directory, by title or author keyword
search.

In addition, you may also find it useful to look at some of the presentations made at
MPLS'2000 held in March. The details of the program are at:
http://www.upperside.fr/bamplsforum.htm
and some of the presentations are at
http://www.upperside.fr/mplsnew.htm

Regards,
-Vishal