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

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@passave.com]
>                 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
>                 >