40G Ethernet over DWDM : Part1

Even though 40G Ethernet is classed as a technology that will be found in the LAN or SAN, at some point in time it will be necessary to transport 40G Ethernet over DWDM links in order to connect remote sites. Typically for links of more than 80km this will mean interfacing to DWDM systems built around the ITU’s G709 standard for OTN, which specifies a digital wrapper with FEC. I had planned to write this as one blog but due to the torrid history of aligning the 10Gbps Ethernet data rates with the associated 10Gbps Telecom data rates I decided to split it into two parts, the first covering how 40G Ethernet is mapped and the second on the challenges faced by early adopters.

Looking at how 10G Ethernet/Fiber Channel is transported over a 10.7Gbps OTU2 DWDM link the first problem we hit is that the OTU2 was initially specified to carry SONET/SDH traffic (9.96Gbps) and does not have the payload capacity to transport 10G Ethernet (10.3Gbps) and 10G FiberChannel (10.5Gbps). The Telcom folks had proposed a 10GBase-W which was basically a rate shaped 10G Ethernet mapped into a OC192 SONET signal, however the response from the data community to rate shaping could be politely summed up as “you want us to do what…..!”

So regardless of the 10GBase-W, the initial market solution was to “overclock” the OTU2 frame (OTU2e) so that it had the extra capacity (something that can be done for OTN but not for SONET).This however has spawned four different overclocked datarates, two for 10G Ethernet and two for 10G Fiberchannel depending on how the data is mapped.

Although the use of OTU2e overclocking is very wide spread it is acknowledged now as an undesirable solution for the WAN as it makes multiplexing these signals into a higher rate 40G signal very difficult (needs an overclocked OTU3) and pretty much prevents any reasonable form of OTN crossconnect.

For 10G Ethernet, a method has been devised by AMCC to map the data into a standard rate OTU2, this is done by making the OTU2 payload slightly bigger (using some unused overhead bytes) and deleting Idle 64B/66B characters in the IPG whilst still being able to transport certain ordered set messages likes local/remote defect. This proposal, which is an extension of the ITU G.7041 GFP based mapping, is now part of the ITU’s G.Sup43 and is pretty much accepted as the industries preferred solution (though not optimal). However the solution does not work for the higher datarate of 10.5Gbps Fiberchannel.

Despite the problems lessons were learned, and in the definition of the ITU’s 100G OTN standard a landmark was reached where, rather than a telecom signal like SONET being assumed payload, the proposed OTU4 being specified by ITU is based on the 100G Ethernet data rate (103.125Gbps incl. PCS)  – so no more need to overclock – hopefully.

However what about 40G Ethernet (41.25Gbps line rate), since 43Gbps OTU3 is optimized for the SONET 39.8Gbps OC-768, do we need to overclock the OTU3(e.g 45Gbps)?  Well the good news is that it’s not necessary and that is thanks again to the work done in the IEEE (kudos to Steve Trowbridge at Alcatel-Lucent) where a method of transcoding the 40G Ethernet 64B/66B signal into a 1024B/1027B signal (original proposal was for 512B/513B) has been devised which “just” fits inside the payload of the OTU3 – hurray!

The proposed transcoding method does not support full IPG transparency but as long as vendors stick to the 40G PCS coding rules it will work. After all that said it is still possible to map a 40G Ethernet into an overclocked OTU3 using the same method as used in 10G overclocking – but lets hope not.

For the moment the 40G Ethernet transcoding is still just a proposal with the IEEE passing to initial work done over to the ITU’s standards sub committee Study Group 15 . The most likely next step is that it will be included in the next update of G.sup43.

So, even though nearly all of the technical details have been sorted out it will be a while before native 40G Ethernet ports appear on DWDM system which will cause extra challenges to early adopters. Part 2 of the blog discusses these challenges and some possible solutions.

40G Ethernet Resource Center
http://www.40gethernet.com
http://twitter.com/40GEthernet

——-
In both part 1 & 2 of this blog we’ve assumed some (if not too much) knowledge of the G709 standards. Rather than try to go into detail on this subject we think it best to refer people to the excellent OTN Tutorial by Tim Walker which is available “free” from the ITU website.
http://www.itu.int/ITU-T/studygroups/com15/otn/OTNtutorial.pdf or just search for “ITU OTN Tutorial”.

4 Responses to “40G Ethernet over DWDM : Part1”

  1. Steve Trowbridge Says:

    I appreciate the acknowledgement for the 1024B/1027B coding method which allows 40G Ethernet to map into OPU3 without overclocking, but the details which follow aren’t quite correct. You wrote:
    “The proposed transcoding method does not support full IPG transparency but as long as vendors stick to the 40G PCS coding rules it will work. After all that said it is still possible to map a 40G Ethernet into an overclocked OTU3 using the same method as used in 10G overclocking – but lets hope not.

    For the moment the 40G Ethernet transcoding is still just a proposal with the IEEE passing to initial work done over to the ITU’s standards sub committee Study Group 15 . The most likely next step is that it will be included in the next update of G.sup43.”

    In fact, the transcoding DOES provide full IPG transparency, carrying every 66B PCS codeword intact assuming error free transmission. The only aspects which are not carried bit-for-bit are:
    – The scrambler seed may differ between the OTN ingress and egress.
    – Bit errors between the Ethernet Tx and the OTN ingress which affect the sync header or control block type, resulting in a non-transcodable sequence of 66 bits, are replaced by an error control block (0x1e followed by eight /E/ control characters). This is exactly what would happen in the stack at the Ethernet Rx if the same bit errors arrived at the Rx PCS, just done a bit earlier when carried over OTN.

    In addition, this will not be documented in G.sup43, but in G.709 as a fully standardized mapping.

    IEEE has done their part as well to ensure the robustness of this mapping by including strong prohibitions against deviations (i.e., proprietary extensions) in areas of the frame format that could affect the transcoding.

  2. 40gethernet Says:

    Steve, many thanks for taking the time to clarify the misunderstanding we had about the 1024/1027 coding method and about the standards path – especially as it was good news in that full IPG transparency is supported! Best regards,
    40GEthernet Resource Center

  3. 40gethernet Says:

    JDSU have produced a great new Poster for OTN showing the latest specification updates including ODU0 support (for mapping GigE’s) and OTU3e1 & OTU3e2 options. Get it at …

    Click to access otn-fec_po_opt_tm_ae.pdf

  4. FPGA Gurus » Blog Archive » Into the OTN data stream at OFC/NFOEC Says:

    […] of Sonet in the public network make similar plans, you know that many carriers want to retain the OTU2 signals (10G) from the current Optical Transport Network, and multiplex transport signals on top to achieve […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: