By Stephen Hardy
With the move to packet-based networking, interest in Optical Transport Network has grown–as has the need for OTN test capabilities.
The evolution from circuit-switched TDM to packet-based transport requires the interplay of a variety of technologies and protocols. Therefore, packet-based networking needs an agent to hold the pieces together and ensure smooth operation, just as SONET/SDH does in legacy TDM transport.
For many networks, particularly at the core, Optical Transport Network (OTN) fills that role. OTN provides DWDM-enabled packet transport with similar management functions as SONET/SDH, while adding forward error correction (FEC) and more efficient accommodation of such traffic types as Ethernet, Fibre Channel, and even SONET/SDH itself.
However, technology advancements usually bring new challenges, particularly when it comes to test and measurement. For technicians at carriers implementing OTN, the trick lies in OTN's flexibility. It's not enough to test OTN itself, but also to inspect the potentially wide variety of payloads the OTN transport system may be carrying. Test equipment vendors say they have attempted to ease this problem. But meeting this challenge promises to become more difficult as new OTN capabilities reach the field.
Origins of OTN
The International Telecommunications Union (ITU) conceptualized OTN in 1996. However, a practical way to implement OTN concepts didn't appear until several years later with the development of the "digital wrapper" container strategy. The ITU used the digital wrapper idea as the basis for a series of OTN Recommendations, the most important of which are G.872 "Architecture of Optical Transport Networks" and G.709/Y.331 "Interfaces for the Optical Transport Network."
The OTN container system is something like a Russian doll. The client signal is mapped into an Optical Channel Payload Unit (OPU). The OPU is then wrapped within an Optical Channel Data Unit (ODU), to which Tandem Connection Monitoring overhead is attached. This ODU is then encapsulated within an Optical Channel Transport Unit (OTU) along with the appropriate amount of FEC. The OTU is mapped into an Optical Channel, which in turn is mapped into an Optical Multiplex Section, which then finds its way into an Optical Transport Section. (EXFO has a fine application note that explains the OTN container structure in more detail available on its website.)
Reflecting the need to test both OTN and payload parameters, Anritsu's MD1260A 40/100G Ethernet Analyzer pairs 40- and 100-Gigabit Ethernet test capabilities with OTU3 and OTU4 measurements. Source: Anritsu Corp.
For testing purposes, the sections of most interest are the ODU and OTU, both of which originally came in three flavors. Since OTU provides the interface most like the OC-x hierarchy of SONET, it is the most common term used to express transmission speeds. The three original OTU speeds were:
- OTU1, which carries payloads at 2.7 Gbps
- OTU2, which operates at 10.7 Gbps
- OTU3, for traffic at 43 Gbps
These rates mirror those of SONET/SDH. However, carrier needs and standards activities quickly uncovered inefficiencies at both ends of the speed continuum. For example, the completion of the IEEE 802.3ba specification created a requirement for a way to eventually accommodate 100-Gigabit Ethernet. This led to the creation of OTU4.
Meanwhile, a low-end speed of 2.7 Gbps mimicked the inefficiencies of SONET/SDH in mapping Gigabit Ethernet into the OTN hierarchy. The ITU-T recently solved this problem by creating ODU0, which enables a pair of Gigabit Ethernet signals to be mapped efficiently into a single OTU1 (a corresponding OTU0 was not created). The standards generators then went one better by creating ODUflex, which enables the creation of payload containers of custom sizes. ODUflex is expected to prove particularly useful in accommodating the various speeds of Fibre Channel.
OTN test issues
OTN first caught on in Europe, but is now increasingly deployed around the world to support the evolution to packet optical networks, particularly in the core. Its growing popularity naturally has caught the attention of test equipment vendors. The roster of test instrument suppliers with at least some OTN test capabilities for network installation and maintenance applications includes Anritsu, Digital Lightwave, EXFO, Ixia, JDSU, Sunrise Telecom, VeEX, and Yokogawa, among others.
Perhaps because it was created to bring similar management capabilities to packet-optimized infrastructures, OTN testing in the most general sense mirrors that of SONET/SDH.
Digital Lightwave recently added Fibre Channel and ODU0 to ODU3 multiplexing support to the OTN test features of its NIC platform. Source: Digital Lightwave
"For me, OTN test applications are very similar to SONET/SDH in the past," agrees Reza Vaez-Ghaemi, emerging technology manager, within the test and measurement business unit at JDSU. "What customers are interested in is checking the basic connectivity between two points. So basic bit error test is the first thing to start with. Also, [they want to] take a look at the forward error correction of their network–make sure that the network equipment can properly respond to correctable and uncorrectable FEC errors. The other test category is taking a look at section and path headers, the overhead bytes for section and path, and making sure there are no errors or alarms embedded in there. And then the other category that also happens in some applications is taking a look at justification control bytes, which provide information about the asynchronous or synchronous clients and how well the clock aligns."
The similarities between the goals of SONET/SDH and OTN, the fact that carriers were expected to transition from the former to the latter, and the common practice of handling Ethernet over SONET/SDH led most test equipment manufacturers initially to just add OTN capabilities to their 10- and 40-Gbps SONET/SDH test kits. However, as carriers have moved to cut out the SONET/SDH middleman, the need to add native Ethernet test capabilities became more pressing–as did the requirement for a basic understanding of Ethernet testing.
"People that have a good core network testing ability, that have been through SONET and SDH, can relate to the new ways of OTN, plus they need to be Ethernet friendly now," offers Bruno Giguère, an advisor in the CTO Office of EXFO. "There are issues there when it comes to testing end-to-end on the network. You cannot just do a loopback at the other end when you're starting to do Ethernet."
Therefore, most OTN test gear now combines OTN with SONET/SDH and Ethernet test capabilities–and, as ODUflex becomes more widely employed, perhaps Fibre Channel test capabilities will become widespread, as well. Such a combination of test procedures, alarms, and specifications could become confusing, particularly to test technicians accustomed to just SONET/SDH or just Ethernet. Therefore, test equipment developers have worked hard to make each testing aspect as familiar looking as possible.
"When we're in BER testing, everything seems to be industry standard or ad hoc standard–we all do similar things," explains Ildefonso Polo, director of product marketing, transport products at Sunrise Telecom, by way of example. "There are a few features we have that our competitors may have implemented differently or not implemented, and the other way around. So most of our focus has been on making it easier."
Ease of use will become even more important as carriers employ ODU0 and ODUflex. "With these OTN enhancements, we have a very complex and large number of OTN multiplexing stages, going from ODU0 into ODU1, ODU2, OTU3, and OTU4. But one can also skip certain stages; one can go from ODU0 to ODU2," says Vaez-Ghaemi. "I think as we move forward into this new OTN world–I call it 'next-gen OTN world'–there will be more variance and colors to OTN testing which will involve customers becoming comfortable with these different mapping procedures, for example."
It's clear that implementing OTN's increased flexibility will come at the price of increased test requirement complexity. Network installers and troubleshooters will have to hope that test instruments continue to evolve to ensure that the dynamic nature of OTN does not make network test an overwhelming task.