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

RE: [EFM] [EFM-OAM] OAM Transport Proposal


PHY ID tagging inside preamble was accepted by 802.3 in St. Louis. The
suggested PHY ID format requires 8 bytes preamble regardless of any OAM
bytes inside the preamble. Therefore, the issue of 8 preamble bytes is a
problem that we need to solve anyway.

PHY ID tagging also requires some of the functionality you described for the
RS layer, like stripping and handling the preamble, and even much more, like
multiplexing layer.

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.


> -----Original Message-----
> From:
> []On Behalf Of Booth,
> Bradley
> Sent: Wednesday, April 24, 2002 6:26 PM
> To: ''
> 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