Subject: LMP CV and MPLS OAM CV

From: "Robert Streijl" <[email-masked]>
Date: Mon, 21 May 2001 20:42:22 -0400

Neil et al,

What is the difference between connectivity verification provided by LMP,
and CV OAM packets?
Will there be any extensions to the MPLS OAM document on GMPLS OAM?
What is the status on P-flows in MPLS OAM?

Thanks,
Robert

---

From: [email-masked]
Date: Tue, 22 May 2001 09:16:02 +0100

Hi Robert (sorry reply below is a bit long-winded.....I could not easily
give short/simple answers without adequately covering the issues),

You asked on 22 May 2001 01:42
> What is the difference between connectivity verification 

NH=> These address quite different issues.

The first point to note is that MPLS ('classic') introduces a new layer
network technology.....we can see this by noting facts like (i) it defines a
new data/user-plane framing structure (ie the shim header encapsulation
rules), (ii) LSPs are trails (in func arch-speak) which can be explicitly
defined in terms of source/sink, (ii) the source/sink (and indeed
intermediate) points create new processing requirements (eg swap/pop/push),
etc.   The fact that MPLS introduces new functions means, by definition,
that is also introduces new potential failure modes (ie that did not exist
in IP say or, more generally, are not relevant to any other layer network
technology).  It is these new failure modes that our MPLS OAM draft
addresses.....but it goes further than that, to specify issues like how to
measure availability, how to stop nested LSP alarm storms, etc.  These
things are important to operators and can be considered as common (to any
technology) OAM themes....I come back to this point later.

LMP is a new protocol....it is *not* a new layer network.  This is the key
difference.  Indeed, GMPLS does *not* introduce new layer networks (though
judging from the currently lively debate on the CCAMPS channel one might
think otherwise!).  GMPLS is actually a philosophy rather than a
technology....it takes already existing/standardised (but see Note)
data/user-plane networks and applies a common control-plane to them.  Now,
whether the *choice* of the right control-plane facets (the 4 key ones are
(i) addressing, (ii) signalling protocol, (iii) routing protocol and (iv)
control-plane transport network topology) is appropriate is a different
issue....and one I don't want to open up here (but I suspect most know the
views of BT on this).
Note - The GMPLS control-plane can be applied to existing/standardised
user-plane layer networks such as SDH and PDH.  It was, of course,
originally targeted at OTNs....though the actual user-plane standardisation
is not yet complete here.

Now these existing/standardised user-plane networks (such as SDH/PDH) do
have OAM as part of the user-plane framing overhead structure....this is
both natural and correct.  'True' OTNs however, create a bit of a problem as
they can be considered as transparent to the user-plane......esp at
intermediate points when we consider optical switching.  This is why, in
G.709, the concept of a digital wrapper is being worked on.....one can
consider this as the equivalent of the various SDH/Sonet framing formats.
Now, LMP was originally designed (and please correct/add to this Jonathan L
if necessary) to address this 'transparency' problem by providing a method
of testing the user-plane connectivity by injecting a well-known 'test
signal' into the user-plane prior to bringing it into service (for external
traffic carrying).  LMP has other functions however (like how to swap over
between control-channels that carry the LMP protocol), but this was the
prime mover I believe.

So, in conclusion, MPLS OAM and LMP address very different applications.  Is
this clear/OK now?

> Will there be any extensions to the MPLS OAM document on GMPLS OAM?

NH=> You have to note this 1st:
-	the user/data-plane needs its own OAM...and this is per layer
technology
-	the control-plane needs its own OAM (but more accurately it needs
specific/tailored OAM for (i) the routing protocol, (ii) the signalling
protocol and (iii) the user/data-plane of the signalling network....which
can be quite distinct from the user-plane for normal customer traffic.  And
note that 'hellos', error notifications, etc are all OAM functions.).
Once one moves away from a pure CNLS transport mode (ie explicitly
signalled/routed MPLS LSP trails or any GMPLS trails) then the user-plane
and the control-plane *must* be considered separately since they are neither
functionally nor topologically congruent....so this is a whole new ball game
for some.

Now from what I said previously, our MPLS OAM work addresses missing
functionality in the classic MPLS user-plane....it does *not* address any
control-plane aspects.  The need for any additional GMPLS user-plane
functionality however, needs to consider the unique characteristics of the
*section-layer* transport media considered (ie optical
terrestrial/submarine, radio, satellite, copper, etc) and what is defined
for the framing structure at the trail level, ie PDH is different to SDH is
different to OTN.....and especially in terms of the failure modes (and their
handling) that are relevant to the layer network technology considered.
However, one can list some obvious/common OAM themes:
-	must define all defects in terms of entry/exit criteria;
-	must define defect handling in terms of consequent actions, eg
suppress alarm storms in higher/client layer networks, squelch customer
traffic in case of misroutings to ensure customer security/confidentially,
etc
-	must define availability entry/exit criteria (a pre-requisite for
any QoS metric collection, since QoS is only relevant to the up-state)
-	etc
I believe we have described the key themes quite well in our MPLS OAM work,
and then interpreted their implementation details for 'classic' ER MPLS
LSPs.....one would have to apply similar themes to any other user-plane
layer technologies wrt their specific implementation details.

So, whilst its perfectly correct to take the basic themes in our MPLS OAM
work, their actual manifestation in a given layer technology will be quite
different.  And for OTNs, this is being attempted in G.709 to some extent.

> What is the status on P-flows in MPLS OAM?

NH=> Its still FFS.  We need contributions from other operators to say
exactly what they want here.  But note this:  The measurement of performance
metrics needs to be considered within a larger operational framework.....it
can be very costly (for little real benefit) to continuously collect large
amounts of performance data from all connections (just ask any large
operator, I am sure they will say the same).  And in terms of a framework we
need:
-	basic OAM for defect handling and availability measurements...this
is must-have in all situations;
-	ability to turn-on ad hoc detailed QoS flows, eg trouble-shooting or
measurement of important customer connections.....this is more relevant to
pkt-based networks;
-	where QoS metric processing is continuously enabled (eg SDH trails)
then some form of threshold/event-filtering/exception-reporting is required;
-	some network sampling of QoS to determine performance trends and
give some figure of merit over time....again more relevant to pkt-based
networks;
-	network node/link utilisation statistics....that then need coupling
with forecast data to drive the planning cycle.

Shahram (Davari) has written an excellent paper which examines various
P-flow options (for E/L-LSP variants).  I am sure Shahram could let you have
a copy if you want to see it.  However, as I noted above, this area needs
input from the larger operator community.

---

From: [email-masked]
Date: Tue, 22 May 2001 16:09:12 +0100

Hi Robert, you asked (I have snipped the bottom off the mail)on 22 May 2001
13:57
> 
> Neil: Thanks very much for this answer. It is is perfectly clear.
> I knew there had to be a difference, and some of it was clear 
> to me, but
> not all of it.
> So, do you expect there will be more investigation on OAM in 
> GMPLS in each
> of the specific media used (besides G.709)?
> 
NH=> To be perfectly honest I have not given a great deal of thought to this
since its not that high on our priority stack.  Maybe also be true for many
of the other operators(?), but I have seen very little input from most of
the large ones (on any of the GMPLS stuff).

SDH/Sonet and PDH have been around long-enough to have stable and well
defined OAM of the user-plane.  However, if a control-plane is introduced
then some coupling of user-plane OAM span and S-PVC-like span seems
essential, eg to trigger prot-sw.  Ditto for the OTN, though here there is
some notion of several levels of nested TCM (Tanden Connection Monitoring)
also incorporated in G.709.....Maarten Vissers is the expert to talk to here
for more info.
Note - We are not so interested in SVCs at this stage....seems hard to build
a viable business case for a 'Gbit/s PSTN look-alike' in our opinion with
unknown GoS/pricing/'erlang' model.

ATM has some OAM.....but its far from ideal and we still cannot properly
define/measure availability in this fabric (I tried to address these
weaknesses in the MPLS OAM work, and those familar with ATM OAM may realise
what the issues are, but its complex and long-winded to explain on mail).

regards, Neil

---

From: "Robert Streijl" <[email-masked]>
Date: Tue, 22 May 2001 08:56:40 -0400

Neil, Sharam,

Neil: Thanks very much for this answer. It is is perfectly clear.
I knew there had to be a difference, and some of it was clear to me, but
not all of it.
So, do you expect there will be more investigation on OAM in GMPLS in each
of the specific media used (besides G.709)?

Sharam: Would you share a copy on the P-flows for MPLS OAM with me?
Thanks,

Regards,
Robert

[email-masked] on 05/22/2001 04:16:02 AM

To:   [email-masked]
cc:   [email-masked] (bcc: Robert Streijl/Telcordia)
Subject:  RE: LMP CV and MPLS OAM CV

network technology.....we can see this by noting facts like (i) it defines
a

both natural and correct.  'True' OTNs however, create a bit of a problem
as

So, in conclusion, MPLS OAM and LMP address very different applications.
Is
this clear/OK now?

and the control-plane *must* be considered separately since they are
neither
functionally nor topologically congruent....so this is a whole new ball
game
for some.

different to OTN.....and especially in terms of the failure modes (and
their

exactly what they want here.  But note this:  The measurement of
performance
operator, I am sure they will say the same).  And in terms of a framework
we
then some form of threshold/event-filtering/exception-reporting is
required;

Shahram (Davari) has written an excellent paper which examines various
P-flow options (for E/L-LSP variants).  I am sure Shahram could let you
have
a copy if you want to see it.  However, as I noted above, this area needs
input from the larger operator community.