Re: [HSSG] 40G MAC Rate Discussion
Maarten et all,
As a representative of the end user service provider community, it seems
to me that a 40G MAC would serve primarily as a business driver for
deeper penetration of STM-256/OC-768 transport as opposed to 100G at the
aggregation layer as some have claimed. 10GE (and 1GE for that matter)
as seen in multiple presentations over the last few meetings is already
driving the need for 100GE aggregation, so I am not quite sure I see the
benefit of both 40G and 100G in any aggregation environment.
Building an architecture utilizing 40G server interfaces with 100G
uplinks would seem to limit the number of efficient options at my
disposal. Some multiple of 5x2 would seem to be the only clear option.
Given the availability of both 10GE and 40GE interfaces and assuming
100GE uplinks I would be interested in seeing a presentation/s
demonstrating a strong case for the use of 40GE server handoffs vs 10GE.
It seems to me the real benefit/driver for a 40G MAC would be in the
Metro and Long-Haul Ethernet market and not as a host interface. This
thinking may be slightly myopic, but the real question for me is
assuming the standard is ratified in 2009 would users be presented with
two interface options at that time? If this were the case unless
economics outweighed versatility and capacity I can't see why the 40
would be a better choice than 100 given both options.
From: Maarten Vissers [mailto:Maarten.Vissers@ALCATEL-LUCENT.DE]
Sent: Wednesday, April 04, 2007 6:25 AM
Subject: Re: [HSSG] 40G MAC Rate Discussion
> I see more reason for a 40G optical standard that basically extends
> the OC192 10GE WAN PHY standard to OC768 as this would enable
> ethernet to be carried in current state of the art DWDM systems.
FYI, this standard exists for some time within ITU-T Recommendations.
Refer to http://www.ieee802.org/3/hssg/public/sep06/vissers_01_0906.pdf
for an introduction.
The frame format is shown in slide 8.
The applicable ITU-T Recommendations are listed on slide 16; for an
STM-256/OC-768 interface carrying Ethernet MAC frames those are:
- G.8012 Ethernet UNI and Ethernet NNI
- G.7041 Generic framing procedure (GFP)
- G.707 Network node interface for the synchronous digital hierarchy
- G.959.1 Optical transport network physical layer interfaces
- G.693 Optical interfaces for intra-office systems
> This would of course be a moot point if we think that most DWDM
> vendors will have a 100GE DWDM transponder by the time the 100GE
> standard is ready, and a 40GE OC768 compatible standard would take
> the same amount of time to implement as the 100GE variant.
Carrying 40GE within a STM-256/OC-768 signal allows to deploy today's
available 40G DWDM transponders. As such only a the STM-256/OC-768
compatible 40GE interface card within the Ethernet Switches or IP/MPLS
Routers is still required. With all standards available and existing
STM-256/OC-768 framer as well as Ethernet into GFP mapper devices
available, it is jsut the combination into a signle STM-256/OC-768 based
40GE device that is missing. As its design can start today, it could be
available soon, certainly before a 100GE design would be available.
> I do think that it should be taken into account that a 100GE standard
> will be carried over DWDM, and mechanisms should be implemented for
> fast-failure-detection, mostly of the "there is a one-way fiber
G.709 compliant DWDM systems/networks include such
mechanism as well as a means to signal such fault to the connected
i.e. the clause 16.6.1/G.709 "generic-AIS" mechanism. The generic-AIS
signal is a signal with a 2047-bit polynomial number 11 (PN-11)
For STM-256/OC-768 based 40GE interfaces these fast-failure-detection
signalling mechanisms are defined and will be available in designs of
itnerface ports and are available in associated 40G transponders.
> and the "the BER is high so the link is not good".
The STM-256/OC-768 based 40GE formats include BER detection capabilities
via the B2 and B3 bytes in the frame. It furthermore includes a BCH-3
PS. There is an alternative 40GE interface standardised in ITU-T
recommendations; this is the OTM-0.3 based 40GE interface using the
(OTN OTU3/ODU3, see slide 9) frame instead of the G.707 (SDH/SONET
VC-4-256c/STS-768c, see slide 8) frame. This OTM-0.3 based 40GE includes
RS(255,239) FEC, BER detection capabilities and fast-failure-detection
Mikael Abrahamsson <swmike@SWM.PP.SE>
Please respond to Mikael Abrahamsson
Subject: Re: [HSSG] 40G MAC Rate Discussion
On Tue, 3 Apr 2007, Shimon Muller wrote:
> Nothing magic about 40Gb for servers, just as there is nothing magic
> about a 10x scaling factor, except for tradition. 40Gb happens to be
> the right ballpark for server needs in that timeframe, and it will be
> the right cost.
I represent a customer view here.
My coworkers who run servers seem to have no problem with link
and they have a history with four port FE cards and they're now doing
with gig ports when they need it. The only 10GE attached servers we have
exist in the network lab for cheap packet generation.
Myself, being a network engineer, I see operational problems with more
than 4 links in a LAG but 4 is quite ok. I therefore see little reason
a 40G server speed, as this can be solved by 4*10GE LAG. A 10x scaling
factor makes sense because 10 links in a LAG starts to create
problems with proper load balancing, how you manage them both physically
and logically, and a host of other problems that is better solved on the
I see more reason for a 40G optical standard that basically extends the
OC192 10GE WAN PHY standard to OC768 as this would enable ethernet to be
carried in current state of the art DWDM systems. This would of course
a moot point if we think that most DWDM vendors will have a 100GE DWDM
transponder by the time the 100GE standard is ready, and a 40GE OC768
compatible standard would take the same amount of time to implement as
I do think that it should be taken into account that a 100GE standard
be carried over DWDM, and mechanisms should be implemented for
fast-failure-detection, mostly of the "there is a one-way fiber
break"-variant and the "the BER is high so the link is not good". This
perhaps something that should be discussed in another thread...
Mikael Abrahamsson email: firstname.lastname@example.org