Operators are drawn to software-defined networks (SDNs) because they simplify network management. As operators migrate from traditional environments to SDN, they must be aware of potential service disruptions, lower client quality of service (QoS), and other issues. Testing, while always important, takes on an even greater role during this transitionary stage, particularly at the data-plane level where operator revenue is generated.
While the tests – QoS, traffic generation, etc. – haven't changed, the technologies certainly have, and operators will be required to test a variety of client signals over the data plane. Circuit-based traffic common in legacy networks is now being encapsulated into next-generation transport technologies such as Optical Transport Network (OTN), Multiprotocol Label Switching (MPLS), and Generalized MPLS (GMPLS).
OTN has increasingly become the preferred method for high-speed networks for a number of reasons. It provides operators with better visibility and control closer to the network edge. Network management becomes simplified, as OTN places user traffic at the core managed infrastructure earlier. OTN can also enable operators to better monitor and service large customers.
OTN uses Optical Data Unit (ODU) as digital wrapper to many technologies, such as Ethernet, SONET, and Fibre Channel (Figure 1). In essence, ODU is a transport container that carries client signals from network ingress to egress. It provides a payload area for client data along with overhead for performance monitoring and fault management. ODUflex (Figure 2) is a new feature that supports the flexible allocation of client-signal bandwidth to make the best use of OTN capacity.
The use of ODU reduces the number of technologies that need to be measured from many to one. The result is that test platforms must support ODU wrappers and be easily updated to keep pace with the constantly changing standards so they can generate any type of data to accurately measure the data plane.
Appeal of SDN
OTN is only one change in the ever-evolving network. In the traditional approach to networking, most network functionality is implemented in a dedicated appliance, such as a switch, router, or application delivery controller. Within the respective appliance, most of the functionality is implemented in specific hardware such as an application-specific integrated circuit (ASIC). SDNs are viewed as a superior approach to this hardware-centric networking approach.
As described by the Open Networking Foundation (ONF), the SDN architecture (Figure 3) is dynamic, manageable, cost-effective, and adaptable. These attributes make an SDN ideal for today's high-bandwidth networks. This architecture decouples the network control and forwarding functions, enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services.
Proponents of SDN point to five key benefits:
- Programmability: Control of the network can be programmed directly because it is decoupled from forwarding functions.
- Responsive: Administrators can dynamically adjust network-wide traffic flow to meet changing needs.
- Centrally managed: Software-based SDN controllers centralize network intelligence to create a universal network appearance to applications and policy engines.
- Dynamic Configuration: Network managers can configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs. Because the programs are open standards-based they can write themselves.
- Vendor-agnostic: When implemented through open standards, network design and operation are simplified because instructions are provided by SDN controllers rather than multiple, vendor-specific devices and protocols.
Network Testing
Many believe incorporating test software controlled by SDN into the network is another benefit and the best approach to maintain network performance. While this may be the most logical solution in a few years when standards and SDN technology have fully evolved, independent transport testers not integrated into SDN remain the best approach for today.
The reason test software integrated into the SDN is not currently optimal is that there is no reference when tests are conducted. For example, most networks use switches from multiple manufacturers. With SDN controlling the tests, there is no way to determine which results correlate to each switch. The incestuous nature of having the network element become the network tester by installing virtualized test capabilities creates additional points of failure. In this case, both the network element and optical modules raise questions when test results between interoperable devices yield inconclusive results.
A separate test instrument, such as the one shown in Figure 4, solves this problem because it has its own "golden" reference, so determining the results for each network element is easier and any issues can be located faster. For example, duplicating the same test environment and parameters taken from one network element can be achieved on different manufacturers' devices, regardless of control plane and management environment. In the event that one manufacturers' device yields opposing results, the independent test reference can capture, troubleshoot, and report the results that can be duplicated without removing the network element nor virtual test instance.
Instrument flexibility is also critical, enabling operators to save time and money. Test sets need to support legacy and emerging transport technologies, as well as rates from DS1 to 100 Gbps, so they can conduct measurements anywhere in the network, including inside the metro, access, and core.
Virtualized tools for monitoring network performance, reliability, and dynamic traffic management that communicate through the control plane are significant reasons to migrate to SDN architecture. However, the need for independent testing and troubleshooting from reference is required in the data plane.
Not any separate test approach can be used to monitor networks during this migration to SDN networks. These environments require test instruments that support forward error correction (FEC) performance tests using Poisson distribution random errors. Adopted by ITU-T O.182, these tests are important because the FEC section is one of the most vital areas of the network frame. It allows for greater decibel range between equipment by correcting errors within the frame at the receiver end.
Reproducible, accurate FEC error correction tests are performed by generating truly random signal errors that can stress OTN FEC. This capability enables a much lower BERT measurement to ensure testing to the limit or beyond the switching equipment's ability. This is necessary to accurately measure the actual performance and threshold of an OTN.
Network Monitoring
To maintain network performance and efficiently troubleshoot issues, test platforms need to support section monitoring (SM) and path monitoring (PM) of an OTN, each of which has different alarms and error detections. These maintenance signals, as they are called, send feedback on issues that occur at the network far end and offer an indication of the layer in which they occurred. Among the indications are:
- Backward Defect Indication (BDI): indicates signal fail in the upstream
- Backward Error Indication (BEI): indicates the number of errors detected in the upstream
- Incoming Alignment Error (IAE): detects error by BIP-8 code in the OTU layer
- Backward Incoming Alignment Error (BIAE): counts the IAE errors in the upstream in the out.
Network engineers and technicians use these OTN maintenance signals to quickly and correctly locate an issue, so they know the position in the network where testing should begin. Use of these signals also enables issues to be prioritized. For example, Layer SM will have a higher priority because it is likely a core issue, whereas a PM problem is most likely a single customer issue.
Taking this Tandem Connection Monitoring (TCM) approach makes it easy to identify the customer or segment level affected. With this information, operators can ensure that issues affecting high-priority customers are corrected first. Additionally, understanding the various TCM levels that are being analyzed or injecting errors identifies the section where there is a problem.
Conclusion
SDNs are evolving to enable networks to effectively and efficiently meet ever-growing bandwidth needs. The transition from traditional network environments to SDN is a complex process that poses many challenges to operators who must maintain high QoS and customer retention. The most effective way to ensure that this move will be done seamlessly is to use separate test instruments with a "golden" reference rather than integrating test software into the SDN.
Daniel Gonzalez is digital/optical business development manager for Anritsu Co. He has more than 16 years in application planning, development, digital and optical transport testing, training, and execution with knowledge in technologies including TDM, SONET, OTN, ATM, Carrier Ethernet, and physical layer signal integrity. He also is a member of IEEE.