Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] RE: OAM Transport Proposal

One comment below on copper OAM...

At 07:47 AM 4/23/2002 -0400, Matt Squire wrote:

> >
> > 1) Eliminate reference to the EOC/voc.  We (those working on the OAM)
> > have been working under the assumption that the copper track will
> > solidify on an Ethernet over xDSL technology, and the xDSL technology
> > will be an already defined DSL technology such as VDSL.  Such DSL
> > technologies provide a management channel with the EOC/voc.  The members
> > of the copper track have repeatedly expressed the opinion that the
> > EOC/voc managmeent channel should continue to be used for most PHY
> > management functionality.  What we are really proposing is a layered OAM
> > scheme. Certain OAM functions are common across all Ethernets and are
> > communicated using a frame-based OAM mechanism.  Other OAM functions are
> > PHY specific and communicated using the preamble (for P2P full-duplex
> > Ethernet) or EOC/voc (for Ethernet over copper).  The proposal for
> > Ethernet over copper is that the common Ethernet functions be
> > communicated via a frame-based mechanism, and any PHY specific functions
> > performed in the EOC/voc.  This would permit, as an example, using a
> > standard Ethernet MAC over a standard xDSL chip.  So I don't think we
> > can eliminate the reference.
> >
> > BJB> If you do not plan to eliminate the reference, then please provide the
> > data where others can read about how this is performed.  It seems premature
> > to ask the task force and the working group to support something that is
> > undefined.  I know you may be waiting for the copper track to provide you
> > with some direction, but it's hard to say I agree with a management scheme
> > when I don't know what it is.
> >
>Fair enough.  We're in a little bit of a chicken-and-egg problem.  We
>didn't think we'd get approval without explicitly addressing the EOC/voc
>work for copper, but we can't really address it until more has been
>officially adopted by the copper group.  My suggestion to move past this
>point is to:
>a) Remove reference to EOC/voc
>b) Replace it with statement to the effect that copper-specific OAM
>enhancements are expected but not included in this baseline

BAA> I recall the copper STF did officially adopt VDSL as part of their 
baseline in St. Louis, but the baseline proposal did not achieve 75% 
consensus in the TF.  If we believe that copper will try again with VDSL in 
May, then it is probably safe to reference VDSL-specific methods in the OAM 
baseline.  To that end, I would suggest altering (b) above with something 
to the effect that copper-specific OAM transport enhancements may include 
any of the out-of-band methods available for VDSL, such as indicator bits 
(IB), VOC, or eoc.

We may wish to consider indicator bits where possible instead of VOC/eoc 
because IBs are carried in the VDSL frame header (much like 
OAM-in-preamble), and because the VOC protocol appears potentially much 
slower in comparison (900 msec worst case per acknowledged 
transaction).  Which functionality gets mapped to which method is still TBD.

For those interested in reading further, the T1E1.4 trial-use specification 
T1.424 describes OAM methods for VDSL, as does ITU-T G.993.1.