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"




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