Re: Hari
Roy,
My responses to your questions are bracketed [ ] below.
At 10:36 PM 11/22/99 -0600, Roy Bynum wrote:
>Fred,
>
>Is or is not Hari a 8B10B encoding method? [yes]
>Is 8B10B the same encoding method that
>has been suggested for the WAN PHY? [There have been 12.5 Gb/s serial,
>8b/10b proposals made to the HSSG. Our latest proposal does not carry
>8b/10b out onto the serial data stream]
>If not, then there must be some sort of
>translation, almost another MAC bridge to take the 802.3 frames from the Hari
>interconnect and put them into another encoding method. Are you
>suggesting that we create another, secondary, MAC bridge just to support a
>different PHY? [No, encoder/decoders are not MAC bridges]
>Was this
>what was presented at York? [By whom?]
>I don't think that is what is in the objectives. [I believe the objectives
>include a 10 Gb/s MAC with LAN and WAN PHY families. I don't believe
>slowing HARI to an aggregate data rate of 9.58464 Gb/s, or 2.9952 Gb/s per
>8b/10b encoded line, is precluded. Neither is feeding this aggregate into
>a SONET LITE, or OC-192 Compatible framing device.]
>
>As for real estate on the PC board. Vendors need to think about reducing
>the size
>of their boards and systems. [They, and we, ARE]
>More and more floor space is being taken by these
>systems as well as power and cooling. Reducing the size of the boards,
>reducing the
>amount of electronics, reducing power requirements, and increasing the
>density of
>the connections is becoming an issue in large installations, like those
>that will
>use P802.3ae. Hari tends to take exactly the opposite direction in system
>design.
>Hari makes it easy for the system designer to become sloppy, not requiring
>them to
>become tighter and better. [Gates are cheaper than pins. If switch ASIC
>designers do not believe that HARI is a good choice for an ASIC interface,
>they should propose an alternative and make their case.]
Regards,
>Thank you,
>Roy Bynum
>
>Fred Weniger wrote:
>
> > Dear Ladies and Gentlemen:
> >
> > Before we commence constructing a DMZ between the LAN and WAN 10GbE camps,
> > may I remind one and all that Vitesse offered a proposal at the Kauai HSSG
> > which we believe will provide an alternative path to peaceful
> > co-existence. Our proposal allowed the MAC to run at 10 Gb/s, and
> > suggested a "pause" or "rate-match" function on the XGMII to allow HARI to
> > run at 2.9952 Gb/s on each of the four lines if it is intended for WAN
> > connection. We stated that a HARI to SONET LITE framer could be
> > implemented in CMOS, and could use the OIF-proposed standard 16- bit Serdes
> > to serialize the date in an OC-192 COMPATIBLE format. We, as chip makers,
> > believe this is quite achievable, and provides both camps with what they
> > want. If there are those who disagree, please reply.
> >
> > At 10:37 PM 11/20/99 -0600, Roy Bynum wrote:
> >
> > >Rich,
> > >
> > >I'm not sure what gave you the idea that Hari was favorable to serial
> > >PHYs. I do know that
> > >it is not favorable to anything other than the legacy fiber channel 8B10B
> > >LAN PHY. Hari is
> > >NOT a PHY neutral device interconnect. Some LAN vendors have very huge
> > >boards and they want
> > >
> > >something that will support their 8B10B encoding over the distance of
> > >their board, and also
> > >the back plane if needed. By introducing Hari as the standard for device
> > >interconnect
> > >between the PMA and the PMD, they are specifically, and possibly
> > >knowingly, hampering the
> > >development of the agreed on WAN PHY. There is no mechanism for rate
> > >controlling over
> > >Hari. This is in violation of the agreed objective in this regard. Hari
> > >is an attempt by a
> > >specific camp to control the development of 10GbE and limit development of
> > >anything other
> > >than the 10.0 only rate PHY.
> > >
> > >As you will remember, I called the presenters and floor on the issue of
> > >what Hari really
> > >was. It was admitted that it was a LAN extension interconnect by the
> > >individual that
> > >responded. For those of us that are attempting to bring 802.3 into the
> > >20th century by
> > >making a truly ubiquitous MAC, we have been astounded by the brazen push
> > >of this
> > >"interconnect". Chip makers will confirm that Hari specifically makes
> > >the WAN PHY
> > >extremely difficult to implement. Since Hari truly is not common to all
> > >of the PHYs as
> > >specified in the objectives, I suggest that it be withdrawn from
> > >consideration as part of
> > >the 10GbE standard.
> > >
> > >Thank you,
> > >Roy Bynum
> > >
> > >
> > >
> > >Rich Taborek wrote:
> > >
> > > > Roy,
> > > >
> > > > I thought that Hari was clearly presented in at least half a dozen
> > > presentations by at
> > > > least the same number of presenters who all explained it in the same
> > > way in Kauai. I'll
> > > > try one more time here.
> > > >
> > > > Hari is the same as the Serial interface of the 10 GMII as presented to
> > > the HSSG by
> > > > Howard Frazier of Cisco in Montreal, York and Kauai. A group of
> > > Ethernet, Fibre Channel,
> > > > InfiniBand and even OIF folks have gotten together over the past
> > > several months to try
> > > > and arrive at a common interface for passing 10 Gbps of data
> > > continuously in each
> > > > direction between a PCS/PMA element (which may be integrated with the
> > > MAC and the PMD
> > > > (i.e. transceiver module).
> > > >
> > > > Note that a typical Ethernet PHY, like 1000BASE-X contains the PCS, PMA
> > > and PMD
> > > > sublayers. Hari is NOT a PHY nor is it a PHY sublayer. Hari is an
> > > interface between
> > > > sublayers and is very similar in nature to the Ten-Bit Interface (TBI)
> > > of 1000BASE-X,
> > > > which is fully described in Clause 36 of that standard.
> > > >
> > > > Hari has nothing at all to do with WWDM although it clearly may be used
> > > to attach a WWDM
> > > > PMD to its MAC/PCS/PMA.
> > > >
> > > > Hari may be used to attach a Parallel Optical PMD to its MAC/PCS/PMA in
> > > much the same
> > > > fashion as for WWDM
> > > >
> > > > Hari usage to attach a MAS PMD to its MAC/PCS/PMA has been described in
> > > all my MAS
> > > > proposals to the HSSG including the latest update presented in Kauai:
> > > >
> > >
> http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_2_1199.pdf
> > > >
> > > > Hari usage to attach a Serial PMD to its MAC/PCS/PMA along with a
> > > proposed coding to
> > > > maintain a line rate of ~10 Gbaud has been described in the Kauai
> > > proposal by Rick
> > > > Walker and Richard Dugan of Agilent:
> > > >
> > >
> http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/walker_1_1199.pdf
> > > >
> > > > Therefore, Hari provides a common interface for all major classes of
> > > PMDs proposed to
> > > > the HSSG to date in addition to being strongly considered as a common
> > > interface for
> > > > other ~10 Gbps standard and industry interfaces.
> > > >
> > > > The principal strengths of Hari are:
> > > > 1) Low pin count
> > > > 2) Self-timed (doesn't need a clock with data)
> > > > 3) Supports reasonable distances over inexpensive medium (e.g. 20" of
> > > FR4 traces)
> > > > 4) Good synergy with traditional Ethernet MAC/PHY framing
> > > > 5) Sufficient robustness to not compromise a 10E-12 link BER
> > > >
> > > > 8B/10B encoding has been proposed for Hari since it has been proven
> > > time and time again
> > > > in multiple forums that 8B/10B is a very robust serial link
> > > transmission code. However,
> > > > Hari is not a PCS and an alternate code could have been proposed for
> > > Hari. I consider
> > > > the Hari usage of 8B/10B to be analogous to a parity bit for a
> > > traditional parallel
> > > > interface. The "parity bit" can be generated at the source and
> > > discarded after checking
> > > > at the destination. The MAS and Serial PMD proposals referenced above
> > > use Hari in
> > > > exactly this fashion and result in the lower line rate possible for
> > > those respective
> > > > interfaces when compared to a PMD coding which would carry forward the
> > > 8B/10B overhead.
> > > >
> > > > Hari is being proposed for inclusion into the 802.3ae standard as an
> > > interface as
> > > > described above. However, Hari does not dictate the encoding of data
> > > transported over
> > > > the Medium. Hari simply enables the transport of that data over the
> > > medium in a manner
> > > > commensurate with the 5 criteria of 802.3ae.
> > > >
> > > > As such, I would also recommend that Hari be considered for the WAN
> PHY.
> > > >
> > > > Best regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > Roy Bynum wrote:
> > > >
> > > > > Rich,
> > > > >
> > > > > I am confused here. Is Hari being proposed as a PHY for the LAN
> > > compatible PHY of
> > > > > 10GbE? I have recognized that Hari only needs the WWDM optical
> > > interface to be a 4
> > > > > wavelength parallel short reach PHY. When it was first presented,
> > > the way that it
> > > > > was presented reminded me of a "solution looking for a problem". It
> > > certainly looks
> > > > > like there are a lot of people have been working on this for some
> > > time. All of the
> > > > > conversations on the reflector are starting to treat Hari as a PHY,
> > > not a device
> > > > > interconnect. I am confused why an interconnect suitable to be a
> > > full LAN PHY would
> > > > > be proposed first as a device interconnect. As a 500m and less LAN
> > > PHY, I am
> > > > > neutral on Hari. As something else, I confused by the way it was
> > > presented and have
> > > > > my doubts as to the overall impact of Hari as a device interconnect
> > > and the
> > > > > limitations that it inherently makes on the PCS/PMD relationship.
> > > > >
> > > > > Hari as a device interconnect requires specific functionality. It
> > > forces the
> > > > > physical coding functionality of non parallel PHYs to exist at the
> > > PMD, not the
> > > > > PCS. I have been told by a Hari supporter that the PCS/PMA/PMD
> > > relationship is
> > > > > purely for the standard and has little relationship to how protocols
> > > are implemented
> > > > > and devices are actually designed. If device and protocol
> > > implementation has little
> > > > > to do with the standard, why have the standard? If the protocol
> > > implementation is
> > > > > specific to the standard, then Hari is a PCS specific to a particular
> > > PHY and is
> > > > > exclusive of other PCS definitions for other PHY definitions.
> > > > >
> > > > > If Hari is a PCS, let us recognize it as such and move on with
> other PHY
> > > > > definitions. If it is not a PCS then let us recognize that it will
> > > alter the nature
> > > > > of the relationships of the PHY functionalities for the non-WWDM PHYs
> > > dramatically.
> > > > > A silicon designer can best determine if the increase in complexity
> > > of the PMD is
> > > > > countered by the pin count benefits of Hari as something other than a
> > > PCS. Hari as
> > > > > a device interconnect needs to be removed from the table. Hari as a
> > > PCS, with minor
> > > > > modifications can be evaluated as such.
> > > > >
> > > > > Thank you,
> > > > > Roy Bynum
> > > > >
> > > > > Rich Taborek wrote:
> > > > >
> > > > > > 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_119
> > > 9.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.
> > > >
> > > > ----------------------------------------------------------
> > > >
> > > > 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
> >
> > Fred Weniger
> > Gigabit Product Marketing Manager
> > 805-388-7571
> > weniger@xxxxxxxxxxx
Fred Weniger