RE: [EFM] [EFM-OAM] OAM Transport Proposal
Roy,
So this is all your fault? ;) That does explain a lot... just kidding!
Seriously though, with some of the information related to preamble bytes,
PHY ID and where it is being handled should probably come under some more
scrutiny to make sure we're not heading down the wrong path.
Cheers,
Brad
-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: Thursday, April 25, 2002 12:35 PM
To: Booth, Bradley; stds-802-3-efm@ieee.org
Subject: RE: [EFM] [EFM-OAM] OAM Transport Proposal
Brad,
If I remember correctly, the baseline that was accepted for
the P2MP MPCP
protocol used the PHY ID in an 8 byte preamble. There has
yet to be a
requirement for PHY ID outside of P2MP. There are several
people that are
trying to make it part of the baseline for OAM in general,
but I do not see
the need. (I wish that I had patented the idea of the PHY
ID before I
presented it at the May 2001 meeting. I would have better
control over it
now.)
Thank you,
Roy Bynum
At 08:18 AM 4/25/2002 -0700, Booth, Bradley wrote:
>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
> >