Subject: RE: MPLS OAM? (was Re: PHP negotiation)

From: [email-masked]
Date: Tue, 20 Feb 2001 12:40:52 -0000

Hi Giles,  you asked:
<snipped>
> What I want to do is to measure, reasonably accurately, the 
> packet loss
> (and latency) of any given LSP through the network.  This is 
> useful for
> SLA monitoring etc.  Whether this is strictly an "OAM" 
> function doesn't
> concern me overly.  If this can be done as a small delta to 
> providing an
> OAM facility without this capability then it would seem like 
> a good idea
> (presumably that is the reason you specified the P flow in the first
> place?)
NH=> Yes.  But the only metrics I have considered so far are loss.  We could
add others (like errors and delay) but I have not considered these at this
time to keep it simple.....indeed, initally I wondered whether we should be
trying to do any QoS measurements at all above basic defect handling.  But
if other metrics are considered important then these should be
considered....noting that there is a cost associated with their
measurement/processing so the wish list should not be too large.

---

From: Giles Heron <[email-masked]>
Date: Tue, 20 Feb 2001 15:26:52 +0000

> measurement/processing so the wish list should not be too large.

I'd say that you'd want to decouple defect handling from QoS
measurement?

As far as I can tell the CV, BDI, and FDI flows are aimed at defect
handling, and the P flow at performance/QoS measurement?

It may be that this is an "either, or, or both" type of situation? 
Defect handling could be applied to "trunk" LSPs in the network (though
in some ways I'd question the need for this in the presence of the label
distribution protocols - surely if a connectivity defect occurs then the
label mapping will be withdrawn by RSVP or LDP?)  However performance
measurement is required on LSPs relating to user circuits.  In some
cases these LSPs may have implicit connectivity (for example in the
"draft-martini" case where targetted LDP is run from PE to PE to signal
"VC" labels, which are layered over "IGP" labels signaled by LDP, RSVP,
or whatever) and so connectivity verification makes no sense?

The CV, BDI and FDI flows should all be sent through the network with
EXP values set for minimum loss/delay (I think you have specified this
in your doc.)

The P flow should be sent with the same EXP value as the user data, to
ensure equal forwarding treatment.  Load balancing is an issue here -
the P flow MUST be forwarded over the same links as the user data to
ensure reasonably accurate measurement.  This brings us back to hash
functions which ignore the S bit, or to use of TE LSPs to enable
deterministic path selection for each LSP.  In fact use of TE for these
LSPs is unlikely in large SP networks, precisely because these are
"user" LSPs rather than "trunk" LSPs (so TE is unlikely to scale to the
number of LSPs required?)

Giles

-- 
===================================================
Giles Heron - IP Architect - Level 3 Communications
phone: +44 20 7864 0719     mobile: +44 7880 506185
===================================================