100G Ethernet: The Speed of Now
Best-Practice Test Methodologies for 100GbE and IPv6
There are now 7 billion potential subscribers in the world, tracking toward 8 billion, possibly as soon as the next decade.
This unprecedented scalability of subscribers and bandwidth, and the emergence of the mobile internet, demand a new level of performance from test platforms to make sure the always-on, always-connected generation stays connected.
"Not so obvious is how to assure that
reliable deployments occur on schedule."
This white paper looks at the challenges of testing IPv6 and 100G Ethernet:
- What changes with the new technology, and what stays the same
- Best-practices test methodologies for both IPv6 and 100G Ethernet
- Selecting a test platform with the power to support these methodologies
100G ETHERNET: THE SPEED OF NOW
Validating IPv4/v6 Performance on 100G Ethernet
December 2011
Rev. A 12/11
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
CONTENTS
Executive Overview 1
Market Drivers: Truths and Consequences . 1
Three Truths . 1
Three Consequences . 3
A Quick Technology Tour 3
IPv6 . 4
100G Ethernet 5
The More Things Change, the More They Stay the Same . 7
Test Realism: Emulation versus Simulation 7
Real User Behavior . 7
Real Converged Traffic . 8
Real Network Conditions . 8
Beyond QoS: Testing and Delivering QoE . 8
Accelerated Testing: Product Lifecycles at the Speed of Now . 9
Testing IPv6 at the Speed of Now 9
Standards-Based Benchmarks . 9
Validate Throughput, Packet Loss, Sequencing and Latency 10
Validate Performance 11
Assess the Impact of the IPv6 FIB Size on Router Performance 12
SPIRENT WHITE PAPER • i
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
CONTENTS
Testing 100G Ethernet at the Speed of Now . 13
Validate Data Transmissions in Loopback Mode . 13
Validate Performance of the Optics 13
Validate Short and Long Term Performance of the PMA Layer 13
Validate PCS Marker Alignment 13
Assess Maximum Lane Skew Limits . 14
Standards-Based Benchmarks . 14
Testing 100G Ethernet IPv6 at the Speed of Now . 14
Real Time IPv4/v6 Routing at 100G Ethernet with Real-World Scenarios . 14
Layer 2-7 True Multi-Protocol Testing at 100G Ethernet 14
High Port-Density Testing at 100G Ethernet . 14
Testing the Tester . 15
Conclusion: Testing at the Speed of Now . 15
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
1 • SPIRENT WHITE PAPER
EXECUTIVE OVERVIEW
Is it true that you can never be too rich, too thin, or have too much bandwidth?
The ever-increasing demand for content seems to validate that claim as far as
bandwidth goes. There are now 7 billion potential subscribers in the world,
tracking toward 8 billion, possibly as soon as the next decade.
The implications for address space (IPv6) and bandwidth (100G Ethernet)
are obvious. Not so obvious is how to assure that reliable and efficient
implementations and deployments of these technologies occur on or ahead
of schedule. This unprecedented scalability of subscribers and bandwidth,
and the emergence of the mobile internet, demand an unprecedented level of
performance from the test platforms that make sure the always-on, always-
connected generation stays connected.
The rules for delivering services are changing, as can be seen in Carrier
advertising. The “can you hear me now” guy has been supplanted by data
throughput claims and measures of video quality.
This white paper looks at the challenges of testing IPv6 and 100G Ethernet,
what changes with the new technology and what stays the same. It includes an
overview of best-practices test methodologies for both IPv6 and 100G Ethernet
and the implications for selecting a test platform with the power to support
those methodologies.
MARKET DRIVERS: TRUTHS AND CONSEQUENCES
Early in the twentieth century, Wallis Simpson, the Duchess of Windsor, declared
that a woman can never be too rich or too thin. While it may be debatable that
more is always better, there seems to be a corollary for the twenty-first century.
Three Truths
As the always-on, always-connected lifestyle sweeps across the globe, three
truths of networking have emerged.
There will always be:
1. More subscribers
2. More demand for content
3. More addressable devices per person
More Subscribers
The world population officially hit 7 billion people in 2011 and according to UN
projections will hit 8 billion in the next decade.
http://en.wikipedia.org/wiki/File:World-Population-1800-2100.png
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
SPIRENT WHITE PAPER • 2
According to Miniwatts Marketing Group, in March 2011 there were over two billion internet
users, representing 30 percent penetration worldwide. While North America approaches
saturation at 78 percent, other areas, such as Asia (23 percent) and Africa (11 percent), are
huge growth markets.
http://www.internetworldstats.com/stats.htm
KPCB reports that as of 3Q 2010 there were 726 million 3G mobile subscribers, representing 14
percent penetration worldwide with 35 percent year-on-year growth.
http://www.slideshare.net/kleinerperkins/kpcb-top-10-mobile-trends-feb-2011
It’s clear that even with aggressive market growth rates, the population growth rate is equally
aggressive, with every person a potential subscriber
More Demand for Content
The mobile internet is upon us, along with interactive mobile applications, hi-def video
conferencing, high-speed file transfer, mobile clouds, and a host of others.
The market response to the seemingly endless demand for content results in a self-perpetuating
cycle. As the technology evolves to provide the new services, these services spur more demand
for content.
Real-time entertainment has moved to the forefront of online content. The Cisco Visual
Networking Index Global Data Traffic Forecast projects mobile data traffic to grow to 26 times
the present level by 2015.
http://www.slideshare.net/kleinerperkins/kpcb-top-10-mobile-trends-feb-2011
According to Sandvine’s Global Internet Phenomena Report: Fall 2011, Netflix alone accounts
for 30 percent of the peak downstream traffic and 22 percent of aggregate daily traffic in North
America. Video continues to enjoy significant growth with a CAGR of over 50 percent.
http://www.sandvine.com/news/global_broadband_trends.asp
High-profile events that have traditionally been the province of broadcast television, such as
President Obama’s inauguration, Michael Jackson’s memorial service, and the royal wedding
of Prince William and Kate Middleton, now have a global reach through live streaming. Live
streaming of key finalist events from the 2012 London Olympics is expected to set records for
network traffic.
In general, for decades the demand for content has increased and is now concentrating on high-
bandwidth, latency-sensitive traffic.
More Addressable Devices per Person
Morgan Stanley projects that by 2012 the number of smart phones will exceed the total number
of PCs, both desktops and laptops.
http://www.slideshare.net/CMSummit/ms-internet-trends060710final
Back in 2004, the UK IPv6 Task Force made some projections. They projected, quite accurately,
that there would be over 2 billion internet users by 2010. They also projected that the number
of addressable devices on the internet would grow from one per person to over ten per person
by 2015. [UK IPv6 Task Force, 2004, UK Internet Protocol User and ISP Surveys]
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
They may be right. IP-addressable devices have expanded beyond traditional computing
and network devices to include smartphones, tablets, mobile entertainment centers, vehicle
systems, surveillance systems, machine-to-machine.
Consider one household of two people on my block. They have fifteen IP addressable devices,
half of which are mobile devices. (3 laptops, 1 desktop, 3 smartphones with Wi-Fi, 2 iPads,
1 network-aware Blu-ray player, 1 DVR, 1 network printer, and 1 file server.) With DVRs and
gaming systems supplementing computers and smartphones, the single-IP-device household is
becoming more rare.
Three Consequences
The inevitability of growth in number of subscribers, number of devices per subscriber, and
demand for content has two implications for those building networks.
Networks will continue to require:
1. More bandwidth.
2. More addresses.
3. Better Quality of Experience (QoE)
Ethernet dealt with bandwidth concerns by going from 1G Ethernet to 10G Ethernet to
40G Ethernet and now 100G Ethernet in a decade. But the increase in speed comes with an
increase in complexity. The silicon didn’t get a hundred times faster. Achieving 100G Ethernet
throughput requires multiple chips, multiple cores and multiple lambdas.
The depletion of IPv4 addresses in February 2011 highlighted the urgency of IPv6 deployment.
IPv6 resolved the address issue.
And because of increasing expectations of QoE from the expanding subscriber base, networks
must deliver high-bandwidth, low-latency, real-time entertainment with unprecedented levels
of quality.
A QUICK TECHNOLOGY TOUR
The advent of the mobile internet is a revolution in the market, demanding new devices and
new services in accelerated time frames. But this revolution is built on the evolution of existing
technologies – IP and Ethernet.
While it is true that the future is bigger (IPv6) and faster (100G Ethernet), the implications for
network applications go beyond questions of address length and bit rate.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
IPv6
Comparisons between the address space for IPv4 and IPv6 quickly turn into bandying about
astronomical numbers. With 32 bits versus 128 bits, the numbers are staggering. Consider a
few facts:
• 2011 world population = 7,000,000,000
• Number of IPv4 addresses per person = 0.61
• Number of IPv6 address per person = 48,611,766,702,991,200,000,000,000,000
(4.86E+28)
The address space of IPv6 is large enough to give each person on the planet a personal
address space larger than the entire IPv4 address space. How much larger? Over
11,000,000,000,000,000,000 (1.13E+19) times larger.
IPv6 poses challenges to existing network solutions.
Switch Fabric and Queuing
The need to attach more devices to the network drove the evolution of addressing. IPv6 allows
us to attach more devices to the network, but this increase in the number of devices stresses
both physical and virtual switches. With an address length of 128 bits as opposed to 32 bits,
IPv6 requires rewriting and integrating into hardware decades-old algorithms that are hardware-
optimized for IPv4.
In addition to length, IPv6 address formats differ from IPv4 formats. Legacy algorithms that
optimize performance based on a fixed length format must be supplemented with more flexible
routines. IPv6 solutions must be evaluated through capacity testing to reveal how the switch
fabric will scale with IPv6 traffic and with rate testing to determine how fast the system can add
addresses to the Forwarding Information Base
Frame Size and Frame Rate
Frame sizes for IPv6 are much more likely to reach 16K than in IPv4. This can affect switch
performance, especially in dual-stack implementations, which must handle packets of both
versions with the wide range of frame sizes found on the internet and the sudden changes in
frame rate that happen during microbursts, the sudden and intense increase of traffic for a
short duration.
Microbursts increase both packet density and address density. One example is time-of-day
oriented events such as the sudden increase in users and traffic on smartphones at the close of
business as subscribers head to their cars for the commute home.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
Peaceful Coexistence
The transition from pure IPv4 networks to pure IPv6 networks will be a long journey. During
the interim, there are technologies in place to allow both to coexist on the same network.
These solutions are workarounds that require translation or tunneling, which introduce extra
processing steps in the path with the latency and the increased points of failure that go along
with it. For some end users this delay is just an inconvenience. For others, such as financial
services, delay is potentially disastrous for the top and bottom lines. For service providers, low
latency is a competitive differentiator.
IPv6 Deployment Challenges
IPv6 is substantially different from IPv4. CPUs, ASICs, queues, buffers, RIBs, microcode, drivers,
and OS Code are at high risk for:
• Unexpected data plane performance / forwarding optimization
• Inefficient queuing algorithms and unoptimized queue hash management
• Decreased stability and reliability and increased security breaches
• Loss of quality of service (QoS), quality of experience (QoE), and the ability to sell
service level agreements (SLAs)
• Poor performance, compliance, and scale of control plane protocols
100G Ethernet
In 100G Ethernet, a different number of lanes is used at several levels in an interface, but there
is no requirement in the specification for a static mapping of virtual lanes to physical lanes.
As a result, two issues can arise, swapping of lanes and skew between lanes based on different
flight times from one set of optics to the other, introduced by imperfections in the electrical or
optical interfaces or media.
It’s More Than Just Moving Bits Faster
While it’s true that 100G Ethernet is still Ethernet, just faster, there’s a lot packed into that
phrase “just faster.” In some ways it’s more of the same, in others it changes everything.
At this early stage in the life cycle off-the-shelf components are not available, so vendors must
create custom implementations with multiple chips, each containing multiple cores. But the
market demands shorter development cycles. For 10G Ethernet, the evolution from achieving
10G Ethernet transport to 10G Ethernet multiservice routing took seven years. For 100G
Ethernet, the expectation is 100G Ethernet multiservice routing in two years.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
At the upper layers, that means each component in a device or step in a process must
accomplish the same thing it currently does in one tenth of the time. Consider a router, for
example, which strips lower-layer information from an incoming packet, queues it, performs a
route lookup, and sends it to the proper outbound queue to be packetized, while performing
filtering, SLA monitoring and policing, and class of service / quality of service (CoS/QoS)
prioritization. In addition, a router also exchanges per-VPN MPLS label information, builds
multicast routing trees, performs routing table updates for multiple protocols, maintains
statistics and logs (performance, alarm, event and failure) and performs firewall and security
functions, such as key exchanges, attack detection and prevention.
A router with 100G Ethernet interfaces must do all this at ten times 10G Ethernet speeds
without dropping packets, introducing excessive jitter, compromising VPN boundaries, or
reordering packets, which is especially disruptive for storage and real-time entertainment
Clock Precision
Imprecise clocking between systems at 100G Ethernet can increase latency and packet loss.
At 10G Ethernet, especially at high densities, the specification allows for a little variance for
clocks. As you aggregate traffic into 10G Ethernet ports, small differences between clocks can
cause high latency and packet loss. At 100G Ethernet, the tolerances are even smaller.
100G Ethernet Deployment Challenges
Key test metrics for IEEE 802.3ba 100G Ethernet are:
• Layer 1 skew performance: Lane skew was a contributor in older Ethernet roll out
issues, being able to add skew and to measure effects are a critical part of the physical
layer setup.
• Layer 1 lane swapping: Measuring the ability of the DUT to manage the virtual to
physical translation is critical because lane swapping errors can lead to interface link-
down problems that are difficult to debug in deployed systems.
• Layer 1 per-lane unique BERT (PRBS): The ability to test the physical pathways using
unique PRBS BERT patterns reveals physical lane stability and crosstalk issues.
• Latency and jitter: Testing 100G Ethernet to 100G Ethernet and 100G Ethernet to
multiple 10G Ethernet ports is a critical test of backwards compatibility. The ability to
measure jitter to 2.5 ns in the core is essential because one 64-byte frame, with inter-
frame gap, is transmitted every 6.72 ns.
• RFC2544 100G Ethernet throughput: Measuring the forwarding rate at 100G Ethernet is
critical to prove forwarding performance.
• Correct sequencing detection: Validating the buffering storage-and-reassembly
algorithm while under load and across different Ethernet technologies is essential.
Reported metrics include lost, duplicate, late, and reordered packets. Sequencing
is even more important for 100G Ethernet because it is not limited to reassembling
packets at the network layer. At the physical layer bitstreams are broken up, transmitted
across separate optical paths, and reassembled.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
The More Things Change, the More They Stay the Same
At the lower levels of the technology there are significant differences between IPv4 and IPv6,
and between 10G Ethernet and 100G Ethernet. Design and implementation decisions must
reflect these differences and employ a test methodology that stresses the typical and corner
cases unique to each technology.
However, when it comes to user quality of experience, the requirements do not change.
Application-level concerns center on performance, availability, scalability and security (PASS),
the classic measures that differentiate one solution from another. PASS testing is still required,
but with more speed and more scalability.
TEST REALISM: EMULATION VERSUS SIMULATION
The ability to accurately evaluate a solution against the PASS parameters is based on the
simple but essential element of test realism. Realistic testing means re-creating the environment
that the application lives in, from the provider to the customer, in all its dynamic and daunting
complexity.
Test realism comes down to the difference between simulation and emulation. Simulation
attempts to predict the behavior of a system by creating an approximate mathematical model
based on a set of assumptions. Emulation replaces a part of the system and performs in exactly
the same way as the element it replaces. It adjusts dynamically to a changing environment and
responds to actual stimuli from the system it interacts with.
Simulation is appropriate for analyzing a system to infer predictions about how it might behave,
but emulation is required to see what will actually happen in a given situation, to know how a
solution will respond under real-world conditions.
There are three essential elements of test realism.
Real user behavior
Users are as unique as their fingerprints. They vary significantly in how long and in what
manner they navigate through an application and how they respond to sluggish performance,
picture and voice dropouts, dropped calls, and other problems. They violate usage and security
policies in different ways. They find unique ways to break a system.
Realistic testing means the flexibility and sophistication to emulate a wide range of user
behavior, both benign and malicious.
Hitting a device with a mix of traffic types (say, mixing HTTP requests/responses with IPTV
channel changes and P2P file sharing or gaming traffic) isn’t emulating user behavior. It’s
a simulation, just hitting the system with a mix of traffic, static packets that don’t respond
statefully to the incoming messages. Emulating real user behavior means supporting stateful
traffic that emulates how a user operates, including think time, click-through, abandon, channel
surfing, etc. It means good users and malicious users simultaneously attempting to achieve
their good and bad goals.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
User-centric traffic reveals the performance of the device in a real environment. Queues,
buffering, and other mechanisms behave differently depending on the order and the nature of
the transactions. An arbitrary (and artificial) static mix of messages, or even a dynamic mix of
messages that doesn’t account for the stateful nature of user connections, will not stress the
system the way real users do. As a result, failure points can remain undetected until the real
users start using it. Which is exactly the wrong time for that to happen.
Real converged traffic
Single-purpose networks are relics of the past. The consolidation of networks onto Carrier
Ethernet and MPLS enables mobile and fixed-line voice and data, residential video, and MPLS-
based VPNs to share the same network. The different types of traffic carried on the converged
network have different characteristics and requirements, but they all travel on the same path,
dependent on CoS and differentiated traffic rules to keep everyone happy.
Realistic testing means the power to create line-rate, fully-emulated, stateful traffic across
hundreds of ports.
Real converged traffic not only means a realistic mix of traffic types, but also realistic traffic
encapsulation. For example, if the deployed system tunnels user PPP sessions over MPLS,
then testing PPP setup-teardown rate and throughput performance without MPLS is not real
converged traffic. It’s a dangerous shortcut that will mask problems users will discover after
deployment. Real converged traffic means emulating the actual deployed topology, regardless
of how complex or simple, including all encapsulations.
Real network conditions
The network creates time-varying conditions that are linked to a complex set of conditions,
influenced by routing table updates, signaling protocols, queuing algorithms, buffering, traffic
management and policing policies, malicious attacks, EMI and other environmental factors.
Realistic testing means the power and complexity to create the dynamic, time-varying
conditions found on deployed, production networks.
Real network conditions can’t be emulated through static rates of delay/loss or distribution-
based mathematical models of impairment. Real networks don’t introduce impairments at
fixed rates or follow neat curves. They behave in seemingly non-deterministic ways due to the
number of factors affecting them. Testing under real network conditions means emulating this
complexity to discover issues before the real network finds them.
Beyond QoS: Testing and Delivering QoE
Realistic testing goes beyond simple, deterministic QoS test methodologies. While real-time
services are built on a foundation of a QoS-enabled network, the real deliverable is not a set of
priority rules and metrics. It’s a high quality of experience for the subscriber.
Which is why test realism is an essential component while building and maintaining the
infrastructure of the mobile internet. Deterministic legacy test methodologies deliver valuable
information about individual components or functions, but good QoS numbers alone are no
guarantee of QoE. A test methodology built on test realism goes beyond validation of discrete
components and functions and recreates the complete environment in which new services
must perform.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
Accelerated Testing: Product Lifecycles at the Speed of Now
Another aspect of the faster, bigger world of the mobile internet is the acceleration of the
technology life cycle. Earlier iterations of Ethernet may have taken a decade to transition
through the life cycle – introduction, growth, maturity, and decline – but successive leaps in
bandwidth have cycled through increasingly shorter timeframes.
TESTING IPV6 AT THE SPEED OF NOW
The testing techniques for testing IPv4, developed a decade ago now only provide marginal
value at the acceptance test phase. To properly and thoroughly test IPv6, we must augment,
improve and establish new testing techniques.
Standards-Based Benchmarks
To provide a standard way of measuring and evaluating a solution, the industry has created a
series of benchmarks. These benchmarks establish a uniform procedure for the generation of
traffic to and from the system under test with a normalized procedure of analysis and reporting.
The goal of the benchmark is to generate metrics in a reproducible and unbiased fashion for
comparability.
IP Throughput and Latency for IPv4 and IPv6
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
RFC 4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
ITU-T Y.1564: Ethernet service activation test methodology
This data plane test provides throughput and latency information for a single router or a system
of interconnected routers, the system under test (SUT).
100G Ethernet Means Accelerated Testing...
Reduced Test Cycles
Higher Scale with Performance
Increased Focus on QoE100 G40 G10 GGigEYearQoS1 3 7 10QoES-CurveShift / Compression
For each successive generation, the S-curve from introduction to
maturity gets steeper as schedule expectations are collapsed.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
The throughput of a device or system is the maximum packet-forwarding rate for which
the device or system does not drop any of the offered packets. Any packet loss can induce
significant delays in the execution of higher layer applications. Knowing the maximum data rate
a device or system can support without any packet loss is of crucial importance when judging
the performance of a router or system of interconnected routers.
This test supports asymmetric traffic profiles to simulate real-world provider networks, where
upstream and downstream speeds differ.
This test also determines the latency of a device or system (the time it takes a packet to travel
through the device or the system), calculated at the maximum forwarding rate for which no
packet loss is experienced (throughput rate).
Back-to-Back (Burst Size) Test for IPv4 and IPv6
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Terminology for Network Interconnect Devices
This data plane test determines the maximum number of packets a router or system of
interconnected routers, the system under test (SUT), can forward back-to-back without packet
loss. The number of packets in the longest burst that does not cause packet loss is the back-to-
back value.
In a back-to-back test, the transmitter test ports deliver packets at full line rate with no pause
between successive packets, except the required legal separation for a given technology and
physical medium.
Validate Throughput, Packet Loss, Sequencing and Latency
Packet Loss, Sequencing and Latency for IPv4 and IPv6
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Terminology for Network Interconnect Devices
This data plane test determines the packet loss rate and latency for a single router or a
system of interconnected routers, the system under test (SUT) for various input data rates
and packet sizes.
The packet loss rate of a device or system is the percentage of Layer 3 frames that were offered
at the input of the device or system but were not forwarded by the device or system due to
hardware and software limitations. Calculating the packet loss rate of a system under different
load conditions (input data rate and packet size) serves to evaluate how the system performs
under similar conditions in real-life operation.
This test also determines the latency of a device or system (the time it takes a packet to travel
through the device or the system) calculated for the various input data rates, for which packet
loss may or may not be experienced.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
Validate Performance
IPv4/IPv6 Dual Stack Performance
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
This data plane test determines the ability of the system under test (SUT) to forward both
IPv4 and IPv6 packets. Devices operating in this mode are commonly referred to as running
a dual stack.
The key measurement areas are packet loss and latency. The packet loss rate of a device or
system is the percentage of Layer 3 frames offered at the ingress of the device or system
that were not forwarded by the device or system due to hardware and software limitations.
Calculating the packet loss rate of a system under different load conditions (input data rate
and packet size) serves to evaluate system performance under similar conditions in real-life
operation.
Packet latency is also determined for a device or system (the time it takes a packet to travel
through the device or system). Packet latency is calculated for the various input data rates and
packet sizes for which packet loss may or may not be experienced.
Dual Stack Ipv4 and IPv6 Jitter Test with Microburst
RFC 4689 - Benchmarking Network-layer Traffic Control Mechanisms
This data plane test measures the effects of a continuous microburst across the switch fabric
with the effects of increased jitter.
IPv6/IPv4: Dynamic DS-Lite scale and performance
DS-Lite (Dual-stack lite) is a transition technology that allows a service provider to roll out both
IPv4 and IPv6 addresses to subscribers. By encapsulating and splitting traffic based in IPv4 and
IPv6, the service provider can route traffic accordingly.
IPv6/IPv4: 6to4Tunneling Performance
RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
RFC 1242: Benchmarking Terminology for Network Interconnection Devices
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
This data plane test determines the ability of the system under test (SUT) to encapsulate IPv6
packets on the ingress port with an IPv4 header for transport across an IPv4 network. Prior
to arriving at the destination IPv6 network, this IPv4 header must be removed by a router to
expose the original IPv6 packet.
The key measurement areas are packet loss and latency. The packet loss rate of a device or
system is the percentage of Layer 3 frames offered at the ingress of the device or system but
not forwarded due to hardware and software limitations. Calculating the packet loss rate of
a system under different load conditions (input data rate and packet size) serves to evaluate
system performance under similar conditions in real-life operation.
Packet latency is also determined for a device or system (the time it takes a packet to travel
through the device or system). Packet latency is calculated for the various input data rates and
packet sizes, for which packet loss may or may not be experienced.
IPv6 Prefix Length Performance
RFC 2460: Internet Protocol Version 6 (IPv6) Specification
RFC 2374: IPv6 Aggregatable Global Unicast Address Format
RFC 2373: IP Version 6 Addressing Architecture
This data- and control-plane test measures the IPv6 data forwarding performance of a system
under test (SUT) that has an IPv6 route table of varying prefix lengths.
A test device port sends IPv6 routes with varying prefix lengths to the SUT using an IPv6
routing protocol. A second test device port sends data packets to the SUT. These data packets
utilize each of the different prefix lengths. Performance measurements per prefix length are
then taken.
Assess the Impact of the IPv6 FIB Size on Router Performance
Router Performance Impact of IPv6 FIB Size
RFC 2460: Internet Protocol Version 6 (IPv6) Specification
This data- and control-plane test measures the effect of data packet performance when the
system under test (SUT) has different numbers of IPv6 routes in its Forwarding Information
Base (FIB) table.
A test device port sends a fixed number of IPv6 routes to the SUT using an IPv6 routing
protocol. A second test device port sends data packets to the SUT that utilize routes in the FIB
table. Performance measurements of throughput, latency and packet loss of the data packets
are taken. The test is then repeated using more IPv6 routes in the router FIB table.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
TESTING 100G ETHERNET AT THE SPEED OF NOW
The 100G Ethernet delivery test requirements are different from 1G Ethernet and 10G Ethernet
because of the strong emphasis placed on QoS/CoS, realism, stacked protocols, and multiplay
services over 100G Ethernet.
Validate Data Transmission in Loopback Mode
IEEE 802.3ba.
This test determines whether the system under test (SUT) works error free in loopback. This test
places the SUT in loopback mode and verifies that traffic is received correctly without errors. In
this mode, each lane maps traffic to its respective virtual lane. Then, virtual lanes are mapped
to the physical layer. On the receive side, the procedure is reversed.
This test provides long duration verification and determines basic pathway and switching
robustness. It creates a baseline of expected results before involving the 100G Ethernet
module, provides long duration verification of the SUT, and determines that the basic pathway
and switching functions work correctly on the SUT.
Validate Performance of the Optics
IEEE 802.3ba.
By measuring potential errors over a long duration, this test determines whether the optics
function correctly. Numerous traffic patterns are generated across the optics. The optics
are then measured for traffic rate and error conditions. This test characterizes the optics,
determines whether the optics can pass traffic successfully, determines whether the optics
can run error free, provides long duration verification of the optics, and determines the skew
introduced while running traffic.
Validate Short and Long Term Performance of the PMA Layer
802.3ba
This test case determines whether the SUT generates traffic without errors at the PMA layer.
The primary function of the PMA is to multiplex M input lanes to N output lanes where needed.
The PMA also performs clock recovery, clock conversion, test pattern generation and detection
and loopbacks where applicable. This test case validates multiplexing validity and clocking,
recovery mechanisms, and determines the interoperability between the SUT and the tester at
the PMA layer.
Validate PCS Marker Alignment
IEEE 802.3ba
This test case verifies that the virtual lane markers are properly implemented in the
100G Ethernet SUT design by generating large amounts of traffic and determining whether
physical-to-virtual translation occurs correctly. Validating PCS lane markers enhances
interoperability and reduces the possibility of random errors in the field.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
Assess Maximum Lane Skew Limits
IEEE 802.3ba
This test case measures the range and correctness of individual lane skew inside the SUT 100G
Ethernet implementation. Lane skew is a difference in timing delay across lanes. Skew must be
compensated for on the receive time before the data stream may be reconstituted by the RX
port. Maximum skew compensation is an important metric in interoperability.
Standards-Based Benchmarks
RFC 2544: Benchmarking Methodology for Network Interconnect Devices
Industry benchmarks provide a standard method to measure and evaluate a solution through
a uniform procedure for the generation of traffic to and from the system under test supported
by a normalized procedure for analysis and reporting. The goal of the benchmark is to generate
metrics in a reproducible and unbiased fashion for comparability.
TESTING 100G ETHERNET IPV6 AT THE SPEED OF NOW
IPv6 and 100G Ethernet are pushing networking to new levels of performance. The massive
scalability required has implications not only for the devices used to build the network, but the
systems that test the devices and networks.
There are three key capabilities required of a test system for 100G Ethernet and IPv6.
Real-Time IPv4/v6 Routing at 100G Ethernet with Real-World Scenarios
Dual-stack implementation is the foundation of the foreseeable future, along with the
processing overhead and potential performance impact that goes with it.
Currently the internet routes 380,000 IPv4 prefixes aggregated to 220,000+ table entries,
compared to 7,500+ IPv6 prefixes aggregated to 6,400+ table entries. However, for IPv6 that
represents an over 100% increase year-on-year, compared to the 12% increase for IPv4.
Your test system must have the power and sophistication to emulate a dual-stack, MPLS-
enabled, real-world routing environment at line rate.
L2-L7 True Multi-Protocol Testing at 100G Ethernet
To deliver the QoE the customer expects, QoS must function without errors under line-rate
stateful traffic. That means your test system must deliver the realism of true emulation, not just
simulation, at 100G Ethernet to go beyond QoS to deliver QoE.
High Port-Density Testing at 100G Ethernet
Depending on the platform, a router chassis can have up to 32 x 100G Ethernet ports. While
initial deployments may not require 3 terabits of throughput per chassis, current growth rates
indicate that the requirement is not that far in the future. Your test system needs the power to
match the scale of the production network.
100G Ethernet: The Speed of Now
Validating IPv4/v6 Performance on 100G Ethernet
Testing the Tester
Testing goes beyond the ability to throw traffic at a box or system. Testing the unprecedented
scale of speed and users involved with 100G Ethernet and IPv6 with realism requires a test
platform that can not only scale to stress the system, but can insulate your workflow from the
negative effects of high-scale testing and results.
A test platform is a competitive differentiator that can mean the difference between accelerated
time to market or costly schedule delays. Don’t hesitate to ask the tough questions about your
existing system or a system under consideration. Make sure it supports:
• Detailed statistics with targeted analysis: The power of testing is the ability to gather
comprehensive results and interpret them. Before selecting a system, look at the results
it produces from real tests and ask pointed questions about using them to quickly
identify root problems. A test system that streamlines troubleshooting through powerful
results can significantly accelerate design and development. Good results can help you
stay on or ahead of schedule.
• Scalability: Numbers matter. You need a good understanding of your target
environment, including plans for growth. Armed with this information, verify that the
test platform can scale to your requirements in terms of numbers of users, clients,
subscribers, application services, VMs, and ports.
• Ease of use: There should be one system that controls all test scenarios. Your day is
complicated enough without having to learn multiple interfaces for different elements of
a single test system.
• Automation: The ability to automate individual tests and suites of tests is a
fundamental element in test lab productivity. In these days of reduced resources and
increased expectations, simple, manageable automation is not a luxury, it’s essential.
CONCLUSION: TESTING AT THE SPEED OF NOW
The combination of more subscribers than ever demanding more high-bandwidth, delay-
sensitive, real-time content than ever requires equipment manufacturers and service providers
to deliver more powerful solutions and higher QoE than ever.
The scale of IPv6 and 100G Ethernet brings new challenges to the market and specifically to
the test lab. Test realism, scalability (whether in ports, subscribers, sessions, VPNs, routes,
tunnels, or VLANs), automation and intelligent results that help you quickly pinpoint root causes
are more important than ever.
Make sure your test platform can deliver what you need to stay ahead of schedule, ahead of
demand, and ahead of the competition.
For more information see www.spirent.com/ethernet.
