RE: [EFM] [EFM-OAM] OAM Transport Proposal
Now that I've had a flight and a night to sleep on this, let me see if I can
get some more answers. :-)
I also believe that there are a lot of statements being made about what is
in hardware, software and firmware. As our working group chair pointed out
to me early in my 802.3 days: it is incorrect for us to assume what is
implemented in hardware, software or firmware; we can only specify what
responses are required to be compliant and how those responses are generated
is up to the implementer.
First, let me state, that I'm sure that in the form of implementing OAM in
preamble (OAMinP) in logic, the effort is not that difficult. That said,
I'm not looking at OAMinP from a logic design point of view, but from how
does the task force open up 802.3 to specify this.
I'm going to address the two issues with OAMinP separately. The first issue
is the number of preamble bytes. The second issue is the functionality
required in the reconciliation sublayer (RS).
Number of preamble bytes:
* opening only Clause 36
* a buffer or queuing function added to the PCS
* buffer function would align the SPD based on transmit alignment
* would need to specify that this is only for OAMinP with full-duplex
* insert capability into PICS and compliance requirements into PICS
* concern: will GbE MACs live with less than min. IPG
* opening Clauses 35 and 36
* buffer or queuing function added to the RS
* require addition to GMII to pass up (or pass down) transmit
alignment
* in transmit alignment pass down, the transmit state machine would
need to be changed
* would need to specify that this is only for OAMinP with full-duplex
* would need to add new PICS for the RS and this feature
* concern #1: changes state-less RS into a functional RS
* concern #2: change to the GMII, which would also impact Clause 40
Functionality required in RS:
* this would change all 802.3 RS to have functionality for stripping
the preamble
* impact would be to Clauses 22, 35, 41 (assuming full duplex
repeaters are included) and 46
* would need to insert specification for the handling of preamble
* would need to insert capability into PICS and compliance
requirements into PICS
* addition of MIBs
* concern #1: changes state-less RSs (22, 35, 41) into functional RSs
* concern #2: specification of how to handle these alarms (i.e.
latency, valid responses, etc.)
There is something else that concerns me too. MAC control frames are
required to offer the optional OAMinP feature, yet in some instances (as
described by Sergiu, non-MAC-based converters) where we'd like to use
OAMinP, we don't have MAC control frames to offer this feature.
Cheers,
Brad