Re: Hari and train-up sequences
Hi all,
A general comment about link initialization... Although sending Idles
is sufficient for deskew given the remote side is receiving them, it
is not enough to ensure proper link initialization. For example, the
receiving side may not be "plugged in", or it may have just booted. If
the receiving side doesn't receive enough idles or any idles, it may
not be able to deskew properly.
There should be a link initialization defined so that before a station
transitions from transmitting its idle sequence to transmitting
frames, it knows that the station at the far end has synced up (found
commas, PLLs are locked, finished deskew). This sequence will be
useful not only during system bootup, but also when loss of sync
occurs following normal operation.
I realize that adding Autonegotiation as an PAR objective failed in
York. I take this as a backlash to complexity involved in using fast
link pulses to distiguish between 1Gig and 10Gig. Its good to keep
things sweet and simple, however, we should not throw out useful and
needed functions served by Autonegotiation. For one, we are going to
need some form of link init. This is as simple as a two part handshake.
Going one step further, I think its a minor increment to send PAUSE
information during link init so that system admins don't have to
think about how to set up their networks. This is especially useful
when stations speak asynchronous Pause.
Linda
> Delivered-To: stanfordalumni.org%linc@xxxxxxxxxxxxxxxxxx
> X-Received: 15 Nov 1999 04:13:32 GMT
> Date: Sun, 14 Nov 1999 18:54:28 -0800
> From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: HSSG <stds-802-3-hssg@xxxxxxxx>
> Subject: Hari and train-up sequences
> Content-Transfer-Encoding: 7bit
> X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> X-Listname: stds-802-3-hssg
> X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
> X-SMTP-HELO: c004.sfo.cp.net
> X-SMTP-MAIL-FROM: owner-stds-802-3-hssg@xxxxxxxx
> X-SMAP-Received-From: outside
> X-SMTP-PEER-INFO: c004-mx000.c004.sfo.cp.net [209.228.14.122]
>
>
> The purpose of this note is to clear up confusion regarding Hari, a
> proposed 4-lane serial interface for 10 GbE and train-up sequences.
>
> It should be clear that NO TRAINING SEQUENCES are proposed for Hari.
> Both the "Hari Coding Objectives" presentation
>
(http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_1_1199.pdf)
> and "Word Striping on Multiple Serial Lanes"
> http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/ritter_1_1199.pdf)
> make a point of noting that no train-up is required Hari to deskew.
>
> The Hari Coding Objectives proposal uses the standard Idle sequence
> proposed by Howard Frazier of Cisco to deskew multiple parallel lanes
> while simultaneously acquiring code-group synchronization on all lanes.
>
> --
> Best regards,
> Rich
>
> ----------------------------------------------------------
>
> Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
> Tel: 408-370-9233 Cell: 408-832-3957 Fax: 408-374-3645
> Email: rtaborek@xxxxxxxxxxxxx
>
>
>
---------------------------------------------------------------
Linda Cheng Cisco Systems
Desktop Switching Business Unit
(408) 527-2015 (phone) 170 West Tasman Drive
(408) 527-4698 (fax) San Jose, CA 95134-1706
---------------------------------------------------------------