Given that many carriers have begun mass
deployment of their 100G networks, a couple
of questions arise: first, is 100 Gigabit
Ethernet (GigE) testing different than 10
GigE testing? Second, what needs to be
tested during the deployment of a new 100
GigE network? In this article, we will address
the key tests that need to be performed at
100 GigE during commissioning, turn-up, and
Figure 1 illustrates some of the network complexity in today’s high-speed networks, with rates from 10M all the way up to 100G. Multiple tasks must be performed to qualify the network, and to this end we will be covering the key testing points from the interface all the way to services testing.
CFP quality is improving, and as a result we are now seeing fewer and fewer issues due to incompatibility or electrical crosstalk. However, a quick validation test is still required before each deployment to analyze the main status of the CFP and ensure that there are no errors. The main tests involve analyzing the laser power to ensure that the laser’s transmitted and received optical power is within the specific range; as part of the same validation process, the received per-lane frequency will need to be tested.
In some cases, the CFP is considered the weakest link in the network; in such cases, it will be critical to ensure that the CFP is completely functional before conducting any CFP deployment.
Unlike the single-wavelength transceivers that were used for legacy 2.5G and 10G, each CFP parallel optical channel must be monitored for transmitted and received power levels. Even if the overall power across all channels (4 or 10) is within the acceptable range, this might be the result of averaging a channel with very low power, which could in turn impact the transmission and performance on the optical channel and a high-power channel, which could damage the optical receiver at the other end. The add-on of a simple attenuator on the optical link can help reduce the RX power.
In some cases, a per-lane view may be required to identify any suspicious lanes that could eventually cause bit errors. For instance, lane 9 as shown in Figure 3, is slightly out of range. The tests are also applicable to the upcoming CFP2 interface, which is backward-compatible with CFP technology. There is no gearbox in the CFP2—it was moved to the host, reducing the physical size and power consumption. However, this also introduces some new challenges, and at the same time new issues. EXFO’s CFP2 adapter, which can be inserted into a CFP interface, allows field technicians to validate CFP2 transceivers before deployment, thus minimizing risk. Given that more than 60% of deployment issues are related to CFP or CFP2, it is now critical to test each CFP. EXFO’s CFP health check supports both interfaces with a basic and advanced mode for quick pass/fail validation.
ETHERNET BER TEST (ETHERBERT)Once the physical-layer test complete, the next step is to ensure that an Ethernet packet can be transmitted in an error-free manner over the entire network. This could be considered a basic test, but is helpful in validating that all of the traffic is able to transition to the far end and loopback without any errors. Failing this would result in bit errors. The same test can also provide complete Ethernet statistics and protection switching time data from both paths (working and protection). This data helps qualify Ethernet switches or routers that identify end-to-end connectivity issues from the MAC layer and up.
TESTING MULTIPLE TYPES OF SERVICESThe BER test is primarily based on pseudo-random traffic, whereas in reality, live traffic tends to be based more on different types of services, thereby driving the need for more multiservice tests in which the user can simulate multiple streams with predefined data, voice and video traffic profiles, or user-configurable profiles. These tests make it possible to simulate all of the types of services that will be running on the network while simultaneously qualifying all the key service-level agreement (SLA) parameters for each of these services. Moreover, these tests validate the quality of service (QoS) mechanisms provisioned in the network for prioritization of the different service types, which results in better troubleshooting, more accurate validation and much faster deployment. This capability includes the generation, shaping and monitoring of Ethernet and IP traffic with throughput, frame loss, sequencing, packet jitter, latency, frame size, traffic type and flow control.
NETWORK PERFORMANCE VALIDATION:
To ensure that a 100 Gigabit Ethernet network is capable of supporting a variety of services (such as VoIP and video), an RFC 2544 test can be executed, whereby the 100G pipe will be tested and confirmed
for 100% throughput and low-latency frame loss by testing at different frame sizes.
RFC 2544 AND Y.1564 TEST
The predefined frame sizes will simulate various traffic conditions, because small frame sizes increase the number of frames transmitted, thereby stressing the network device. Because carriers are currently faced with stressful constraints in terms of time to deployment, the industry can now initiate a shift toward ITU-T Y.1564 (EtherSAM) for turn-up testing. This test offers simultaneous tests (as opposed to RFC 2544’s sequential tests), and validates multiple services at the same time, thereby qualifying the services as defined in the SLA. ITU-T Y.1564 is a crucial test that must be executed, and is based on two phases. The first phase, which is called the network configuration test, consists of validating the QoS mechanisms and limits based on the key performance indicator (KPI) threshold: the committed information rate (CIR), the excess information rate and the discard traffic conditions.
Figure 5 above shows the KPIs that will be measured during the network configuration test.
The second phase, called the service performance test (see Figure 6), runs all services simultaneously and validates each service individually based on the specified CIR and SLA. This means that each selected service will be run simultaneously in order to measure the throughput, jitter and latency of each service. A pass/fail result will then be generated based on the service-specific thresholds provided.
As part of the process of minimizing test times and reducing the amount of truck rolls, a dual test set (DTS) configuration can measure the performance of the system under test (SUT) by measuring both transmission directions. Additionally, this test (which is also known as a head-to-toe test) offers a lot of value when the networks feature multiple routers.
In a DTS configuration, the user can have one test set controlling the other by simply dedicating one as the “local” test set and the other as the “remote” test set. This makes it easy to determine in which direction the traffic is flowing. It also provides asymmetric results that can easily identify network limitations. For example, Figure 7 to the right shows a local-to-remote direction in red, and a remote-to-local direction in green. This bidirectional flow of traffic enables the test sets to transmit and receive at the same time.