Re: [EFM] [EFM-OAM] OAM Transport Proposal
Roy,
I'm unaware of anyone in the OAM sub-Task Force who has proposed the use
of Logical PHY ID for OAM in general. Since you had been a member of the
OAM sub-Task Force you know this full well. I'll kindly ask you to stop
spreading any more FUD on this and related issues so we can all get down
to real work.
For the record: PHY ID, designating Logical PHY ID is specified in the
preamble format of the OAM Baseline to indicate the format of the entire
preamble. Furthermore, an asterisk is placed on this field with the
asterisk text stating: "PHY ID for P2MP only".
Please also be aware that this issues of OAM for P2MP are not resolved
and OAM is required for P2MP as it is for P2P. I don't believe that
we'll be able to use the PHY ID field for an OAM-specific function when
OAM functions in the preamble are active in a P2MP application.
I've attached the latest OAM Baseline proposal the EFM OAM sub-Task
Force is working on. It's dated 4/22. Please see slide 10.
I hope this clears things up for you.
Best Regards,
Rich
--
Roy Bynum wrote:
>
> 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
> > >
OAMtransport_042202.pdf