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

From: [email-masked]
Date: Sat, 17 Feb 2001 09:34:11 -0000

Giles Heron [mailto:[email-masked]] wrote on 16 February 2001 21:39
<snipped>
> I guess this would imply that on any set of parallel links between two
> MPLS routers you'd be pushing an extra level of label to handle the
> linkset?  I'm not sure that's the most efficient way of doing
> load-sharing?
NH=> No I am not suggesting this.  I am only pointing out that
(architecturally) load splitting is effectively an inverse multiplexing
function.  This is creating lower level trails that need their own
management (by whatever method one sees fit)....for example, if one of these
links fail one would need to (i) know about this (ii) take appropriate
consequential actions, eg stop sending traffic down it, alert Ops people,
etc.  All I was pointing out was that one *could* put an OAM flow on these
lower level trails.....though of course you could use some other
method....but the key point is they need management.
> 
> And in any case you'd come back to the same issue.  How does B decide
> which packets of a given LSP from A-D need to be placed on the "upper"
> link and which on the "lower"?  If OAM packets are routed on 
> a different
> physical link than user data packets then the OAM no longer 
> measures the
> LSP accurately?
NH=> As Shahram pointed out you would not hash on S bit.....assuming you
wanted to do what you are suggesting.  Whether the (low frequency) OAM pkt
took the 1st or 2nd load sharing link would be a matter for the inverse
muxing algorithm used.  The OAM pkt would still measure the A-D LSP OK I
think, due to these factors:
-	CV flow....the load sharing is (conceptually) providing resilience
to the B-C partition of the trail.  So providing the management of the inv
muxing algorithm could detect failures and take the right actions the the CV
flow would still get from A-D....and since all defects (dLOCV, dTTSI, dLoop)
are only relevant at the sink point (ie at D) then these would still be
detectable.
-	P flow....the fact that the traffic splits is
irrelevant....providing it still comes back at D (there are some ordering
issues here, ie if grossly out of sync then short-term measures would have
errors, but this error->0 and T->large).  The P flow simply measure
pkt/octet loss between A and D and does not care how the pkts are routed
between these.
Question:  I am puzzled by the requirement to measure "accurately" here.
Measure what exactly?  For example A-B1st-C-D is a different trail to
A-B2nd-C-D....so are you implying you want to measure each trail separately
or some joint metric (and which metric)?  Note:  OAM is not usually about
accurate measurement of QoS metrics....OAM is more about detecting failures
and taking appropriate consequent actions (eg protecting customer data,
alerting Ops people).  Accurate QoS measurements cost money to
measure/collect/process/analyse, and one 1st has to define what are the 'up'
and 'down' states, since the QoS metrics/objectives should really only apply
to the up-state (otheriwse they can quickly become meaningless)
> 
> [rest of original message snipped]
>

---

From: Mahadevan Iyer <[email-masked]>
Date: Sun, 18 Feb 2001 21:22:33 -0800 (PST)

> to the up-state (otheriwse they can quickly become

Neil,

From a service provider point of view, do they 1)use
QoS measurements at all or are they 2)satisfied with
detecting failures ? 

I guess this will tie into the billing/accounting for
customers. 

As a follow up question(if the answer to the previous
question is 2) could one infer that billing/accounting
is not actual usage/actual volume based. The customer
gets charged for whatever was negotiated upfront. If
there is a problem, the provider pays whatever is
mentioned in the penalty clause.

Thanks

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

---

From: Giles Heron <[email-masked]>
Date: Mon, 19 Feb 2001 20:31:44 +0000

> method....but the key point is they need management.

Agreed, these links need management.  But they are under the control of
the IGP, so there is no need to do any "trail" management on them. 
Wonderful things these IGPs ;-)

> pkt/octet loss between A and D and does not care how the pkts are routed

I don't think the traffic split is irrelevant at all.  If the OAM flow
follows a different path to the user data flow for any reason (for
example load sharing algorithms that include the S bit) then the P flow
measurements may be inaccurate (for example due to congestion/bit errors
on one of the links.)  I would be surprised if any of the equipment
vendors have thought to exclude the S bit from their hash functions
(though I am prepared to be proven wrong on this point.)

(As Shahram has pointed out this may be moot if MPLS TE is used, since a
given LSP from A to D would be explicity routed over either B1st-C or
B2nd-C.)

> to the up-state (otheriwse they can quickly become meaningless)

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?)

Giles

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