Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>> 
>