RE: A Question about "Inter Packet Gap and SOP Lane alignment"
Rich and Jonathan,
While Infiniband shares a line code with XAUI, it does not use the same
"primitive link protocol." The idle, approach to deskew and clock
compensation are all different between the two. We may get commonality
between some of the other standards you mention, but not between those
two. I did present the Ethernet idle to the Infiniband group, but got
no support for changing Infiniband to harmonize it. I believe that
the probablility of common definitions with Infiniband is near zero.
I notice that in Rich's example the packets are significantly shorter
than the minimum Ethernet packet length which would be two columns of
preamble/SFD plus 16 columns of data. Was your example meant to
cover the shorter packets of Fibre Channel?
I point these things out because I have trouble resisting technical
discussions. However, we have adopted an interpacket gap proposal
and it has not been shown to be broken. There are a lot of other
ways idle, IPG's, and deskew can be handled effectively, but we've
already picked a method (113 to zip) so I don't understand why we
are getting proposals to fool with it so soon.
Regards,
Pat
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Wednesday, July 19, 2000 5:54 PM
To: HSSG
Subject: Re: A Question about "Inter Packet Gap and SOP Lane alignment"
Jonathan,
I absolutely agree with you about the advantages of having the same
primitive
link protocol, components, measurement and compliance techniques, etc. be
applicable to Ethernet, Fibre Channel, InfiniBand, OIF, proprietary
backplane,
etc. applications.
Boaz,
As I pointed out in a prior note on this thread, lane-to-lane deskew CANNOT
be
performed with the SOP column, and therefore, with LSS columns since there
the
spacing of the alignment reference is less than the maximum lane-to-lane
skew in
some environments. The specific environment which breaks your suggestion is
1550
WDM with its large lane-to-lane skew. Please consider the following:
8B/10B encoded stream at transmitter:
.....KRLRRKRLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRRR.....
.....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
.....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
.....KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
8B/10B encoded stream at receiver:
KRLRRKRLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRRR................
...........KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
...........KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR.....
..KRDRRKRDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRRR..............
My question to you is how the receiver is supposed to align to/deskew if it
is
using either LSS or packet data columns, even consecutive columns? Since the
receiver starts out with no lane sync and with lanes significantly skewed,
what
is the receivers reference point (i.e. which code-groups in each lane at the
receiver are related)? Note that the same problem exists in the absence of
LSS
words, rendering LSS an orthogonal issue to lane-to-lane deskew.
The simple and accepted P802.3ae /A/ spacing proposal solves this problem by
providing a minimum guaranteed /A/ column spacing. This minimum /A/ spacing
is
flexible and can easily accommodate the maximum skew of any proposed PMD.
Using
/A/ columns (extending the spacing to 32 min), the 8B/10B encoded stream at
receiver would look something like this:
KRLRRARLKSDDDDDDDTKRSDDDDDDDTKRSDDDDDDDTKRLKRAR................
...........KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR.....
...........KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR.....
..KRDRRARDKDDDDDDDDKKRDDDDDDDDKKRDDDDDDDDKKRDKRAR..............
Note that there is NO ambiguity as to which code-groups in each lane are
related
(i.e. were simultaneously transmitted) even in the presence of LSS and
standard
minimum size Ethernet packets.
Please tell me if there is a flaw in my logic somewhere because I am anxious
fix
it if there is. I'm also very interested to any simplifications to the
P802.3ae
baseline proposals which work.
Best Regards,
Rich
--
Jonathan Thatcher wrote:
>
> 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
> >>
> >
-------------------------------------------------------
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