Re: Hari as 10 Gig Fibre Channel
The inherent reasons are:
a) The ability to locate a transceiver a significant distance (a foot or two)
away from the protocol ASIC(s);
b) The ability to use a low-cost technology (e.g. CMOS) to drive the
c) The ability to use common PCB material to to build 10 Gbps products;
d) The desire to keep microwave technology, if required at all, isolated to a
small part of the transceiver;
e) Per port cost. What is your cost target at maturity with the interconnect
technology your proposing? Please consider all costs. Is is 3.5X GbE port cost
at maturity? If not. This is the primary reason for a low-cost ubiquitous
interface like Hari.
Patrick Gilliland wrote:
> I have to agree with Roy. There is no inherent
> reason why the PMD interface should be a HARI.
> The best PMD interface for a 10GbE optical transceiver
> is a 10Gbit/s serial data stream.
> Only if one assumes there will be a multi-channel
> or a single multi-level channel PMD is an interface
> like this one necessary to discuss.
> Patrick Gilliland
> At 10:31 PM 11/28/99 -0600, you wrote:
> >Perhaps the NCITS TC T11 is the correct forum to standardize on Hari.
> Please remove it as a
> >specific functional standard within P802.3ae. Please make it possible for
> the people
> >working on the PHYs to apply the functional implementations that are
> needed for the specific
> >PHYs. According to the 802.3 model the PHY specific coding occurs within
> the PCS, not the
> >PMD. Applying Hari between the PMA and PMD violates that model!
> >Hari is only a requirement for those people that decided on the PHY of
> choice before the
> >HSSG got a chance to vote on it/them, and jumped the gun on their ASICs.
> As far as I am
> >concerned those people can implement anything they want, as long as they
> do not make it part
> >of the P802.3ae standard.
> >Right now several people are upset because I have challenged their
> perceived control of the
> >development of 10GbE. I have brought disorder where they thought that
> they had imposed
> >order, their order. They are correct. I challenged their perceived view
> of Ethernet as a
> >confined protocol, when they did not understand how Data Link protocols
> are used and what
> >makes them functionally different. They did not understand that the
> developers of GbE
> >brought the disorder first by crossing the boundary between confined LAN
> application and
> >unconfined WAN application.
> >The application of Fiber Channel technology and functionality helped cause
> that disorder.
> >Most FC applications have response timing limitations (100x ms) at the
> application level,
> >which makes most FC implementations Local. Putting Fiber Channel under
> applications that do
> >not have those same response timing limitations removes the Local only
> limitation. FC is
> >designed for campus facilities, using privately owned fiber. The GbE
> people incorrectly
> >thought that they too were making GbE into a Local only protocol. They
> did not understand
> >that the full duplex nature of the original Ethernet, applied through
> 100mb 802.3 was what
> >made it truly Local only. Even the electrical full duplex 100BT can be
> used across a long
> >haul fiber system by putting it into an optical transducer. Full duplex
> 100FX has been used
> >across long distances with wavelength/power transducers. GbE is taking
> off as a leased
> >fiber WAN protocol, without service operations support.
> >I am not the cause of the disorder here. The people that did not fully
> understand the
> >implications and applications of what they were doing are the cause of the
> disorder. Please
> >do not codify that disorder within P802.3ae.
> >Thank you,
> >Roy Bynum
> >Rich Taborek wrote:
> >> Earlier this week, NCITS Technical Committee T11, chartered with
> development of the
> >> Fibre Channel suite of standards, approved a project proposal to extend
> FC protocol to
> >> an operating speed of approximately 10 Gbps, following the lead of the
> IEEE 802.3
> >> committee. The project proposal, entitled FC-PI-2 to identify the
> documentation effort
> >> associated with the 10 Gig FC project, was approved by T11 Letter Ballot
> on Monday,
> >> November 22, 1999 by a vote of Yes63-No02-NotVoting10 (4 yes ballots
> included comments).
> >> Further details and comments can be found via the T11 web site @
> http://www.t11.org/ by
> >> clicking on "ballots", then "closed ballots", then "T11 Ballot - FC-PI-2
> PP approval".
> >> The next step is to forward the project proposal to NCITS, T11's parent
> body. The
> >> FC-PI-2 project proposal can be found @
> >> ftp://ftp.t11.org/t11/admin/project_proposals/99-521v1.pdf.
> >> An introductory meeting to kick off the 10 Gig FC project will be held
> during the next
> >> T11 Plenary week on December 8, 1999 at the Peppermill Hotel in Reno,
> NV, USA, during
> >> the joint session of the T11.2 (FC Physical Layer) and T11.3 (FC
> >> committees. This meeting is scheduled for 1:00-2:00 PM. Further T11
> Plenary week details
> >> can be found by clicking on "meetings" from the T11 home page.
Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
Tel: 408-330-0488 or 408-370-9233 Cell: 408-832-3957
Email: firstname.lastname@example.org or email@example.com