RE: [EFM] Re: OAM Transport Proposal
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
>>-----Original Message-----
>>From: Matt Squire [mailto:mattsquire@xxxxxxx]
>>Sent: Tuesday, April 23, 2002 8:29 PM
>>To: stds-802-3-efm@ieee.org
>>Subject: [EFM] Re: OAM Transport Proposal
>>
>>
>>
>>
>>
>>Another attempt to address multiple questions at one time.
>>
>>1) MDIO slowing preamble down. The intent is that the any
>>bit handling
>>of the preamble is done below the MDIO interface. One of the reasons,
>>for me anyway, to keep the use of preamble to communicating a few very
>>specific states was for this point exactly. Trying to
>>communicate real
>>'data' would be slowed down by getting the data from the MDIO
>>interface. The assumption is that the RS is enhanced to hold a small
>>number of state variables which can be communicated via the preamble
>>without turning into management frames over MDIO.
>>
>>2) Handling copper & EOC/voc. We will modify the baseline to
>>explictly
>>not address any copper PHY enhancements that may (or may not) be
>>forthcoming via the adoption of an existing xDSL with IB/EOC/voc
>>capabilities. On copper, the only OAM proposed in the
>>baseline will be
>>the common functionality offered by frames. We will note that copper
>>enhancements are expected to be forthcoming after a copper baseline is
>>adopted.
>>
>>3) Null/Dummy frames screwing up MIBS. Yes semantics of the
>>undersized
>>frames variable will have to change to say something like "except for
>>null/dummy frames which are counted by ...". But I think
>>things can be
>>defined in a way thats backward compatible. This, along with
>>only using
>>those frames when the other side supports it, should have the
>>effect of
>>MIB compatibility.
>>
>>4) Clauses effected. We did a preliminary examination of the clauses
>>that needed to be addressed by the proposal. The following
>>is the list
>>as I see it.
>> - Clause 30 (Management). New MIB objects, enhanced
>>locally and also
>>enhanced to include peer info.
>> - Clause 31 (MAC Control). Add OAM section, fraem formats, protocol
>>operation, bla bla bla
>> - Annex 43B. Add OAM types to slow protocols list, maybe
>>change slow
>>protocol definition, etc.
>> - Clauses 22 & 45. New PHY monitoring registers for things like RX
>>power, signal-to-noise ration, etc.
>> - Annex 30A & 30B. New OIDs for managed objects.
>> - Clause (new). OAM preamble byte format, use, description, etc.
>> - Clause 22 & 35 (RS/MII, RS/GMII) - Dummy/null frame generation,
>>inclusion of preamble transport capability.
>>The preamble specific changes are the latter two. Please point out if
>>we're missing some clause changes somewhere. This list does
>>not reflect
>>which clause changes are significant and which are minor.
>>
>>5) Regenerators/converters. As 802.3 does not define these
>>things, its
>>been difficult to address them properly. I know they have
>>been a topic
>>of great discussion in the past. Its certainly reasonable to
>>ask if/how
>>we address such devices. The short answer is, I think, that we don't
>>explicitly do so because they don't exist within 802.3. But I think
>>many people have tried to consider them when forming their opinions.
>>Note that no existing media converter/regenerator will
>>support any kind
>>of OAM no matter how we define it. The question one has to
>>ask is given
>>that we would basically be defining a new device if it is to support
>>Ethernet OAM (ie new hardware required), what should it look
>>like? One
>>could conceivably define it to be a device with 2-MACs that forwards
>>frames. One could define it to be a bit-pipe, but with a
>>certain amount
>>of buffering/latency to support a preamble insertion. There are
>>differing opinions as to what this 'most simple' device would be.
>>Before we can address it with OAM capabilities we would have
>>to agree on
>>its architecture, and I think one's OAM perspective would color their
>>view of the architecture.
>>
>>
>>- Matt
>>
>>
>>
>>
>>
>>- Matt
>>
The information contained in this electronic mail is privileged and
confidential, intended only for the use of the individual or entity named
above. If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution, or copying of this
communication is strictly prohibited. If you receive this communication in
error, please immediately notify Disclaimer@xxxxxxxxxx Thank you.