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
> >