Some of the discussion of 100Gb protocols has
been in the context of a 10 x 10Gb physical layer. It is early in the standards
process to reach this conclusion, and our discussions would benefit by not making
the assumption of 10 physical layer channels.
Part of our objective should be to define standards
that will operate over the existing infrastructure (for example existing
deployment distances: 10km, 40km, 80km,) and be amenable to low cost, high
volume manufacturing. The 10GBASE-LR, 10km standard is a good example, as it is
the most widely used 10G Ethernet SMF interface. It takes advantage of the low fiber
dispersion at 1310nm to use low cost DFBs. A 10 channel CWDM 100Gb
implementation would require a 200nm window, assuming today’s 20nm minimum
wavelength spacing limit for un-cooled optics. This would cause dispersion of the
shorter wavelength channels to approach 1550nm values. This can be compared to one
of the previously listed alternate approaches; 5 x 20Gb. Since the dispersion
effects at 20Gb are four times those at 10Gb, either approach will require a unique
set of technical solutions to deal with this problem. It is not apparent today,
which would result in lower implementation costs five years from now.
Chris Cole
From: David Martin
[mailto:dwmartin@xxxxxxxxxx]
Sent: Tuesday, September 05, 2006
10:11 AM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach
Objectives
Steve,
Some history on the 10GigE project…
Re: 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…
There were lengthy discussions on the
applications for 10GigE. Both LAN and WAN were recognized as important. But the
2 had different fundamental rate requirements, leading to the values we have
today. For example, a common test for an 802.1 bridge supporting the next
generation Ethernet line rate on its aggregated side is to fully fill 10
interfaces at the current Ethernet line rate on the lower speed side and
observe that no frames are lost through the higher rate interface. That was one
practical, backwards compatibility-based argument for LAN = 10.000G. And
you’re well aware of the WAN rate requirement.
The committee’s position was that a
standard 802.1 bridge would suffice to convert between the 2 interface rates.
Remember that the 802 committee is the
“LAN/MAN Standards Committee”, not WAN. It is a testament to the
participants of P802.3ae that they were open-minded enough to consider the WAN
PHY proposal.
Re: 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…
Since repeaters were not included within
the scope of P802.3ae, such work was launched through T1X1.5 and then migrated
to SG15, eventually becoming G.7041 GFP with related pieces in G.806, which of
course you’re well familiar with.
So the standards world did do its job.
The different rates are not the issue.
It’s the proprietary variants of the 10GigE LAN that are the problem. We
could have had a similar problem now with the WAN PHY if a vendor had made
proprietary use of its TOH. Then instead of directly connecting a 10GigE WAN
PHY signal into an OC-192 regen (i.e., its original intent), the WAN PHY signal
would have to be somehow entirely mapped into an OC-192, which of course
wouldn’t fit and we might have over-clocked OC-192s today instead.
So how does a standards body crystal ball
and preclude an equipment vendor from breaking a standard with proprietary
changes? That’s the issue. And the answer is obvious.
...Dave
David W. Martin
Nortel Networks
dwmartin@xxxxxxxxxx
+1 613 765 2901 (esn 395)
~~~~~~~~~~~~~~~~~~~~
From: Trowbridge,
Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
Sent: Monday, September 04, 2006
4:43 PM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach
Objectives
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
From: Geoff
Thompson [mailto:gthompso@xxxxxxxxxx]
Sent: Monday, September 04, 2006
12:27 PM
To: Trowbridge, Stephen J (Steve)
Cc:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach
Objectives
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