The MPLS WG Archive

[Dave McDysan <dave.mcdysan@wcom.com>]

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> neil.2.harrison@bt.com
> Sent: Wednesday, December 12, 2001 7:30 AM
> To: mpls@UU.NET
> Subject: RE: MPLSOAM BOF meeting draft minutes
>

Stuff deleted.

>
> Taking the CO case since GMPLS is mentioned, let's pick SDH/Sonet
> as one (of
> many) potential technologies.  Here you will find that the OAM principles
> (of Y.1710) and solutions (of draft Y.1711) generally
> apply.....that is, you
> will find a CV function (trail ID verification) a FDI function
> (to suppress
> downstream/client layer alarms, etc) a BDI function (to tell one direction
> about the other direction...if appropriate) and perf monitoring (eg the
> BIPs).  You will find similar principles/functional-solutions in
> ATM (though
> there are some problems with *how* this has been done here, that I have
> tried really hard to correct and simplify for MPLS).  These are
> done in the
> user-plane (for very good reasons), they are control-plane
> agnostic and they
> have no dependency on any specific client or server layer technology's OAM
> functions.  These (effectively 'no layer/plane violation') principles are
> absolutely essential to allow add/change/remove of layer networks and give
> consistent behaviour/treatment irrespective of application.
>

In my opinion, using ATM continuity check (even with the changes you
propose) as a precedent for MPLS OAM has several practical issues. Although
the continuity check function has been defined in ATM, it is not widely
implemented in deployed ATM, FR/ATM, or IP/ATM networks. Broken ATM
implementations occurred (possibly still occur) where a control plane
indicated a VC was up, but it was not forwarding traffic. One operational
approach is to periodically monitor whether a trunk or access VC is carrying
traffic (e.g., by looking a MIB variables). If no traffic is passing, then
there is a potential problem. In practice, this works pretty well on VP
trunks for ATM. I believe that the real solution is to fix (or replace the
vendor of) a broken implementation. If the proposed continuity packet
solution requires hardware, there is also a practical issue of upgrading
already deployed equipment. This was (is) a very real issue for real-world
ATM, FR over ATM, and IP over ATM networks.

Dave