Re: [EFM] EFM OAM on Preamble
Hiroshi,
I agree this should only be done in full duplex and is not
a concern with 10GE.
Hiroshi Suzuki wrote:
>
> We have 2 options for this.
> a) Not to use this byte. This means we have only 6byte preamble (
> including SFD byte.) to carry OAM.
> Since we have 2 reserved byte, still OK with it. This actually was
> discussed off-line last week.
The receiver doesn't know if the first byte was discarded
so a protocol would have to look something like this:
TX: 55 55 OAM1 OAM2 RES1 PHY1 PHY2 CRC
The receiver would get one of these and would have to know
how to deal with either, i.e., it needs to see 55 in both
the 2nd AND 3rd bytes to know that this is a regular
preamble and not an OAM preamble:
RX1: 55 55 OAM1 OAM2 RES1 PHY1 PHY2 CRC
RX2: 55 OAM1 OAM2 RES1 PHY1 PHY2 CRC
> b) PCS recovers /S/+7byte preamble ( including SFD byte ), when Unaligned
> case.
> This is simply done by having additional 3-4 byte FIFO in PCS.
> We will discuss about these options in detail in Jan meeting.
I guess I'll wait for January to hear about this...
Regards,
Ben
Hiroshi Suzuki wrote:
>
> Hi Ben,
>
> Thank you for the question.
>
> Indeed, during my presentation, there was a discussion on Preamble
> transparency.
> In the current PCS/RS/GMII clauses of existing 802.3 spec clearly describes
> PHY may shrink preamble to only SFD and RS has to accept a frame with any
> shrinked preamble.
>
> For these comments, I made it clear that
>
> - OAM on Preamble is applied to Full duplex mode only. Not for half-duplex
> / CSMA-CD mode.
> Preamble shrinkage to "any" size happens only for CSMA-CD mode.
> And EFM environments and SP provider circumstances, any half duplex mode
> does not make sense
> due to distance limitation. So this assumption is valid, I hope.
> Only thing to modify the spec is that we state something like in RS/GMII
> clause ( where OAM handler locates )
> "Preamble not be shrinked by PHY in full duplex mode, when OAM is used"
>
> -EFM Cupper P2P, EPON will have PCS change as well as PMD, so we can make
> sure preamble transparency in the new spec.
>
> -For P2P GE, there is the following issue, as you anticipate.
> ( this was not discussed during presentation but
> discussed off-line during the meeting)
> Since Idle detection is done by every 16bits, Aligned / Unalined frame
> may lose the first byte of Preamble, where
> the second byte be replaced with /S/.
> We have 2 options for this.
> a) Not to use this byte. This means we have only 6byte preamble (
> including SFD byte.) to carry OAM.
> Since we have 2 reserved byte, still OK with it. This actually was
> discussed off-line last week.
> b) PCS recovers /S/+7byte preamble ( including SFD byte ), when Unaligned
> case.
> This is simply done by having additional 3-4 byte FIFO in PCS.
> We will discuss about these options in detail in Jan meeting.
> Note this occurs only in GE. Not in 100baseX, 10GE.
>
> -For 802.3ae 10GE, it is clearly stated in the spec, no preamble shrinkage.
> If preamble is shrinked, MAC can discard whole frames.
>
> Hope this helps.
>
> Thanks!
>
> Hiroshi
>
> At 09:48 AM 11/20/2001 -0500, Ben Brown wrote:
>
> >Hiroshi,
> >
> >I did not attend your presentation entitled "EFM OAM on Preamble"
> >but I've seen a copy of your slides. I wonder if this question
> >was asked during the presentation and would like to hear your
> >response:
> >
> >How is this protocol handled when preamble bytes are lost?
> >Specifically in the case of 1GE when the first byte of
> >preamble is discarded around 50% of the time.
> >
> >Thanks,
> >Ben Brown
> >
> >--
> >-----------------------------------------
> >Benjamin Brown
> >AMCC
> >2 Commerce Park West
> >Suite 104
> >Bedford NH 03110
> >603-641-9837 - Work
> >603-491-0296 - Cell
> >603-626-7455 - Fax
> >603-798-4115 - Home Office
> >bbrown@xxxxxxxx
> >-----------------------------------------
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------