Assumptions and questions
- To: <stds-802-3-hssg-speed@xxxxxxxx>
- Subject: Assumptions and questions
- From: "Jonathan Thatcher" <jonathan@xxxxxxxxxxxxx>
- Date: Tue, 15 Jun 1999 14:58:10 -0600
- Importance: Normal
- In-Reply-To: <37E04260A7BBD211AF0F0090272A827117B41E@xxxxxxxxxxxxxxxxxxx>
- Sender: owner-stds-802-3-hssg-speed@xxxxxxxxxxxxxxxxxx
All,
It would seem to me that there are a couple of issues related to assumptions
that need to be cleaned up prior to turning on the afterburners.
1a. Does anyone believe that we can set the speed to the 9.66 Gig only (i.e.
not support 10.00000000000 Gig)?
1b. If not, is it possible to have a single speed XGMII and support two PHY
speeds?
1c. If not, can the speed change be restricted to the reconciliation layer?
1d. If not, does anything special need to be done for a MAC that can support
both speeds?
2a. If an OC-192 speed were to be supported, is forward error correction a
desire or a requirement?
2b. If it is a requirement, can it be implemented without affecting the MAC?
2c. If it must affect the MAC, what is the bound?
It is my observation (having talked to a fair number of people) is that:
A. Many people believe that 10.00000000 Gig is required (not just 10 gig
when rounded up from 9.x).
B. Many people are interested in not touching the MAC (save the change to
make it speed independent).
C. There is a strong split between supporting WAN and attaching to the WAN.
It is my opinion that we cannot say yes (75%) to 1a. I would like to think
we can say yes to 1b (or worst case, 1c with an ability to simultaneously
implement both reconciliation layers easily in hardware).
I have no idea what the answer is to 2a (but I expect to hear that it is a
requirement). I would like to think that we can find a way to say yes to 2b.
This might mean that the standard gives the definition and the
implementation is done differently.
jonathan
- References:
- Assumptions
- From: "Thirion, Walt" <wthirion@Level1.com>