RE: A Question about "Inter Packet Gap and SOP Lane alignment"
Hi,
I agree that being similar to other industry standards is a considerable
benefit.
Rich, you asked:
>
> 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
Since the Max Skew is 4 columns, and Min packet length is 16, I think there
is no ambiguity.So, you work as follows: In first lane, Deskew condition is,
say, K/R,S,D. In others, its K/R,D,D. After this condition occures in a
certain lane it waits until it happens in the others. If it doesnt occur
within 4 column difference, you reset the condition and starts looking
again.
This is OK? If not please tell me why. Its very interesting to me. I think
the advantage is that you do alignment per frame, so if there is some
deviation you fix it on a per frame basis.
However, I agree it is more complicate than the/A/ method.
And, about my position here:
I understand that the committee agreed about the proposal in:
http://grouper.ieee.org/groups/802/3/ae/public/jul00/taborek_1_0700.pdf
(This is right?)
This decision is fine and makes sense, And I think it should be modified
slightly to add /A/ or /K/ (The missing one) to the third column if exists
before start randomization. I also accept the proposal to discuss it in the
review for the draft as Ben and others suggested, Although I'm not sure if
it so important to keep the 12 legacy in 10g.
Thx., an Best regards,
Boaz
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Thursday, July 20, 2000 3:54 AM
> 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.
I agree that being similar to other industry standards is a considerable
benefit.
>
> 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
>