RE: A Question about "Inter Packet Gap and SOP Lane alignment"
There is one clear reason to me. The magnitude of the quote-benefit-unquote
does not overcome the advantage of having common core definitions with Fibre
Channel and potentially Infiniband.
jt
>-----Original Message-----
>From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
>Sent: Wednesday, July 19, 2000 12:38 AM
>To: 'rtaborek@xxxxxxxxxxxxx'; HSSG
>Subject: RE: A Question about "Inter Packet Gap and SOP Lane alignment"
>
>
>
>Hi,
>I agree with Howard: Why do you need to be aligned during the IDLE?
>And about the technical problems:
>
>1.Whats the problem to do alignmenet on the LSS column as well?
>And if you want to avoid it:
>2.You can avoid Doing alignement on LSS column, and do very
>robust scheme a
>sfollows:
>
>Just do alignement on two (Or even three) consequtive Data
>columns. Minimal
>packet is about 16 data columns.
>
>Boaz
>
>
>> -----Original Message-----
>> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
>> Sent: Wednesday, July 19, 2000 2:28 AM
>> To: HSSG
>> Subject: Re: A Question about "Inter Packet Gap and SOP Lane
>> alignment"
>>
>>
>>
>> Howard,
>>
>> I believe that you realize full well that your suggestion is
>> a subversive
>> maneuver to derail LSS whose "words" have a similar "look and
>> feel" to a
>> Start-of-Packet delimiter.
>>
>> The format of an LSS word is /K/D/D/D/ where K is a special
>> character with the
>> meaning LSS. The format of a Start-of-Packet delimiter is an
>> SOP word /K/D/D/D/
>> where K is a special character with the meaning SOP. The same
>> general encoded
>> format is defined for transport on the XGMII, XAUI, the
>> 8B/10B PCS and the
>> 64B/66B PCS. The reason for this format is it allows a single
>> LSS word to carry
>> three bytes of data, plenty enough to function as an OAM&P
>transport.
>>
>> Your proposal to reconsider the use of /A/ for alignment and
>> instead perform the
>> alignment on the Idle-to-Data transition is not sufficiently
>> robust due to the
>> potential presence of LSS words in the Idle stream and
>> insufficient hamming
>> distance between the special characters for the various
>> interfaces which may be
>> traversed.
>>
>> Additionally, alternative PMDs such as the 1550 WWDM proposed
>> by Mr. Michael
>> Fisk of Luminent and Mr. Fred Mohamadi of Broadcom in May in
>> Ottawa may impart
>> significantly more skew between lanes than can be handled by
>> the current and
>> simple /A/ spacing. The spacing may need to be increased
>> significantly for the
>> 50 km 1550 WWDM links proposed in that presentation and
>> publicly exhibited at
>> N+I in May by you know who. It is a simple matter to increase
>> the /A/ spacing
>> since we currently use a simple counter. However, it is not
>> possible to use
>> Idle-to-Data transitions as you propose since the skew (I'm
>> still trying to
>> assess the exact number) may be larger than the minimum
>> Ethernet frame size
>> spacing.
>>
>> What is it about this "/A/K/R/O/ stuff during IDLE" that is
>> getting out of hand?
>> This sounds like more FUD. I still haven't heard a valid
>> technical argument
>> against LSS, only FUD. I also have not seen any robust
>> counter proposals.
>>
>> It is true that the current initialization protocol (for
>> 8B/10B based links)
>> allows for a link to initialize only when a packet occurs.
>> However, I hope that
>> the reader recognizes that this will result in needlessly
>> dropped packets and
>> that link initialization does not require packets. 8B/10B
>> links are continuously
>> signaled whenever the link hardware is powered. The
>> continuous signal is Idle.
>> The link initializes during Idle and is ready to go when a
>> packet arrives.
>> Whenever a packet transfer is requested by the MAC, the Idle
>stream is
>> interrupted. This operation is as simple, straightforward and
>> robust as can be.
>>
>> Howard Frazier wrote:
>> >
>> > Maybe we should reconsider the use of /A/ for alignment. We don't
>> > really need to use a special character for lane alignment.
> We could
>> > just as well perform the alignment on the IDLE->DATA transition at
>> > the start of each packet.
>> >
>> > All of this /A/K/R/O/ stuff during IDLE is getting out of hand.
>> > We would be better off with simpler rules for IDLE, like a
>> randomized
>> > sequence of Ks and Rs.
>> >
>> > In fact, if we did the alignment based on the transition from
>> > lane[0:3]=IDLE to (lane[0]=SOP & lane[1:3]=data), then we wouldn't
>> > need to maintain columns of Ks and Rs during IDLE. We
>> would just need
>> > to send a complete column of R once during IPG, for
>instance, on the
>> > column immediately following the T. IDLE could be random
>per-lane Ks
>> > and Rs at all other times.
>> >
>> > The IDLE insert/delete rules would remain unchanged.
>> >
>> > We don't really need to be aligned until there is a packet
>> to receive,
>> > and the first packet that a receiver gets can be used to
>> establish the
>> > lane alignment. If a receiver looses alignment, it will
>re-establish
>> > the alignment at the next start of packet.
>> >
>> > Howard Frazier
>> > Cisco Systems, Inc.
>>
>> --
>>
>> 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
>>
>