Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Preparing for Idaho -- XGMII or whatever




Larry,

If you are arguing here that the interface to the upper layers may have to
by PHY dependent, I would very much like to encourage you to put your
thoughts together and reserve a slot at the June meeting for a brief
presentation.

jonathan

> -----Original Message-----
> From: Larry Miller [mailto:l_d_miller@xxxxxxxxxxxxx]
> Sent: Tuesday, May 18, 1999 5:08 PM
> To: Jonathan Thatcher
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: Preparing for Idaho -- XGMII or whatever
>
>
> It looks like the Media Independent Interface (xxMII) could
> also well depend
> on the signaling technology used.
>
> The single stream methods inherently present higher serial
> signaling bit
> rates which could be profitably used by some of the high end
> semiconductor
> technologies (such as SiGe?) at, say, the byte wide parallel interface
> level.
>
> If you were going to connect it to something operating at
> today's 1 GbE
> speed (approx. 125 MHz), and many companies might want to do just this
> because it fits their ASIC technology, you are looking at an
> 80 to 100 bit
> wide parallel interface.
>
> Some of the other signaling proposals do not generate serial
> streams that
> are so fast to start with, and the byte wide scheme might not
> fit well at
> all as an interface point. On these, the very wide parallel
> bus would work
> well, but then this would penalize the single-stream methods
> by effectively
> forcing them to include an additional deserialization which
> would take them
> down to parallel bus speeds below where they want to go.
>
> Like everything else about this, It's Going To Be Tricky, and
> there may not
> be a single solution that fits everyone.
>
> Larry Miller
> Nortel Networks
>
> -----Original Message-----
> From: Jonathan Thatcher <jonathan@xxxxxxxxxxxxx>
> To: stds-802-3-hssg@xxxxxxxx <stds-802-3-hssg@xxxxxxxx>
> Date: Tuesday, May 18, 1999 7:37 AM
> Subject: Preparing for Idaho -- expecting more requests for
> presentations
>
>
> >
> >Firstly, I would like to thank those who are bringing new
> information and
> >requirements to the table on the reflector. I am sure that we will be
> having
> >an interesting discussion concerning Ethernet over the WAN.... :-)
> >
> >During this first meeting, we will need to focus on a couple
> of simple
> >things:
> >1. A preliminary cut at our objectives.
> >2. A preliminary time line (objectives and goals for Sept interim).
> >3. A deeper review of potential technologies.
> >
> >I anticipate that we will spend all day Tuesday on the first
> two items. To
> a
> >large degree, this will be an extension of the "call for interest."
> >Extension implies "not simply repeating what happened at the previous
> >meeting."
> >
> >During conversations with Geoff, it was decided to postpone doing a
> tutorial
> >until the November Plenary. We agreed that it is premature
> to tell the 802
> >at large what we are about when we don't yet know what we
> are about. We are
> >therefore free to spend time that would have been dedicated
> to the tutorial
> >on the above goals.
> >
> >Per discussions at the "call to interest," it is pretty
> clear that there
> are
> >a number of things that need to be resolved fairly quickly
> in the timeline
> >(yes, I am implying that some things, like the
> "down-selection" of the
> >actual PHYs and the naming thereof can probably wait a while):
> >
> >1. What is the definition of the new common PHY interface (XGMII?)?
> >2. What are the potential encoding schemes? What are the
> tradeoffs? Is
> there
> >benefit making these PHY dependent (XGMII independent)?
> >3. What is the MATRIX of potential application spaces / PHY
> implementations?
> >How and where do these overlap? Are these defined by
> anything other than
> >distance? What are the criteria that will be used to select
> which of these
> >we END UP WITH? How do we know we are exploring ALL
> REASONABLE options?
> >4. What are we going to do with new fiber (high bandwidth;
> POF)? Are we
> >going stay with the Ethernet tradition of supporting the
> install base?
> >5. What interactions/relationships should we have with OIF;
> NGIO; FIO; FC;
> >etc? Should we fold in any requirements from these groups?
> >6. Do we need to support the installed WAN infrastructure?
> If so, how much
> >of it?
> >7. Since we are not the 10GigE Study Group, what speeds to
> we support? This
> >is not just a OC-192 vs 10 vs 12.5 gig question.
> >8. How do we move forward with idea of a speed independent MAC?
> >9. As we add length, what additional requirements come with
> it (from the
> >reflector: fast failure detection; reporting; diagnostics;
> subscription
> >control; maintenance support)? How do we balance the cost of these
> additions
> >against the gain? Against the tradition of Ethernet being
> the most cost
> >effective implementation for LANs?
> >10. When we do a new fiber survey, what information do we
> want reported
> back
> >and in what form?
> >
> >Etc.
> >
> >As of this time, there is a surprising dearth of requests for
> >time/presentation on these, and other key issues. Over the
> last couple
> >months, I have received informal requests for time. I would
> very much like
> >these to be formalized. What to do?
> >Send me a title; topic; presenter name; and estimated time for
> presentation.
> >If you are not sure you are "officially" logged, I won't be
> offended by a
> >redundant note.
> >
> >If you have a topic that you think is important to
> cover/discuss (e.g., set
> >up a discussion for a subsequent meeting based on requests
> for information)
> >but don't wish to build a presentation, send me a short note
> describing the
> >topic. We can put these on the agenda. This will allow us to
> conduct the
> >meeting according to Robert's Rules.
> >
> >Note, as chair, I will attempt to limit free-for-all
> discussion. While we
> >will have time for open discussion, my experience is that
> well thought out
> >presentations make for a better and more productive meeting. Hint!
> >
> >jonathan
> >
> >Jonathan Thatcher  "jonathan@xxxxxxxxxxxxx"
> >Chair IEEE 802.3 High Speed Study Group
> >Vice President Product Marketing, Picolight Incorporated
> >4665 Nautilus Court South, Suite 3, Boulder CO 80301
> >Phone: 303-530-3189 X238; Fax: 303-530-4897
> >
> >
>
>
>