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

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
>
>