RE: [EFM] [EFM-OAM] OAM Transport Proposal
Onn,
It does NOT work because CRC could be the same value as SFD pattern
once you try to rely on SFD.
And the big question on how to support dummy/null-frame without SFD.
I am also hearing many people complain about excluding
the SFD value in reserved bytes.
Hiroshi
At 11:10 AM 4/25/2002 +0200, Onn Haran wrote:
>The amount of changes required to support 8 preamble bytes seems
>considerable. I would like to suggest an alternative solution, and I would
>appreciate if you can analyze the amount of required changes.
>
>The preamble could be 7 or 8 bytes, based on the following format:
>Byte 1: SPD
>Byte 2: Reserved - transmitted only when preamble is 8 bytes
>Byte 3: OAM
>Byte 4: Reserved
>Bytes 5-6: PHY ID
>Byte 7: CRC (calculated over the previous 4 bytes)
>Byte 8: SFD
>
>
>I understand that a lot of specification effort is required for adding OAM
>in preamble. But most of this effort is required anyway for PHY ID tagging.
>When coming to evaluate the effort of specifying OAM in preamble, we should
>focus on the delta from PHY ID tagging specification.
>
>Regards,
>Onn.
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Booth,
> > Bradley
> > Sent: Wednesday, April 24, 2002 6:26 PM
> > To: 'stds-802-3-efm@ieee.org'
> > Subject: 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
> >