Re: 66-bit alignment vs 8-bit alignment
Hi Rich,
Thanks for putting the things in a very concise manner. I think as long as
SONET can synchronize on A1, A2 and Ethernet can synchronize on 64/66
delimiters and subsequent
idles and as long as payload rate is limited to 9.584640 (+-100ppm), there
should not be
any problem in treating the Ethernet signal as "blackbox" (at least that is
how I understand).
I think Mr Ishida can add more comments to this as his proposal seems to be on
similar in line.
Regards,
Tripathi.
At 12:08 PM 4/14/00 -0700, you wrote:
>Dave,
>
>Dave, thanks for your prompt and courteous responses. I have some additional
>questions on your comments below. For the sake of brevity, I've deleted
>extraneous text. If you believe that I've taken anything out of context,
>please
>correct me.
>
> > David Martin wrote:
> >> Rich Taborek wrote:
>
> >> 1) Why would a SONET section framer or any SONET framer, including that
> >> in the UniPHY proposal, care about the contents of the payload it is
> >> carrying for the specific case that the payload is 10 GbE payload? I
> >> may be wrong, but I don't believe that any other SONET payload is
> >> relevant or of any interest to IEEE P802.3ae;
> >
> > The SONET section framer does not care about the contents of the SONET
> path.
> > It is the circuitry that recovers the payload from the SONET path that is
> > simpler if that payload is byte aligned, since the byte alignment is
> already
> > provided by the section framer.
>
>Please excuse my ignorance of SONET nomenclature in advance. For the
>purposes of
>this discussion thread I am going to use agreed upon terminology from the
>agreed
>upon "WAN PHY DEFINITIONS" presentation prepared by Mr. David Law and ad hoc
>contributors including yourself:
>http://grouper.ieee.org/groups/802/3/ae/public/mar00/law_1_0300.pdf
>
>The first assumption I'll make is that P802.3ae has no objectives to
>develop or
>modify any architecture bounded by the "Line side" of SONET Line Terminating
>Equipment (LTE) as illustrated in slide 8. If this is not a valid assumption
>then don't bother with the rest of this note since I must be way off base and
>need to be educated further about SONET.
>
>If the above first assumption is correct, then my second assumption is that
>P802.3ae need not concern itself with SONET Section or Line framing and need
>only concern itself with SONET Path framing specific to the framing of
>Ethernet
>packets to a SONET path in a "SONET compatible" manner. Once again, if this is
>not a valid assumption on my part then don't bother with the rest of this note
>since I must be way off base and need to be educated further about SONET.
>
>The point of the above assumptions is to ensure that I and the IEEE P802.3ae
>committee fully understand the objectives we are tying to meet with respect to
>the WAN PHY. I like the way Mr. Rick Walker phrased this objective in a recent
>note to this reflector:
>
>"In any case, the Ethernet WAN phy does not need T1X1 capability. It is not
>intended to be a general replacement for SONET. It is only a dedicated
>wrapper
>for *pure* 10 GbE streams."
>
>Getting back to the issue I raised in point (1) above and your response: You
>indicated that the circuitry that recovers the payload from the SONET path is
>simpler if that payload is byte aligned, since the byte alignment is already
>provided by the section framer. I with this and how it fits with both the
>Martin
>et. al. WAN PHY proposal and Frazier et. al. UniPHY proposal. In both cases
>information relevant to all SONET framers are byte aligned.
>
>In the case of the Martin et. al. WAN PHY proposal, byte alignment is
>maintained
>through the WAN PHY Path, Line and Section.
>
>In the case of the Frazier et. al. UniPHY proposal, byte alignment is
>present in
>the UniPHY PCS, and is converted to 66-bit alignment by the UniPHY PCS
>(64B/66B). The UniPHY SONET path framing is byte aligned with the exception of
>the 10 GbE payload, which remains 66-bit aligned. UniPHY SONET path framed
>data
>is passed to the SONET LTE and handled like any other Path multiplexed
>data. The
>10 GbE specific payload is not byte-aligned in the case of the Frazier et. al.
>UniPHY proposal. However, I don't perceive this characteristic as being
>relevant
>or disadvantageous in any respect.
>
> >> 2) What is your definition of payload delineation mechanism for the WAN
> >> PHY? More specifically since this issue questions the SONET
> >> interpretation of word size alignment, if the WAN PHY is UniPHY,
> >> the PCS is 64B/66B + SONET framing + SONET scrambling. Therefore,
> >> for the UniPHY, the payload delineation mechanism is the 64B/66B
> >> decoder. Is there some other requirement for the SONET transport
> >> to perform payload delineation?;
> >
> > Examples of payload delineation mechanisms, which occur after SONET section
> > framing and after SONET pointer processing to locate the SONET path: (a)
> > 64B/66B case - hunting for the 2 bit 01 or 10 pattern every 66 bits; (b)
> > <lngth><type><HEC> case - hunting for an 8 byte string which has a CRC-16
> > which matches the 2 byte value following the 8 byte string. Case (a)
> > requires searching by bit. Case (b) requires searching by byte.
>
>I agree with your definitions which point out the differences between the
>a) Frazier et. al. UniPHY proposal
>b) Martin et. al. WAN PHY proposal
>
>The next question in line is whether you agree that both proposals meet
>P802.3ae
>objectives for the WAN PHY?
>
>I assume that the specific objectives in questions are:
>
>"Define two families of PHYs
> A LAN PHY, operating at a data rate of 10.000 Gb/s
> A WAN PHY, operating at a data rate compatible with the
>payload rate of OC-192c/SDH VC-4-64c"
>
>and that the second bullet objective (WAN PHY) can be met by either (a) the
>Frazier et. al. UniPHY proposal or (b) the Martin et. al. WAN PHY proposal.
>
> >> 4) Your last comment about bit-slipping vs. byte-slipping involving more
> >> circuitry is incorrect with respect to 64B/66B code vs. SONET framing.
> >> First of all, this "slipping" operation is part of the link
> >> synchronization function and need not be performed (at least for
> >> 64B/66B) once the link is in sync. For 64B/66B link synchronization
> >> is performed by syncing on either a b'01' or b'10' pattern with 66-bit
> >> periodicity. I don't know SONET that well, but my understanding is
> >> that you're looking for a many byte pattern which occurs every
> >> 155,000 or so bytes. I believe it's safe to say that 64B/66B
> >> bit-slipping involves significantly LESS circuitry than SONET
> >> byte-slipping. Please tell me if I mis-interpreted your "slipping"
> >> comment in any way.
> >
> > The slipping operation is performed on link synchronization. Of course that
> > circuitry is still there after link sync is achieved, it's just burning
> > power. Your reference to the byte pattern search is the SONET section
> > framer operation, which is common for either 64B/66B or <length><type><HEC>
> > mappings into a SONET path.
>
>Thanks for the clarification on when the slipping operation is performed.
>We are
>in agreement that slipping is only performed during link synchronization.
>
>I didn't get a response from you regarding my assertion that 64B/66B
>bit-slipping involves significantly LESS circuitry than SONET byte-slipping.
>Could you please respond to this point? I believe the Frazier et. al. UniPHY
>proposal has a huge advantage over the Martin et. al. WAN PHY proposal on this
>point.
>
>With respect to your assertion that slipping circuitry is always there and
>burns
>power after synchronization, this may be required in the case of SONET but is
>clearly not required for the case of block codes such as 64B/66B and
>8B/10B. In
>fact, CMOS implementations derive significant power benefits by not switching
>states. Since it is very simple to check that a 64B/66B stream is still in
>sync
>after acquiring sync, there is no need to enable sync logic, thereby
>saving the
>power of this logic. However, I must point out that this is an implementation
>issue, not a P802.3ae standards issue.
>
> > ...Dave
> >
> > David W. Martin
> > Nortel Networks
> > +1 613 765-2901
> > +1 613 763-2388 (fax)
> > dwmartin@xxxxxxxxxxxxxxxxxx
>
>--
>
>Best Regards,
>Rich
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
>Santa Clara, CA 95054 http://www.nSerial.com
Best Regards,
Devendra Tripathi
Vitesse Semiconductor Corporation
3100 De La Cruz Boulevard
Santa Clara, CA 95054
Phone: (408) 986-4380 Ext 103
Fax: (408) 986-6050
********************************************************************
Web: http://www.vitesse.com