Re: [HSSG] Reach Objectives
With all due respect, at 10G there were two rates and frame
- The 10G LAN PHY, which some take to mean 10G BASE-R at
10.325 Gbit/s including the 64B/66B coding
- The 10G WAN PHY, which is built inside of a SONET/SDH
wrapper at 9.58464 Gbit/s including 64B/66B coding.
As much as we wish that customers would all choose the LAN
interface when they want to connect to a LAN and the WAN interface when they
want to connect to a WAN, this hasn't happened. We see numerous cases for a
variety of different reasons where people ask to take the 10G LAN PHY and carry
it over a long distance.
There are some straightforward kinds of approaches to do
this if you start from the assumption that Ethernet is really a packet interface
and all you need to do is preserve the packets across the transport network. For
example, you can carry your 10G LAN PHY by mapping it into an ODU2, decoding
64B/66B, dropping the preamble and IPG and replacing with GFP framing (saving
8-12 octets per packet) and using the OTN scrambler and get the full packet
throughput of a 10G LAN PHY over a 10G transport network interface. At the far
end, you reverse the process and regenerate a 10G LAN PHY signal with the same
packet information content. But this breaks any proprietary stuff that people
are doing with the preamble and IPG and seems to have an "image problem" with
some operators that you are fiddling too much with the customer's stuff (even
though most of us understand that this approach doesn't touch the
Let me express the two suggestions that I am making for how
we approach future interface definitions in terms of what it would have looked
like had we done this at 10G:
- ONE RATE AND FORMAT - if we had recognized early enough
that WAN was an important application and tried to unify things to the greatest
extent possible, we might have elected that the XGMII being freshly defined
wasn't exactly 10.00000000000 Gbit/s, but instead, say 9.282944 Gbit/s (if we
decided that SONET/SDH was the dominant transport mode to be targeted) or
9.721329 Gbit/s (if we decided that OTN was the dominant transport mode to be
targeted). Then you could have taken exactly the same 64B/66B coded bitstream
that you used for the LAN and filled it directly into transport frames, and poof
you are done. You wouldn't have had any of the market issues we see
- REPEATER DEFINITION - If we were to define a repeater
that regenerates preamble & IPG and have a requirement that anything that
works in a point-to-point configuration must also work across a repeater, we
could discourage some of this proprietary stuff. If we then define that any
layer 1 server layer network is supposed to meet the requirements for a repeater
(appropriately defined), then you have the flexibility to use things like GFP
framing over a transport network to get the extra throughput you need to fully
carry all of the packets of a 10G LAN PHY Ethernet signal over a 10G
transport network interface.
At 10:50 AM 9/4/2006 , Trowbridge, Stephen J (Steve)
We clearly have a problem
at 10G that certain players have taken Ethernet to be more than a packet
- We have the situation that people have put information in
parts of the frame not designed for carrying information (the preamble and
- We have the problem that some customers think that the entire
frame format, not just the payload is sacred and must not be touched (some
of this stems from the first problem, other parts of this problem are
I think that
it is worth some effort and careful though to make sure that this does not
happen as we define interfaces for the next rate, e.g., that we keep it
simple, and keep it as a (pure) packet network.
I think that there are two possible
- We could make sure that we define ONE frame format
and data rate that works in all contexts
You mean we could
continue to "define ONE frame format and
data rate that works in all contexts"
vs. doing something else, i.e.
define a new frame format which does not work in all contexts.
a no-brainer to me.
(Further, I am of the belief that changing the
frame format is outside the scope of "Higher
This is starting to sound doubtful from the
opinions expressed, but if we COULD achieve a single specification and
ensure that anything that transits one medium would transit another, we
could avoid these kinds of problems.
- I touched on this in the
last email, but we could produce a repeater spec covering all interfaces and
frame formats, e.g., if you have phsycial interfaces/frame formats X and Y,
the repeater spec tells you enough that you could to build X<->X,
Y<->Y and X<->Y repeaters and only what we consider to be the
essential or characteristic information (the payload) would transit the
repeater. We could indicate that any server layer network should meet the
requirements for a repeater. Doing this might discourage inappropriate use
of the frame format to implement proprietary things that would break if you
put a standard repeater between the boxes.
At 03:46 PM 9/3/2006 , Trowbridge, Stephen J (Steve) wrote:
- From: Geoff Thompson [mailto:gthompso@xxxxxxxxxx]
- Sent: Sunday, September 03, 2006 8:47 PM
- To: Trowbridge, Stephen J (Steve)
- Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
- Subject: Re: [HSSG] Reach Objectives
If only it were so simple ...
Ethernet is a packet network, not a bit or circuit