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

Re: [EFM] Re:OAM Transport Proposal






Hi Dennis,

I believe you are correct, Clause 22, as written today, only requires RX_DV to
be asserted by the time SFD is placed on RxD permitting the preamble bytes to be
deleted before they reach the RS (Subclause 22.2.2.6 & 22.2.2.7, Table 22-4).
The OAMinP proposal however process the information contained in the preamble in
the RS, not in the PHY. Therefore to support OAMinP on PtP 100Mb/s as proposed I
would assume that further changes will be proposed to Clause 22 so that it will
require that the entire preamble is passed across the MII to the RS when OAMinP
is operating [I think this change needs to be added to the table on page 20 of
http://www.ieee802.org/3/efm/public/mar02/suzuki_2_0302.pdf].

Regards,
  David Law







Denis Beaudoin <dbeaudoin@ti.com> on 25/04/2002 14:31:28

Sent by:  Denis Beaudoin <dbeaudoin@ti.com>


To:   mattsquire@acm.org
cc:   stds-802-3-efm@ieee.org, sergiu@nbase-xyplex.com (David Law/GB/3Com)
Subject:  [EFM] Re:OAM Transport Proposal





Clause 22 tables 22-4 and 22-5 identify that if any preamble sent to the MAC
layer is seen that it must be '5'. Many phy's eroded MAC preamble to support the

PCS layer. As long as the OAM function is completely imbedded in the PHY, the
PHY can strip off the preamble, all should be OK. But if the OAM function is
generating FRAMES in the event of their absence, this will impact the MAC
functionality especially in full duplex.

Also reference PICS proforma Clause 22 FS5.

Regards Denis


Matt Squire wrote:

> We've had many threads on repeaters, media converters, regenerators, and
> the like throughout the evolution of this work.  The following are my
> recollections as reported by others (Geoff, Tony, etc.).  Pls correct
> anything I misrepresent.
>
> 1) 802.3 defines half-duplex repeaters.
> 2) 802.3 does not define full-duplex repeaters.
> 3) What some people commonly refer to as full duplex repeaters are
> actually 2-port MAC frame forwarders (802.1D relays?).
> 4) 802.3 does not define optical regenerators (ie protocol agnostic
> signal regeneration).
> 5) 802.3 does not define media converters.
>
> Since using the preamble to carry signaling is intended as a full-duplex
> function only, I short-cut to the conclusion that preamble has no
> applicability to any repeater, regenerator, or media converter as
> defined by 802.3.  Before we could figure out how to address this
> full-duplex repeater function that does not exist in 802.3, it would
> have to be properly defined.  Thats all I was getting at.
>
> People are concerned, people are thinking about it, but it has been
> difficult to address because of the terminology confusion and our
> scope.
>
> - Matt
>
> >
> >Hi Matt and all,
> >
> >I will address only the issues related to 5) Regenerators and
> >converters.
> >First of all I want to assume that we consider all the 802.3
> >interfaces,
> >including 100 Mbps and GbE.
> >
> >802,3 defines the above entities. Look at 27. Repeater for 100
> >Mbps baseband
> >networks.
> >The devices that we address are two port full duplex repeaters.
> >Also 802.3ab makes extensive references to repeater implementations.
> >
> >And again, the moment that we defined any preamble based
> >capability - see
> >page 9
> >of the baseline presentation - we decided to make the
> >appropraite changes
> >for preamble
> >support.
> >
> >I also had some questions, regarding packet based functionality.
> >This functionality I assume is not fully contained in the new
> >MAC (like the
> >packet based
> >flow control functionality). It requires an external processing unit
> >(CPU+MAC, HW, or whatever).
> >What is the level of service in the case of a busy link (even
> >malfunctioning
> >due to a broadcast
> >storm, etc.)? Do we lose the management capacity for some time?
> >Wouldn't an out-of-band mechanism (like preamble) be valuable
> >in order to
> >provide even the
> >basic management information as defined in the suzuki proposal?
> >
> >I still think that the compromise should be a functional
> >compromise, that
> >provide the
> >best of the two worlds meaning that the capabilities
> >negotiations should
> >include four
> >options, and should be done also at the lowest level...
> >
> >Sergiu
> >
> >