Re: 664b/66b frame alignment in SONET payload - Reality Check
Wesley,
I am afraid that the use of the term "gear box" belies the complexity of what is going on. Just to do a reality check. The so
called "UniPHY" from which the "WIS" is derived now has four separate data clocking domains: common system @ ~ 10.0, open loop data
transfer @ ~9.2, 64B/66B block encoding/SONET Payload Envelope (SPE) @ ~ 9.5, and the SONET signaling @ ~9.9. Because the alignment
between the SONET frame and the block coding is not on even byte boundaries there will have to be a major buffer to compensate
between the ~9.5 SPE transfer rate and the ~9.9 SONET signaling rate, perhaps as much as 1.5 the SPE. This buffer is also necessary
to allow the sync overlap of difference between the 66 bit coding and 8 bit mapping within the SPE.
Compare this to the already existing HEC framed WAN compatible PHY interface that Nortel already has working. It only has three
clock domains: ~10.0, ~9.5, and ~9.9. If I understand it correctly it only has a frame buffer to obtain the size of the frames
before mapping them. Because the synchronization of the data is derived from the SONET and is on the standard byte boundaries, a
complex "gear box" is not needed.
If Rich Taborek is to be believed there are two separate PHYs now. One PHY is for the CWDM/Parallel PMDs with legacy 8B10B block
coding. Another PHY has 64B/66B block coding for serial PMDs. There is no such thing as a single PHY under current confederations.
I am beginning to suspect that the "UniPHY" is actually going to "cost" a lot more than simply having three separate PHYs instead of
only two. ( This was a question that was put to the group at a previous meeting.) I also think that it is going to take a lot
longer to have working interfaces that can get to market if we continue to push for a "UniPHY". The "WIS" was a good idea, but
it is turning out to be so complex that it may delay the adoption process. There is already a WAN compatible PHY interface that has
been demonstrated. I suspect that a CWDM short read PHY based on 8B10B (XAUI) will be very easy to get working. Without the "WIS",
the 64B/66B LAN only PHY may be moderately easy to get operational as well.
As a customer, if I am going to have separate PHYs for short reach and serial, an additional PHY for WAN actually makes would not
add to the complexity of any decisions that I would be making. In some respects, having totally separate PHYs for LAN and WAN makes
it easier to support. The complexity and training needed for serial LAN only installations is not complicated by the possibility
of having WAN components. Only for those installations that need WAN functionality do I need additional training for my support
personnel. Only for WAN installations do I need additional functionality in my network management systems, if the PHYs are
separate.
Given the closeness to the July meeting, I think that it is time for a reality check.
Thank you,
Roy Bynum
----- Original Message -----
From: "Wesley Lee" <wlee@xxxxxxxxxx>
To: "Tom Alexander" <Tom_Alexander@xxxxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
Sent: Friday, June 16, 2000 2:44 PM
Subject: Re: FW: 664b/66b frame alignment in SONET payload
>
> Tom,
>
> Thanks for bringing this up. I forgot about the "gearbox" which
> puts things nice byte-size chunks :)
>
> Regards
> -Wesley Lee
>
> Tom Alexander wrote:
> >
> > Hi,
> >
> > In the 64B/66B codec diagrams presented by Rick Walker,
> > there is mention of a 66:16 "gearbox" that performs a
> > width/frequency conversion. I believe this may be what
> > you are referring to with respect to the aligner function.
> > In this case the service interface of the 64B/66B PCS
> > should be directly mappable to the service interface of
> > the WIS, with no extra alignment in between (i.e., no
> > alignment that is not already required for the LAN-PHY).
> >
> > Cheers,
> >
> > - Tom
> >
> > -----Original Message-----
> > From: Wesley Lee [mailto:wlee@xxxxxxxxxx]
> > Sent: Friday, June 16, 2000 11:48 AM
> > To: Thomas Dineen
> > Cc: 'rabynum@xxxxxxxxxxxxxx'; 'erikt@xxxxxxxxxxxxxxxxxx';
> > stds-802-3-hssg@xxxxxxxx
> > Subject: Re: FW: 664b/66b frame alignment in SONET payload
> >
> > Hi,
> >
> > Just to clarify my point which I believe is a different from Erik's and
> > this issue admittedly is not major. The point I was make about "wrapping"
> > refers to the wrapping the 66-bit code word within the SPE. Given that the
> > width of the SPE is 16,640 bytes (133,120 bits), the 66-bit code word is not
> > a multiple of this size, and the last code word at the end of the row will
> > be split between this row and the beginning of the next row. What this
> > means
> > is that an aligner function will be needed to handle this "wrapping". Not a
> > big
> > deal, only that it may entail a 66 to 1 mux which some might want to avoid
> > at
> > high speed.
> >
> > -Wesley Lee
> >
> > Thomas Dineen wrote:
> > >
> > > > Gentlepeople:
> > > >
> > > > Maybe I am missing something here but I think this is a
> > non-problem.
> > > >
> > > > I envision a series of repeating STS-N frames with their
> > > > encapsulated
> > > > SPEs as one continuous repeating structure. In other words, after
> > > > extracting
> > > > th ubiquitous Transport and Path Overhead there is no wrap around from
> > one
> > > > SPE to another! The N+1 th SPE follows the Nth SPE in the same manor
> > that
> > > > the N+1 th row follows the Nth. This is especially useful when floating
> > > > SPE mode
> > > > is used with payload pointers.
> > > >
> > > > Inherited A Sonet Problem.
> > > > (Thomas Dineen)
> >
> > --
> > ==================================================================
> > Lucent Microelectronics Enterprise LAN Division - West
> > 1381 McCarthy Blvd, Miltpitas, CA 95035
> > Work: 408-952-8822 FAX : 408-952-8887 wlee@xxxxxxxxxx
> > ==================================================================
>
> --
> ==================================================================
> Lucent Microelectronics Enterprise LAN Division - West
> 1381 McCarthy Blvd, Miltpitas, CA 95035
> Work: 408-952-8822 FAX : 408-952-8887 wlee@xxxxxxxxxx
> ==================================================================