[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