RE: [EFM] [EFM-OAM] OAM Transport Proposal
Onn,
I don't have a copy of the 802.3 minutes from the St. Louis meeting, so I
can neither confirm nor deny your statement about PHY ID. If PHY ID
requires 8 bytes of preamble, then they will have to figure out how to
change previous clauses to generate the required 8 bytes. If PHY ID doesn't
require 8 bytes of preamble, but only enough bytes to pass the PHY ID and a
CRC, then the level of changes will decrease. I'm also assuming that PHY ID
is inserted or used below the RS. If not, this will change the impact
dramatically too.
When looking at PHY ID, OAM and EFM in general, we have to look at the full
scope of the project, not just the deltas of each new feature, which leads
to feature-creep. The impact of OAM addition to 802.3 has more impact on
existing clauses than any of our previous standards efforts. 802.3 has been
reluctant in the past to open up these clauses more than necessary because
of the possibility of breaking something or breaking all existing
implementations in the market.
Cheers,
Brad
-----Original Message-----
From: Onn Haran [mailto:onn.haran@xxxxxxxxxxx]
Sent: Thursday, April 25, 2002 4:11 AM
To: Booth, Bradley; stds-802-3-efm@ieee.org
Subject: RE: [EFM] [EFM-OAM] OAM Transport Proposal
Brad,
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.
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
>