Steve,
Again, this is Ethernet, not SONET/SDH. Enough said. Further, you
continue to blast the WAN/LAN solutions defined today. A lot of people
worked very hard to define those solutions. I resent your implications
that issues between LAN and WAN reside solely on the rate between them
and that 10G was the culprit . There are many issues, not all can be
addressed by IEEE802.
Last, reading below, I interpret your words that you want to define
some sort of bridge or direct port/lane/speed mapping function that
would exist above or at the top of the MAC function for SONET/SDH
applications that support the use of Ethernet in none standard
applications. I believe this is clearly outside the scope of the HSSG
charter. We need to focus on standardized applications as applied to
Ethernet.
-joel
Trowbridge, Stephen J (Steve) wrote:
Geoff,
With all due respect, at 10G
there were two rates and frame formats defined:
- 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 payload).
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 today.
- 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.
Regards,
Steve
Steve-
At 10:50 AM 9/4/2006 , Trowbridge, Stephen J (Steve) wrote:
Geoff,
We clearly have a problem at 10G that certain players have taken
Ethernet to be more than a packet network:
- We have the situation that people have put information in parts of
the frame not designed for carrying information (the preamble and IPG).
- 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
perception).
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 approaches:
- 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.
Sounds like a no-brainer to me.
(Further, I am of the belief that changing the frame format is outside
the scope of "Higher Speed")
Geoff
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.
Regards,
Steve
- 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
- At 03:46 PM 9/3/2006 , Trowbridge, Stephen J
(Steve) wrote:
- Geoff,
- If only it were so simple ...
-
- It is.
- Ethernet is a packet network, not a bit or circuit
network.
- Geoff
|