Spirent Journal of L2/3 QoS PASS Test Methodologies
Quality of Service, or QoS, testing is the set of processes and test cases to verify that services are given the correct amount of resources at the network forwarding and transport layer. QoS allows the user to configure differentiated services either as a global policy or as a Service Level Agreement (SLA). This journal presents a comprehensive set of test cases to measure PASS of the Device Under Test (DUT).
PASS
Spirent Journal of Layer
2/3 QoS PASS Test
Methodologies
February 2011 Edition
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
1
Introduction
Today’s Devices Under Test (DUT) represent complex, multi-protocol network elements with an emphasis
on Quality of Service (QoS) and Quality of Experience (QoE) that scale to terabits of bandwidth across the
switch fabric. The Spirent Catalogue of Test Methodologies represents an element of the Spirent test
ecosystem that helps answer the most critical Performance, Availability, Security and Scale Tests (PASS)
test cases. The Spirent Test ecosystem and Spirent Catalogue of Test Methodologies are intended to help
development engineers and product verification engineers to rapidly develop and test complex test
scenarios.
How to use this Journal
This provides test engineers with a battery of test cases for the Spirent Test Ecosystem. The journal is
divided into sections by technology. Each test case has a unique Test Case ID (Ex. TC_MBH_001) that is
universally unique across the ecosystem.
Tester Requirements
To determine the true capabilities and limitations of a DUT, the tests in this journal require a test tool that
can measure router performance under realistic Internet conditions. It must be able to simultaneously
generate wire-speed traffic, emulate the requisite protocols, and make real-time comparative
performance measurements. High port density for cost-effective performance and stress testing is
important to fully load switching fabrics and determine device and network scalability limits.
In addition to these features, some tests require more advanced capabilities, such as
Integrated traffic, routing, and MPLS protocols (e.g., BGP, OSPF, IS-IS, RSVP-TE, LDP/CR-LDP) to
advertise route topologies for large simulated networks with LSP tunnels while simultaneously
sending traffic over those tunnels. Further, the tester should emulate the interrelationships
between protocol s through a topology.
Emulation of service protocols (e.g., IGMPv3, PIM-SM, MP-iBGP) with diminution.
Correct single-pass testing with measurement of 41+ metrics per pass of a packet.
Tunneling protocol emulation (L2TP) and protocol stacking.
True stateful layer 2-7 traffic.
Ability to over-subscribe traffic dynamically and observe the effects.
Finally, the tester should provide conformance test suites for ensuring protocol conformance and
interoperability, and automated applications for rapidly executing the test cases in this journal.
Further Resources
Additional resources are available on our website at http://www.spirent.com
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
2
Table of Contents
Testing Layer 2/3 QoS ............................................................................................................3
L23_001 Validate source port priority for layer 3 Ethernet ................................................ 5
L23_002 VLAN scale with CoS............................................................................................. 9
L23_003 Service edge remarking test .............................................................................. 13
L23_004 Verify QoS traffic shaping by service class ......................................................... 16
L23_005 QoS SOAK policing test ...................................................................................... 20
L23_006 QoS compliance in microburst conditions .......................................................... 23
L23_007 Measure the DUT queuing mechanism .............................................................. 27
L23_008 VLAN Q-in-Q scalability with PRI ........................................................................ 30
L23_009 Determine whether the DUT processes specific stream sequences ................... 33
L23_010 Determine whether the DUT forwards a mix of jumbo and traditional frame
sizes .................................................................................................................... 36
L23_011 Determine DHCPv4/v6 lease acquisition time under scale ................................ 39
L23_012 Determine the minimum time between sequence errors with microbursts ...... 42
L23_013 Evaluate ultra-Low latency stability with microbursts ...................................... 45
Appendix A – Telecommunications Definitions ..................................................................... 48
Appendix B – Layer 2 802.1q CoS .......................................................................................... 55
Appendix C – RFC 2474 Layer 3 QoS ...................................................................................... 56
Appendix D – RFC 2474 Layer 3 QoS Definitions .................................................................... 57
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
3
Testing Layer 2/3 QoS
Quality of Service, or QoS, testing is the set of processes and test cases to verify that services are given
the correct amount of resources at the network forwarding and transport layer. QoS allows the user to
configure differentiated services either as a global policy or as a Service Level Agreement (SLA).
Thus, Quality of Service is the ability to control the characteristics of ongoing communication services.
Service providers use these control values to offer improved, and possibly contract, levels of service. QoS
is an end-to-end responsibility that involves clients, switches, routers and servers.
The manner in which
remarked packets are
presented to the user allows
or breaks a device’s ability to
forward traffic according to a
policy. For example, steady-
state traffic may forward
correctly, but bursts of traffic,
such as a flood of VoIP or
video traffic, may break the
QoS policy. Testing with real-
world traffic patterns
becomes critical because it is
possible to spend valuable
time configuring a test that lacks real-world application.
Spirent TestCenter™ is the best platform for testing L3 and L4 QoS. TestCenter generates differentiated
and marked traffic and also mixes VBR (Variable Bit Rate) traffic such as MPEG-2/4 or SIP, and CBR
(Constant Bit Rate) or steady state such as data traffic out the same port at the same time.
From a QoS queue management perspective, it is much harder to forward bursts of unexpected but
higher priority traffic compared with classic, repetitive traffic. This traffic differs from other testers by
forcing more CPU look-ups than the Device Under Test (DUT) would experience in a production network.
The user is able to correctly emulate real-world conditions by properly constructing correct, differentiated
traffic such as:
Also, QoS testing requires loading and deep, single-pass inspection of performance. QoS in the real world
is never an analysis of a single metric but a mix of simultaneous metrics. The first step in testing is to
create congestion. With over 32K TX streams and real-time analysis of over 64K streams, measuring up to
41 simultaneous metrics per stream, Spirent TestCenter becomes the only viable platform to test QoS.
Spirent TestCenter simultaneously congests the DUT to turn on QoS and measure all required metrics
necessary to properly assess QoS. For example, TestCenter is the only platform that can measure true
jitter. This is critical to QoS testing because only true RFC 4689 jitter can measure the effect of latency
variation on triple-play traffic.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
4
Spirent TestCenter true jitter is defined as the following:
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
5
L23_001 Validate source port priority for layer 3 Ethernet
Abstract
The purpose of this test case is to determine whether the device under test (DUT) will correctly
drop or delay lower priority traffic in favor of higher priority traffic. This is achieved by over
subscribing the egress port for 1G/10G/40/100G Ethernet. Without validation, the user will not
know if QoS, as defined by the ACL, is compliant..
Description
The objective of this test case to determine whether the DUT properly processes traffic set in a
Layer 3 (L3) QoS policy by the source port. This test determines whether the DUT, when in a
congested state, selectively delays and drops traffic from lower priority ports in favor of higher
priority ports. The DUT pass this test when it maintains the following attributes by class over the
duration of the test.
Packet Loss
(Frame Count)
Maximum Sequence
Errors (Frame Count)
Maximum latency
(uSec)
Network Control (EF) 0 Frames 0 Frames 7 uSec
Real-Time Control
(AF31)
1000 Frames 10 Frames 10 uSec
Best Effort (BE) Any Frames Any Frames Any
Relevance
Test QoS Egress ACL
Test multidimensional, multivariable QoS
Tests interactions between performance metrics in a single instance of the DUT state machine
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[ ] Performance [x] Availability [ ] Security [ ] Scale
Required Tester Capabilities
The tester must have the ability to measure sequencing, loss, and latency with every packet. In
addition, the tester must be able to distinguish loss, duplicate, late, and re-ordered packets
dynamically. The tester must be able to generate multi-burst and mix VBR and CBR in real-time.
For analysis, the test equipment must have the ability to define a multi-dimensional ACL and
prove compliance per ACL in near-real time.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
6
Topology
Test Procedure
1. Reserve the appropriate Ethernet test interfaces. Interfaces may be 1G/10G/40G, or 100G
Ethernet.
2. Select a single interface to be the edge test interface. All other test interfaces will belong to
the core set of interfaces, with the intent to over subscribe the edge interface.
3. Configure the DUT by bringing up the relevant interface. Each interface should be a /16
network. Configure the following ACLs in the DUT for outbound traffic.
a. Traffic with DiffServ codepoint EF (Network Control):
i. No Drop.
ii. Max Jitter <=100 nSec.
iii. No sequencing errors allowed.
iv. Max latency <= 7 uSec or less.
b. Traffic with DiffServ codepoint AF31 (Real-Time Control).
i. Max Drop <= 1000.
ii. Max Sequencing Errors <=10.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
7
iii. Max Latency <=10 uSec.
iv. Max Jitter <= 300 nSec.
c. Traffic with DiffServ codepoint BE (Best Effort).
i. Unmeasured.
4. On Each core test port, configure three stream blocks with IPv4 and DiffServ codepoints set
to: EF, AF31, and BE respectively. Set the host block count to 1. Set each port to port priority
mode.
a. For the stream marked with EF, set the burst count to 1 with a priority of 0 and a stream
rate of 1%.
b. For the stream marked with AF31, set the burst count to 10 with a priority of 1 and a
stream rate of 3%.
c. For the stream marked with BE, set the burst count to 100 with a priority of 2 and a
stream rate 96%.
d. Duplicate test setting on all core ports. Set the destination address to the edge port.
5. On the analyzer on the edge port, setup a dynamic view. Look for conditions in Section 3 that
do not met their respective ACL rules.
6. Start traffic, wait 300 seconds.
7. On edge port, refresh dynamic view. Check to see if there are any entries. If the ACL is
working on the DUT, there will be no entries.
8. Step through a set of host count (1, 10, 100, 100, 1M) per stream and AF31 burst size set (10,
50, 77, 99, 105, 500, 1000). Set the new vales without stopping traffic of the previous step
and go to set 6.
9. End.
Variables & Relevance
Variable Relevance
EDGE Edge Facing QoS Test Interface
CORE Set of Core facing Interfaces to over subscribe the EDGE
interface
Burst Size Size of each streams burst
Host Count Number of Hosts per stream per DiffServ Codepoint
Desired Result
The Dynamic view should not show any results, thus, no stream is out of spec with the ACL QoS
rule.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
8
Key Measured Metrics
Statistic Relevance
EDGE Dynamic View Multidimensional adherence to ACL rule by DiffServ
Codepoint
Analysis
Because the system is dynamic, looking at sequencing, jitter, latency and other metrics, bound
together in a dynamic view, and because the dynamic view only shows streams out of
compliance, any results in the dynamic view demonstrates a non-functioning ACL. Also, because
the user is stepping across different burst sizes and rates, the user can be assured that different
traffic pressure conditions are verified as seen in production networks
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
9
L23_002 VLAN scale with CoS
Abstract
VLAN scalability is a critical component to the ability of the DUT to enforce a uniform QoS/CoS
policy. This test case first scales the number of VLANS until the VLAN priority policy is not met.
Without testing the VLAN with CoS, the DUT may not be able to perform Layer 2 CoS in
production networks.
Description
IEEE 802.1Q provides a mechanism for testing CoS at the VLAN level using the PRI field. In this
test case, the user creates 7 pools of VLANS, each with a different priority level and a fixed
number of source MAC addresses per VLAN. The test then scales the number of VLANS up and
checks CoS for each stream across every VLAN. When the specific CoS policy is no longer valid on
any priority level, the number of VLANs per priority will be deemed to be maximum.
802.1 PRI
CoS
Min. RX / TX
Bandwidth
Ratio
Max
Jitter
(uSec)
Max
Latency
(uSec)
Max
Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max
Late
(Frames)
7 1 0 >=1 0 0 0 0
6 1 0 2 0 0 0 0
5 .99 1 2 0 0 0 0
4 .98 1 3 0 0 0 0
3 .95 2 5 0 1 1 1
2 .90 3 5 1 1 1 1
1 .85 5 10 1 2 2 2
0 ANY ANY ANY ANY ANY ANY ANY
Table 1 – CoS Analysis Values by 802.1Q PRI
Relevance
Determine the effective maximum number of VLANs capable to maintaining CoS.
Determine CoS in steady and non-steady state traffic patterns.
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[ ] Performance [ ] Availability [ ] Security [x] Scale
Required Tester Capabilities
The tester must have the ability to generate the full range of IEEE 802.1Q VLAN and PRI traffic, as
well as unique streams per VLAN/MAC tuples. The test must be able to add live traffic while
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
10
existing traffic is transmitting. The tester must have the ability to generate bursty and steady-
state traffic. In addition the tester must have the ability to measure latency, bandwidth, Jitter,
loss, re-ordered, late, and duplicate packets in real-time.
Topology
Test Procedure
1. Reserve the desired number of test Interfaces. Bring all interfaces’ link to an UP state.
2. Evenly divide the test interfaces into two groups, east and west.
3. On both sets of test ports and the DUT, create 7 VLANs by VLAN ID. Sequentially, number
the VLAN IDS and PRI fields as:
a. VLAN 1, PRI 7, Burst=1.
b. VLAN 512, PRI 6, Burst=3.
c. VLAN 1023, PRI 5, Burst=5.
d. VLAN 1534, PRI 4, Burst=7.
e. VLAN 2340, PRI 3, Burst=10.
f. VLAN 2851, PRI 2, Burst=500.
g. VLAN 3362, PRI 1, Burst=1000.
h. VLAN 3873, PRI 0, Burst=3000.
4. Configure ACLs on the DUT to meet the values in Table 1.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
11
5. Create a host block for each PRI level on every test Interface. Set the host count as desired.
Set the host MAC Source to increment by VLAN to one byte greater than the number of
hosts per VLAN.
6. On each port, create a dynamic view that finds non-compliant streams by PRI level (A NOT of
each row in table 1, combined with ORs). Create a customer field to calculate each streams
RX/TX frame rate ratio.
7. Setup traffic connecting like VLAN IDs from the east set to the west Set. Set all test Interfaces
to port priority mode. Set each stream burst count as indicated in Step 3 and a priority
count equal to the PRI value of the stream. Set the ‘Use Streams’ option in the wizard. Use
the pair traffic pattern.
8. Set the rate of each stream by line rate / total number of streams, per stream.
9. Transmit traffic for desired duration.
10. Refresh the dynamic view. If you detect any entries stop. The total VLAN with CoS for the
current frame size is the current VLAN count – 7. If you reach 4095 VLANS with no entries,
then the count is 4095 for this frame size. Go to Step 13.
11. For each VLAN PRI, duplicate the host block on both east and west port sets. Increment the
VLAN of each. Rerun the traffic wizard and connect the two blocks as in step 7 between the
new entities.
12. Go to Step 9.
13. Increment the frame size to the next entry in the set. Go to Step 9.
14. End.
Variables & Relevance
Variable Relevance
Hosts per VLAN Number of MAC address per VLAN
Default: 255
Number of Test Interfaces Number of Connected test Interfaces
Default: 2
Iteration Time Number of seconds per Iteration
Default: 300 seconds
EAST Set First Set of test Interfaces
WEST Set Second Set of test Interfaces
Test Frame Size Set Frame sizes to test over
Default: {72, 128, 256, 512, 767, 1024, 1280, 1518, 9022}
Desired Result
The DUT should be able to forward traffic compliant with CoS across 7 CoS Profiles and 4095
VLANs for the desired set of frame sizes.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
12
Key Measured Metrics
Statistic Relevance
Peak VLAN Capacity with QoS Number of VLANs capable of forwarding with a CoS Profile
by frame size
Analysis
Create a table with Y-Axis representing Frame Size, and X-Axis representing Maximum VLANs
with Cos. Fill out the table with measured values.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
13
L23_003 Service edge remarking test
Abstract
The edge of the network is where most DiffServ is marked by the network. This test determines
whether the DUT can remark the DiffServ field according to an ACL table. An untested DUT may
incorrectly mark traffic into the network.
Description
Service edge remarking is a critical component to QoS testing. This test case creates a pool of
hosts at the edge of the network with a mix of different services. This traffic is measured on the
core-facing interface to determine whether the VLAN ID, VLAN PRI, and DiffServ
codepoint/Traffic Class is set correctly. This test then loops across different frame sizes to
determine whether frame size has an impact on remarking.
Relevance
Tests IPv4 and IPv6 remarking
Tests Untagged to tagged remarking with CoS
Teats across frame size
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[ ] Performance [x] Availability [ ] Security [ ] Scale
Required Tester Capabilities
The tester must have the ability to generate IPv4 and IPv6 with multiple UDP and TCP services.
The tester must have the ability to measure remarking in real-time.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
14
Topology
Test Procedure
1. Reserve two test Interface ports. Bring up link on both. Assign one interface as the edge
interface and the other as the core.
2. Build a table of expected results.
a. Row should represent L3 and L4 tuples (Ex. IPv4 / TCP 80, IPv6 / UDP 53).
b. Columns should represent remarked behavior.
i. Column 1 should represent VLAN ID or untagged.
ii. Column 2 should represent he VLAN PRI field.
iii. Column 3 should represent DiffServ Codepoint based on L4 destination port
number.
3. Configure the DUT to reflect this remarking scheme.
4. On the Edge port, setup one STREAMBLOCK per row in the table. The StreamBlock should
have the appropriate IP addressing, L4 header, and L4 destination address. DiffServ and
traffic class should be marked with 0.
5. Note the StreamID for each stream.
6. On the core port, setup a dynamic view. In the dynamic view, create a condition per row
linked with ORs. Each condition should be a NOT (Ex, NOT VLAN ID OR NOT DiffServ
Codepoint etc.) Each row should be AND with its StreamID from the table. This will then only
show frames that were improperly remarked.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
15
7. Set the port rate to 100%. Set the frame size to the current value from the frame set.
8. Transmit traffic for the desired iteration time.
9. Refresh the dynamic view. Note any entries. Entries mean a remarking failure.
10. Change the frame size of each stream to the next frame size in the set.
11. Go to Step 7.
12. End.
Variables & Relevance
Variable Relevance
ACL Table Table to Test
Frame Size Set Frame Sizes to test across.
Default: 1280, 1518, 9022
Iteration Time Time per iteration in Seconds
Default: 300 Seconds
Desired Result
All frames, across all frame sizes, should remark traffic correctly.
Key Measured Metrics
Statistic Relevance
Incorrectly Remarked Frames Shows which frames and at what frame sizes do not
remark correctly.
Analysis
For each row and for each frame size where there was a remarking error, create a table and
document which frames and at what rate remarking errors occurred.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
16
L23_004 Verify QoS traffic shaping by service class
Abstract
Traffic rate shaping based on upper layer protocol is a key delivery mechanism for QoS in the
network. This test generates a mix of protocols and verifies the DUT QoS policy by rate, jitter,
sequencing, and latency. The ability of an untested DUT to limit specific protocols in the network
is unknown.
Description
This test determines whether the DUT is capable of rate and performance limit protocols based
on an ingress and egress QoS policy. On the transmission side, a mix of ingress protocols is
generated to the DUT in a mix of burst sizes. On the egress, the rate and performance metrics is
measured and compared to the QoS policy for verification.
Relevance
Determine whether the rate shaper is working.
Verify dependencies based on frame size, frame size mix, and duration.
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[x] Performance [x] Availability [ ] Security [ ] Scale
Required Tester Capabilities
The test equipment must have the ability to generate multiple stateful and stateless protocols
with different burst sizes and measure key performance metrics on generated traffic in real-time.
The test equipment must be able to add and remove traffic while not stopping existing traffic.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
17
Topology
Test Procedure
1. Reserve 2 test interfaces. Bring link up. Define test port A as the edge interface and test port
B as the core interface.
2. Define an ACL performance shaping table.
a. Rows should represent protocols (Ex. HTTP / TCP Dest. 80).
b. Column 1 should represent the minimum rate by protocol.
c. Column 2 should represent maximum rate by protocol.
d. Column 3 should represent maximum jitter by protocol.
e. Column 4 should represent maximum latency by protocol.
f. Column 5 should represent maximum loss by protocol.
g. Column 6 should represent maximum late packet by protocol.
h. Column 7 should represent minimum goodput for HTTP traffic.
i. Column 8 should represent minimum MOS-LQ VoIP Quality.
3. Apply the table policy to the DUT.
4. On each test interface, create a host block with appropriate addressing to match the DUT.
5. On the core Interface, create a dynamic view with the following properties.
a. Create a condition for stateless traffic:
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
18
i. DEST L4 PORT Number AND RATE NOT BETWEEN (MIN and MAX) OR Measured
Jitter > MAX JITTER OR Measured MAX Latency > MAX latency OR Measures Loss >
MAX LOSS or Measured LATE > Max Late.
ii. Combine each condition with an OR.
6. Create stateful HTTP between the edge and core with a 512 Byte Return. Set the Duration to
greater than the current Iteration set.
7. Create stateful VoIP traffic between the edge and Core. Play a WAVE file thought the RTP
stream and setup the call with SIP.
8. Generate Stream Traffic with UDP traffic with a random Destination port between 10001-
65535. Set the rate to 80% of line rate for this stream blocks.
9. Set the Host Block count from the Set.
a. Set the Frame Size of the StreamBlock
i. Set the Iteration Time.
1. Generate Traffic for the current Iteration Time.
2. Refresh Dynamic View.
3. If there are any entries in the Dynamic view, or the MOS-LQ score is
below minimum or HTTP Goodput is below minimum, the iteration
FAILS, else it Passes.
10. Record all entries.
11. END.
Variables & Relevance
Variable Relevance
Frame Size Set Frame Sizes to test across
Default: {64, 128, 256, 512, 768, 1024, 1280, 1518, 9022}
Iteration Time Set Duration set to Test each frame size in Seconds
Default: {10s, 30s, 60s, 300s, 3600s}
Host Count Set Number of Hosts per Test Interface
Default: {1, 10, 256, 1000, 10k}
Desired Result
The Device under test should be able to forward traffic at line rate for the respective host count
set over the desired iteration time.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
19
Key Measured Metrics
Statistic Relevance
Performance Limiting Set of Rules to limit low priority traffic
Minimum HTTP Goodput Performance of HTTP traffic
Minimum MOS-LQ Minimum Voice Quality
Analysis
Through all combination of frame size, duration, and host count, the DUT should be able to rate
limit the P2P traffic simulation. Report any permutations whereby the DUT cannot
simultaneously performance shape the P2P Traffic and maintain minimum HTTP and VoIP quality.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
20
L23_005 QoS SOAK policing test
Abstract
The ability of the DUT to maintain QoS over time is a critical attribute. This test case tests the
QoS capabilities of the DUT over a 48-hour period of high, random load. Without verification,
QoS policing may breakdown over time.
Description
In this test, traffic is generated in full, multi-mesh patterns with random load and frame size.
Each subnet further creates partial meshes from each host in the subnet. The traffic is generated
for a 48-hour window, whereby latency, max and average jitter, loss, and duplicate max is
charted over time by DiffServ Codepoint.
Codepoint Max
Jitter
(uSec)
Max
Latency
(uSec)
Max
Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max Late
(Frames)
EF 0 >=1 0 0 0 0
AF31 0 2 0 0 0 0
AF21 2 5 0 1 1 1
AF11 3 5 1 1 1 1
BE ANY ANY ANY ANY ANY ANY
Table 1 – Recommended QoS Performance minimums by DiffServ
Relevance
Measure how QoS Changes over time.
Version
1.0
Test Category
Measuring L2/3 QoS
PASS
[x] Performance [ ] Availability [ ] Security [ ] Scale
Required Tester Capabilities
The test equipment must have the ability to generate multi mesh (mesh between subnets, sub-
meshes between hosts within each subnet) as well as be able to set random load and frame size.
On the analysis side, the test equipment must be able to chart real-time latency, max and
average jitter, loss, and duplicates by DiffServ Codepoint.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
21
Topology
Test Procedure
1. Reserve desired test Interfaces. Bring link up.
2. Apply the QoS profile to all ports on the DUT.
3. On each test interface, set the port loading mode to port based and randomize the rate
between 1% and 100% of line rate.
4. On each test interface, create host blocks with the desired number of hosts per subnet.
5. Create traffic among all test interfaces in a full mesh pattern. Set the end point mapping to
many-to many, to create a partial mesh between hosts across the subnet. Set the frame sixe
to random.
6. Set the DiffServ Codepoint according to Table 1.
7. Repeat steps 4 and 5, incrementing the DiffServ Codepoint. Label each traffic block their
respective Codepoint.
8. Create a filtered view, and sort by DiffServ Codepoint. Create a real-time graph graphing max
and average latency, max and average jitter, loss, and duplicate test wide.
9. Transmit traffic for 48 hours.
10. Document the generated graphs.
11. End.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
22
Variables & Relevance
Variable Relevance
Hosts per Subnet Number
Desired Result
For EF and AF31 Codepoint the first data points and the last data points in the charts should not
vary. For AF21 and AF11, some minor variance is acceptable. BE is not measured.
Key Measured Metrics
Statistic Relevance
Max and average latency, max and
average jitter, loss, and Duplicate
QoS metrics
Analysis
Examine the real-time charts, higher QoS values should not vary over time. Middle range vales
should have some variance, but be below upper ranges vales. Best Effort is not measured. Be
especially aware of lower priority values exceeding the capacity of higher marked traffic. This
represents a QoS Failure.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
23
L23_006 QoS compliance in microburst conditions
Abstract
High quality traffic such as voice and video tend to be highly bursty in nature. This test case
determines whether the QoS policer properly prioritizes bursty high-quality traffic in an
oversubscription scenario. Without this test, the DUT may not be able to maintain end-to-end
Quality of Experience.
Description
In this test case, test Interface A generates a microburst of high-quality traffic into the DUT with a
Codepoint of AF31. Test interface B generates steady-state best-effort (Codepoint BE) line-rate
traffic. Traffic from both test interfaces A and B have a destination of test interface C. The test
determines whether the DUT is capable of maintaining QoS traffic on the high-quality traffic
Relevance
Determines whether QoS is maintained when high-quality traffic is burst into the buffers.
Tests the DUT switch fabric and lookup tables for efficiency.
Detects possible problem areas when sudden high-quality pressure is placed on the QoS
system.
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[ ] Performance [x] Availability [ ] Security [ ] Scale
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
24
Required Tester Capabilities
The tester must be able to generate microburst conditions across the DUT in an oversubscription
condition. In addition, the test equipment must be able to see the effects of the burst on egress
with a resolution of 10 nSec or less. The tester must also be able to analyze generated sequence
numbers packet by packet to determine queuing problems in the DUT output queue.
Topology
Test Procedure
1. Reserve 3 test Interfaces, A, B, and C. Test Interfaces A and B are edge facing and test
Interface C is core facing. Bring up link.
2. Establish this QoS policy in the DUT:
Codepoint Max
Jitter
(uSec)
Max
Latency
(uSec)
Max
Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max
Late
(Frames)
AF31 0 2 0 0 0 0
BE ANY ANY ANY ANY ANY ANY
3. On test interface C, create a filtered view based on DiffServ Codepoint. Change to that view.
Place a VFD variable in the source and destination. The VFD should increment the source by
a quantity of (ARP cache limit - .01 (ARP cache limit) / 2. The destination should also
increment the same quantity as the source VFD, but beginning in a unique range.
4. On test interfaces B & C, setup a bi-directional StreamBlock at line rate at 64 bytes and
DiffServ marked as BE. Place a VFD variable in the source and destination flipped from Step 3
for HostBlock C.
5. Perform L2 Learning for test Interface B and C.
6. Start traffic on test interfaces B and C
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
25
7. On Test Interface A, Create a HostBlock with 1% of the ARP Cache Limit.
8. Create traffic from Hosts in test interface A to the first 1% of hosts on test Interface C. Set
the frame Size to 64 bytes. Turn on PRBS payload. Mark the traffic as DiffServ AF31.
9. On host port A, set the port mode to manual mode.
10. Set the microburst schedule to:
Entry Flow Return
to Entry
Loop
Count
Burst
Count
Burst
Size
IFG
(Percent %)
IBG
(Bytes)
IEG
(Bytes)
1 Down Next 1 3 2 12 12
2 Down Next 2 5 5 12 12
3 Loop 1 100 1 7 100 12 12
11. Start capturing traffic on test interface C with a hardware filter to only capture traffic
marked DiffServ AF31. On test interface C, setup a high resolution stream sampling. Sample
the stream containing AF31 traffic from test Interface C. Setup the parameters of the high
resolution sample to trigger when conditions in Step 2 are not met. Start the high resolution
sample on test interface C.
12. Start transmission on test interface A
13. After the desired iteration time, stop the traffic and capture.
14. On test Interface C, for AF31 tagged traffic, examine the performance metric in Step 2.
15. If the performance metrics are compliant, then the DUT is QoS microburst compliant, else it
is not.
16. End.
Variables & Relevance
Variable Relevance
APR Cache LIMIT Maximum Entries in the DUT ARP cache
Iteration Time Time to test in Seconds:
Default: 300s
Desired Result
In the course of micro bursting into the DUT, the AF31 tagged traffic should be QoS compliant
for all packets marked with AF31.
Key Measured Metrics
Statistic Relevance
See Table in Step 2 Performance metrics for AF31 tagged traffic
Capture Packet by packet capture of AF31 traffic
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
26
Analysis
Examine the performance metrics for AF31 tagged traffic. Create a time-based chart showing
each performance metrics in Step 2. To drill down, also report any triggered conditions in the
High resolution sampling, if present. Finally, from the capture, examine the Spirent signature
field sequence number by exporting the capture to a CSV and import the CSV into a spreadsheet
application and graph the sequence numbers packet-by-packet. Here you will see how the egress
QoS buffer handles traffic packet by packet.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
27
L23_007 Measure the DUT queuing mechanism
Abstract
This test case determines whether the DUT can handle a continuous transmit of streams
containing varying ToS values, load patterns, different IFGs/IBGs, frame count etc. This test case
builds a fixed number of streams with varying parameters and schedules them to induce the
most possible stress on the DUT’s queuing mechanism. The DUT should not drop packets and
there should not be significant impact on the sequence counters. Also, there should be no
significant increase in packet latency.
Description
Different DUTs have different internal queuing mechanism based on factors such as frame sizes,
ToS values, memory etc. and use hashing algorithms to route/switch incoming traffic to
egress interfaces.
This test case builds and transmits several streams with varying frame sizes, Inter-frame gaps,
Inter-burst gaps and specific load patterns to test the DUT’s queuing mechanism. There should
be no dropped, re-ordered, duplicate or late frames or significant latency variations between
streams with varying ToS values and/or other IP fields.
Relevance
Test DUT’s Queuing Mechanism.
Test DUT’s ability to obey the ToS values in the IP packets.
Test DUT’s Hashing Algorithm.
Stress Testing the DUT.
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[x] Performance [x] Availability [ ] Security [ ] Scale
Required Tester Capabilities
Ability to schedule Stream Transmission in a user defined manner.
Results reporting capability based on various IP packet fields.
Per-stream latency reporting capability.
Packet Sequencing Counters like Dropped Frames, Re-ordered frames, Late Frames and
Duplicate frames.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
28
Topology
Test Procedure
1. Create a fixed number of Streams.
a. Vary the ToS value in each of the StreamBlock. (May have the same value for
more than 1 stream.)
b. Vary the source/destination MAC by using a modifier.
c. Vary the frame size for each of the stream.
i. Alternately, the user can also use iMIX for each of the stream.
2. Select the scheduling mode which will allow the user to manually schedule the streams
for transmission.
3. Build a scheduling table using the already created streams in Step 1 above.
a. Configure up to 100% bandwidth but do not over subscribe.
4. Repeat Step 1 to 3 for Port 2 but use different addressing schemes while keeping the
overall port load.
5. Start traffic.
a. Observe the per-stream sequencing counters to verify that the DUT does not
favor a particular stream.
b. Observe the per-stream latency values to verify that there are not significant
differences between the streams.
6. Change the scheduling table and/or add more streams to see if you observe any
different results.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
29
Variables & Relevance
Variable Relevance
IP ToS Value The higher the ToS value, the more priority it gets on the
DUT
Source/Destination MAC
Addresses
Having varying address values tests the DUT’s Hashing
Algorithm
Desired Result
The DUT shouldn’t report any dropped, re-ordered, late or duplicate frames.
Key Measured Metrics
Statistic Relevance
Per-stream Dropped, Re-ordered,
Late or Duplicate Frames
Verifies how deep the DUT buffers run
Per-stream Latency Values Verifies if the DUT is wrongly favoring one stream over
other
Analysis
The DUT shouldn’t report any dropped, re-ordered, late or duplicate frames. There may be
scenarios in which these counters will increment and that would give the user an idea about the
DUT‘s architecture and behavior in various conditions. If we observe drops or any other
sequencing counter increment just in one direction, it would indicate an abnormal DUT behavior
as well.
The latency of high value QoS streams should be lower than for streams with a lower QoS value
for instantaneous values and over long testing durations.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
30
L23_008 VLAN Q-in-Q scalability with PRI
Abstract
Service provider scalability for Q-in-Q VLAN is a critical element for deployment and service
offering in traditional and virtualized networks. This test measures the peak depth of Q-in-Q
while maintaining an IEEE 802.1p compliant priority schedule. Without this measurement, the
DUT may not be able to deliver certified priority levels under peak load.
Description
Q-in=Q VLANs allows for exponentially more service tunnels inside metro WAN environment.
This test case scales up the number of Q-in-Q VLANS until prioritization is not met.
This test case tests the following PRI schedule:
802.1 PRI
CoS
Min. RX / TX
Bandwidth
Ratio
Max
Jitter
(uSec)
Max
Latency
(uSec)
Max
Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max
Late
(Frames)
7 1 0 >=1 0 0 0 0
6 1 0 2 0 0 0 0
5 .99 1 2 0 0 0 0
4 .98 1 3 0 0 0 0
3 .95 2 5 0 1 1 1
2 .90 3 5 1 1 1 1
1 .85 5 10 1 2 2 2
0 ANY ANY ANY ANY ANY ANY ANY
Table 1 – prioritization performance table
Relevance
Measures scale of Q-in-Q VLAN with priority.
Version
1.0
Test Category
Testing L2/3 QoS
PASS
[ ] Performance [ ] Availability [ ] Security [x] Scale
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
31
Required Tester Capabilities
The tester must have the ability to generate the full range of IEEE 802.1Q VLAN and PRI traffic, as
well as unique streams per VLAN/MAC tuples. The test must be able to add live traffic while
existing traffic is transmitting. The tester must have the ability to generate bursty and steady
state traffic. In addition the tester must have the ability to measure latency, bandwidth, Jitter,
loss, re-ordered, late, and duplicate packets in real-time.
Topology
Test Procedure
1. Reserve two test ports, A and B. Bring link up.
2. Install the table 1 priority schedule into the DUT.
3. On tester ports A and B, setup 4095 VLAN at the current level with a distribution of desired
relative percentage of priority.
4. Setup a pair traffic between hosts of like VLAN ID in a many-to-many mapping.
5. Transmit traffic for the desired Iteration
6. Examine the performance metrics in table 1 by PRI. If all Priority levels pass, then add a Q-in
Q layer, creating 4095^current layer of VLANS. Priority levels should be of relative
percentage of desired Distribution. Go to Step 3.
7. If the PRI level is not compliant, then binary search the number of VLANs, at the current level
until all PRI levels conform.
8. The number of VLANS is 4095^(Current level-1)+ Conformant VLANs.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
32
Variables & Relevance
Variable Relevance
Hosts per VLAN Number of Hosts per VLAN
Default: 256
Priority Distribution table Table of % of traffic assigned to each priority level in Table
1
Iteration Time Time per Iteration
Default: 300s
Desired Result
The DUT should be able to maintain CoS for up to 4095^9 VLANs as per table 1.
Key Measured Metrics
Statistic Relevance
Number of Q-in-Q Levels How many Customer VLANS is the DUT able to forward
Number of Current VLANS at the
Edge
Peak Services
Analysis
Document the number of fully conformant Q-in-Q Levels, and at the outer most level, How many
VLAN the DUT is able to forward while maintaining Priority. Because the DUT has to fort each
VLAN Type for Priority, this test will place maximum permutation strain on the forwarding
Engine.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
33
L23_009 Determine whether the DUT processes specific stream
sequences
Abstract
This test determines whether the DUT can handle specific stream sequences sent to it without
dropping packets and compromising QoS.
Description
Internet traffic is increasing by leaps and bounds and thousands of new applications are being
created every day. There is a wide variation in the type of data/streams passing through a DUT
and some sequences of streams might be catastrophic for the DUT.
This test case identifies those types of sequences and schedules them to be sent to the DUT
accordingly. We measure the output on the Rx port and verify that the DUT handles the
sequence, but also forwards all traffic without dropping frames or violating QoS parameters.
Target Users
Engineering, Product Verification, Manufacturing
Target Device Under Test (DUT)
Any DUT
Relevance
This test case allows the tester to verify the DUT performance under specific conditions.
Version
1.0
Test Category
Testing L2/L3 QoS
PASS
[x] Performance [ ] Availability [ ] Security [ ] Scale
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
34
Required Tester Capabilities
The tester needs to support
Basic traffic generating capabilities.
A scheduling mode that will allow the user to manually schedule the stream sequence
along with the ability to control the IFG, IBG etc.
Advanced traffic analyzing capability with sequencing counters that are compliant with
MEF 10.
Topology Diagram
Test Procedure
1. Identify a specific stream sequence which would cause the DUT to mis-handle the
packets, i.e. either drop them or have difficulty in processing them and consequently
violate QoS standards.
2. Create as many streams as required in the tester to build the sequence as identified in
Step 1.
3. Use the scheduling mode which allows the user to manually schedule the streams
defined in Step 2 one by one with a definable IFG and IBG.
4. Loop the sequence, if required, for as many times as required.
5. Start traffic.
6. Verify that the tester receives traffic on the Rx port.
7. Verify that there are no dropped, re-ordered, duplicate or late packets.
8. Stop traffic.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
35
Control Variables & Relevance
Variable Relevance Default Value
Number of
unique Streams
The number of unique streams that defines the
killer sequence for the DUT
At least 1 stream
IFG and IBG Determines the interval at which frames hit the
DUT to trigger the failure condition.
IFG = 12 bytes
IBG = 20 bytes
Key Measured Metrics
Metric Relevance Metric Unit
Rx Packets This count indicates whether the DUT is able to successfully
pass traffic with a defined sequence of streams. A count of zero
indicates a serious problem with the DUT’s ability to handle
such stream sequences.
Count per
stream
Dropped
Frame count
This count indicates whether the DUT drops frames due to its
inability to efficiently process incoming frames.
Count per
stream
Re-ordered
Count
This count indicates whether the DUT re-orders frames. A
frame is considered re-ordered if it arrives earlier at the RX port
than the frames transmitted before it.
Count per
stream
ToS In case of traffic loss, streams with a higher ToS value shouldn’t
show more drops than the lower ToS value traffic.
Value per
streams
Desired Result
The DUT should be able to handle any sequence of streams and with varying IFG and IBGs and
successfully pass traffic.
Analysis
The DUT should be able to handle any sequence of streams and with varying IFG and IBGs and
successfully pass traffic.
If the Rx tester port does not receive traffic, check the DUT to verify that it is dropping the entire
incoming packet and identify the root cause of the issue.
In cases where partial traffic loss occurs, verify that the higher ToS value traffic has zero or
minimal loss and that the loss count is less than the lower ToS value traffic.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
36
L23_010 Determine whether the DUT forwards a mix of jumbo and
traditional frame sizes
Abstract
This test case determines how well the DUT handles a mix of jumbo and normal frames sizes. The
test case mixes both traditional and jumbo frame sizes and verifies the ability of the DUT to
forward traffic. Without verification, the user will not know how the DUT handles a mix of frame
sizes.
Description
Internet traffic is increasing by leaps and bounds and thousands of new applications are being
created every day. The DUT receives jumbo and normal frame sizes consistently and
simultaneously. Usually, most DUTs have separate processing efficiencies for jumbo frames and
normal frame sizes.
A normal Ethernet frame size is defined as between 64 to 1518 (1522 with VLAN). Anything
above, 1518/1522 and up to 9018/9022 is considered a jumbo frame.
In this test case, test ports send a mix of jumbo and normal frames sizes to the DUT and receive
the output at the Rx port.
Target Users
Engineering, Product Verification, Manufacturing
Target Device Under Test (DUT)
Any DUT
Reference
IEEE 802.3
Relevance
This test case allows the tester to verify the DUT performance when a mix of jumbo and normal
frames sizes are received.
Version
1.0
Test Category
Testing L2/L3 QoS
PASS
[x] Performance [ ] Availability [ ] Security [ ] Scale
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
37
Required Tester Capabilities
The tester must support:
Basic traffic generating capabilities
Manual scheduling of streams that contain a mix of jumbo and normal size frames and
the ability to specify IFGs between these frames.
Advanced traffic analyzing capability with sequencing counters that are compliant with
MEF 10.
Topology Diagram
Test Procedure
1. Create Stream A with a frame size of 4000 bytes to generate jumbo frames.
2. Create Stream B with a frame size of 128 bytes to generate normal frames.
3. Select the scheduling mode that allows the user to manually schedule the streams defined in
Step 1 and 2.
4. Build the scheduler with the following sequence:
a. Add one entry, select stream A, set Burst Size = 1, IBG = 10%, Burst Count = 5.
b. Add 2nd entry, select stream B, set Burst Size = 1, IBG = 10%, Burst Count = 3.
c. Add 3rd entry, select stream A, set Burst Size = 1, IBG = 20%, Burst Count = 10.
d. Add 4th entry, select stream B, set Burst Size = 1, IBG = 20%, Burst Count = 6.
e. Add 5th entry, select stream A, set Burst Size = 1, IBG = 40%, Burst Count = 20.
f. Add 6th entry, select stream B, set Burst Size = 1, IBG = 40%, Burst Count = 12.
5. Start traffic.
6. Verify that traffic is received on the RX port
a. Note the latency of the packets arriving at the Rx port.
b. Note the advanced sequencing counters like dropped frame, re-ordered frames,
duplicate and late frames.
7. Change the frame sizes for both Stream A and B (within the Ethernet limits of jumbo and
normal frame sizes) and repeat Steps 3 to 6.
8. Optionally, change the IBG, burst sizes and burst count for one or more entries in Step 4 and
observe the effects on the Rx ports.
9. End test.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
38
Control Variables & Relevance
Variable Relevance Default Value
Frame Sizes To analyzer DUT performance when a mix of
Jumbo and normal frame sizes are present.
Jumbo Frame = 4000 bytes
Normal Frame = 128 bytes
IBG Determines the interval at which frames arrive at
the DUT.
IBG = 20 bytes
Burst Count Number of bursts sent to the DUT for a particular
stream.
Burst Count = 5
Burst Size Number of frames per burst. Burst size = 1
Key Measured Metrics
Metric Relevance Metric Unit
Rx Packets Indicates whether the DUT is able to successfully pass traffic
with a defined sequence of streams. A count of zero indicates a
serious problem with the DUTs ability to handle a mix of jumbo
and normal size packets
Count per
stream
Dropped
Frame count
Indicates whether the DUT drops frames due to its inability to
efficiently process incoming frames.
Count per
stream
Re-ordered
Count
Indicates whether the DUT re-orders frames. A frame is
considered re-ordered if it arrives earlier at the RX port than
frames that were transmitted before it.
Count per
stream
Late Frames Indicates whether the DUT holds onto a packet/frame in the
buffer for an extended period of time while processing the
frames that came after it.
Count per
stream
Latency Minimum, maximum and average latency values indicate
whether the DUT prefers one type of traffic over the other.
Latency histograms provide an accurate picture of how the DUT
processes the frames.
Value per
stream in
microseconds
Desired Result
The DUT should be able to handle the mix of jumbo and normal frame sizes together without
dropping packets or significantly increasing the latency of either of the packet sizes.
Analysis
The DUT should be able to handle the mix of jumbo and normal frame sizes together without
dropping packets or significantly increasing the latency of either of the packet sizes.
The DUT shouldn’t favor one type of the traffic to another.
If abnormalities are observed in the results, such asexcessive latency variation between jumbo
and normal size packets or re-ordered or late frame counts going up consistently, check the DUTs
processing algorithm and buffer allocations.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
39
L23_011 Determine DHCPv4/v6 lease acquisition time under
scale
Abstract
DHCPv4 is a widely used access protocol that acquires network addresses for client devices. This
test measures the quality of experience of DHCPv4 and DHCPv6 per device as the request rate
increases. Understanding DHCP Quality of Experience allows the correct deployment and scale of
DHCP servers in the network and ensures predictability of experience even under load.
Description
Dynamic Host Configuration Protocol (DHCP), is a protocol for assigning dynamic IP addresses to
devices on a network. With dynamic addressing, a device can have a different IP address every
time it connects to the network. In some systems, the device's IP address can even change while
it is still connected. DHCP also supports a mix of static and dynamic IP addresses. Dynamic
addressing simplifies network administration because the software keeps track of IP addresses
rather than requiring an administrator to manage the task. This means that a new computer can
be added to a network without the hassle of manually assigning it a unique IP address. Quality of
Experience for DHCP is defined as the latency between sending a DHCPv4/v6 lease request and
the server response. This test measures the impact of scale on a DHCP server.
Target Users
Product verification, Engineering, Service Providers, Enterprise
Target Device Under Test (DUT)
DHCP Server supporting DHCPv4 and/or DHCPv6
Reference
RFC 2131 - Dynamic Host Configuration Protocol for IPv4
RFC 3319 – Dynamic Host Configuration Protocol for IPv6
Relevance
Understanding the lease acquisition time is a critical component to evaluating the user
experience. Since by definition DHCP is one of the first protocols the user experiences on the
network, the quality of experience in acquiring an address may play a significant role in the user
perception of overall network quality and predictability.
Version
1.0
Test Category
L23
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
40
PASS
[ ] Performance [ ] Availability [ ] Security [x] Scale
Required Tester Capabilities
The tester must be able to generate and measure stateful DHCPv4/v6 lease requests, including
the acquisition time, and to burst requests live into the DHCP server without stopping requests.
Topology Diagram
Test Procedure
1. Reserve the client test port and bring the link up. Determine whether the test will involve
DHCPv4 and/or DHCPv6.
2. For each of the desired protocols, configure the lease rates per second, the duration time
per lease rate and the number of trials per rate.
3. For each of the DHCPv4 and DHCPv6 rates:
a. Setup appropriate DHCPv4 and DHCPv6 device pools.
b. Set the correct rate for DHCPv4 and DHCPv6.
c. Set the burst to the desired duration.
d. Transmit DHCPv4 and/or DHCPv6 lease requests.
e. Measure the maximum lease time.
f. Repeat for the number of trials desired.
4. End.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
41
Control Variables & Relevance
Variable Relevance Default Value
DHCP Versions Versions of DHCP to test DHCPv4
List of Lease rates Rates to test per Second 1,10,100,1000,5000,10000
Iteration Duration Duration of each rate 10 Seconds
Trials Number of trials per Rate 3
Key Measured Metrics
Metric Relevance Metric Unit
DHCPv4 Lease Acquire Time Time for Server Response mSec
DHCPv6 Lease Acquire Time Time for Server Response mSec
Desired Result
Using a baseline of 1 lease request per second, the maximum lease time for subsequent rates
should be no slower than 1% of the baseline across rates and trials.
Analysis
The lease time for 1 DHCP request is the baseline. It should be 1-2 mSec maximum. Each of the
subsequent requests should be no slower than 1% of the baseline across trials and rates.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
42
L23_012 Determine the minimum time between sequence
errors with microbursts
Abstract
The modern Device Under Test (DUT) is expected to transmit traffic for long durations with no
sequencing errors. These errors include lost, out-of-sequence, late, duplicate, and re-ordered
packets. This test measure the duration between sequencing errors in microburst conditions.
This test allows the user to determine the predictability of properly sequenced traffic under burst
conditions.
Description
A microburst is a sudden and intense increase of pressure for a short duration on a DUT switch
fabric, queues, interfaces, and software systems. Traffic is instantaneously multiplied across
multiple attributes simultaneously. These attributes can include bandwidth, address density, and
frame size distribution. The DUT is forced to simultaneously forward existing traffic while adding
table entries for new address and forwarding new traffic flows. A DUT is said to pass when it is
able to keep traffic policies coherent during and after the microburst event. This test sends
microbursts across the DUT for longer than 24 hours. (Greater than 96 hours recommended.) A
run sequence length histogram is setup on the receive side with bucket widths of 1000 packets.
The result is a distribution run sequence length across the DUT.
Target Users
PV, Engineering, and End users
Target Device Under Test (DUT)
Any Layer 2 or Layer 3 Switch
Reference
IEEE 802
Relevance
Understanding the forwarding latency characteristics of the Device Under Test (DUT) over an
extended sample will give the user incite in the predictability of the Device Under Test (DUT)
performance.
Version
1.0
Test Category
L23
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
43
PASS
[ ] Performance [x] Availability [ ] Security [ ] Scale
Required Tester Capabilities
The tester must have the ability to produce a run sequence length histogram and change test
traffic conditions dynamically. The tester must also have the ability to measure latency in a
histogram with at least 16 buckets.
Topology Diagram
Test Procedure
1. Reserve the desired number of test ports and bring the links up.
2. Determine whether the test is a L2 only, L3-IPv4, or L3-IPv6, or L3-IPv4/IPv6 Mix.
3. On all test ports, program run sequence length histograms per stream. Start the first bucket
at 0 packets and make the bucket width 1000 packets. The last bucket should be the
catchall.
4. Setup and start background traffic.
a. Take the first 50% of addresses of L2 and, if desired, L3. (If L3 mixed, allocate 25% to
IPv4 and 25% to IPv6.) Setup host blocks evenly distributed across all test ports.
b. Setup full-mesh traffic with a standard iMIX pattern. Evenly divide all traffic across 70%
of load.
c. Start background traffic. Keep traffic running through the entire test.
5. Loop until the end of the test.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
44
a. Setup a microburst at 30% of load. Set one unique address per packet. Setup the desired
length of the burst. Perform this on all test ports.
b. Burst traffic to the DUT.
c. Move to the next block of addresses. Loop back to the first if the remaining addresses
are used.
d. End loop.
6. At the end of the test duration, stop all traffic. Measure the run sequence length histogram
on all ports.
Control Variables & Relevance
Variable Relevance Default Value
Duration Length of the test in Days 1 Day
Burst Duration Length of a burst 10,000 Packets
Peak number of MAC addresses Upper limits of the DUT 16 Million
Peak number of IPv4 Addresses Upper limits of the DUT 4.3 Billion
Peak number of IPv6 Addresses Upper limits of the DUT 4.3 Billion
Key Measured Metrics
Metric Relevance Metric Unit
Run Sequence Length Histogram Number of packets between errors Packets
Desired Result
The run sequence length should have all packets in the catchall bucket X<=OO.
Analysis
Look at the histograms per port. In a perfect case, the run sequence length should have all the
packets in the catchall. This means that the length between errors was the same as the
transmitted packet count. Report each histogram per port noting histograms that have non-
catchall packets greater than zero.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
45
L23_013 Evaluate ultra-Low latency stability with microbursts
Abstract
The modern Device Under Test (DUT) should have the ability to forward store-and-forward
traffic with a port-to-port latency of less than 1000 nSec (ultra-low latency) under burst
conditions. This test case sends microbursts of traffic to the DUT and measures the distribution
of latency forwarded for an extended duration of time. The ability to characterize the distribution
of latency over an extended period of time is critical in understanding the switch fabric
characteristics of the DUT.
Description
A microburst is a sudden and intense increase of pressure for a short duration on a DUT switch
fabric, queues, interfaces, and software systems. Traffic is instantaneously multiplied across
multiple attributes simultaneously. These attributes can include bandwidth, address density, and
frame size distribution. The DUT is forced to simultaneously forward existing traffic while adding
table entries for new address and forwarding new traffic flows. A DUT is said to pass when it is
able to keep traffic policies coherent during and after the microburst event. This test sends
microbursts across the DUT for longer than 24 hours. (Longer than 96 hours recommended.) A
latency histogram is setup on the receive side with bucket widths of 50 nSec. The result is a
distribution of forwarded latency across the DUT.
Target Users
PV, Engineering, and End users
Target Device Under Test (DUT)
Any Layer 2 or Layer 3 Switch
Reference
IEEE 802
Relevance
Understanding the forwarding latency characteristics of the DUT over an extended sample will
give the user insight in the predictability of the DUT performance.
Version
1.0
Test Category
L23
PASS
[ ] Performance [x] Availability [ ] Security [ ] Scale
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
46
Required Tester Capabilities
The tester must have the ability to measure ultralow latency accurately without adding
compensation to skew the results. The tester must also have the ability to measure latency in a
histogram with at least 16 buckets.
Topology Diagram
Test Procedure
1. Reserve the desire number of test ports and bring the links up.
2. Determine whether the test is L2 only, L3-IPv4, L3-IPv6, or L3-IPv4/IPv6 Mix.
3. On all test ports, turn off latency compensation. Program latency histogram per stream.
Start the first bucket at 0 nSec of latency and make the width of each bucket 50 nSec.
4. Setup and start background traffic.
a. Take the first 50% of addresses of L2 and, if desired, L3. (If L3 mixed, allocate 25% to
IPv4 and 25% to IPv6.) Setup host blocks evenly distributed across all test ports.
b. Setup full mesh traffic with a standard iMIX pattern. Evenly divide all traffic across 70%
of load.
c. Start background traffic. Keep traffic running through the entire test.
5. Loop until the end of the test.
a. Setup a microburst at 30% of load. Set one unique address per packet. Setup the desired
length of the burst. Perform this on all test ports.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
47
b. Burst traffic to the DUT.
c. Move to the next block of addresses. Loop back to the first if the remaining addresses
are used.
d. End Loop.
6. At the end of the test duration, stop all traffic. Measure the latency histogram on all ports.
Control Variables & Relevance
Variable Relevance Default Value
Duration Length of the test in Days 1 Day
Burst Duration Length of a burst 10,000 Packets
Peak number of MAC addresses Upper limits of the DUT 16 Million
Peak number of IPv4 Addresses Upper limits of the DUT 4.3 Billion
Peak number of IPv6 Addresses Upper limits of the DUT 4.3 Billion
Key Measured Metrics
Matric Relevance Metric Unit
Latency Histogram How Latency is Distributed nSec
Desired Result
The latency histograms should be very similar to each other. In addition the latencies should
have a very small variance.
Analysis
Look at the histograms per port and compare them. If you see variations, look at the properties
that are different in the DUT fabric from port to port. Look at the median latency and variance.
You should see only a few histogram buckets filled. Wide variances mean that the DUT does not
have predictable latency profiles.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
48
Appendix A – Telecommunications
Definitions
APPLICATION LOGIC. The computational aspects of an application, including a list of instructions that tells a
software application how to operate.
APPLICATION SERVICE PROVIDER (ASP). An ASP deploys hosts and manages access to a packaged application by
multiple parties from a centrally managed facility. The applications are delivered over networks on a
subscription basis. This delivery model speeds implementation, minimizes the expenses and risks incurred
across the application life cycle, and overcomes the chronic shortage of qualified technical personnel
available in-house.
APPLICATION MAINTENANCE OUTSOURCING PROVIDER. Manages a proprietary or packaged application from
either the customer's or the provider's site.
ASP INFRASTRUCTURE PROVIDER (AIP). A hosting provider that offers a full set of infrastructure services for
hosting online applications.
ATM. Asynchronous Transport Mode. An information transfer standard for routing high-speed, high-
bandwidth traffic such as real-time voice and video, as well as general data bits.
AVAILABILITY. The portion of time that a system can be used for productive work, expressed as a
percentage.
BACKBONE. A centralized high-speed network that interconnects smaller, independent networks.
BANDWIDTH. The number of bits of information that can move through a communications medium in a
given amount of time; the capacity of a telecommunications circuit/network to carry voice, data, and
video information. Typically measured in Kbps and Mbps. Bandwidth from public networks is typically
available to business and residential end-users in increments from 56 Kbps to 45 Mbps.
BIT ERROR RATE. The number of transmitted bits expected to be corrupted per second when two computers
have been communicating for a given length of time.
BURST INFORMATION RATE (BIR). The rate of information in bits per second that the customer may need over
and above the CIR. A burst is typically a short duration transmission that can relieve momentary
congestion in the LAN or provide additional throughput for interactive data applications.
BUSINESS ASP. Provides prepackaged application services in volume to the general business market,
typically targeting small to medium size enterprises.
BUSINESS-CRITICAL APPLICATION. The vital software needed to run a business, whether custom-written or
commercially packaged, such as accounting/finance, ERP, manufacturing, human resources and sales
databases.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
49
BUSINESS SERVICE PROVIDER. Provides online services aided by brick-and-mortar resources, such as payroll
processing and employee benefits administration, printing, distribution or maintenance services. The
category includes business process outsourcing (BPO) companies.
COMMERCE NETWORK PROVIDER. Commerce networks were traditionally proprietary value-added networks
(VANs) used for electronic data interchange (EDI) between companies. Today the category includes the
new generation of electronic purchasing and trading networks.
COMPETITIVE ACCESS PROVIDER (CAP). A telecommunications company that provides an alternative to a LEC
for local transport and special access telecommunications services.
CAPACITY. The ability for a network to provide sufficient transmitting capabilities among its available
transmission media, and respond to customer demand for communications transport, especially at peak
usage times.
CLIENT/DEVICE. Hardware that retrieves information from a server.
CLUSTERING. A group of independent systems working together as a single system. Clustering technology
allows groups of servers to access a single disk array containing applications and data.
COMPUTING UTILITY PROVIDER (CUP). A provider that delivers computing resources, such as storage, database
or systems management, on a pay-as-you-go basis.
CSU/DSU. Channel Server Unit/Digital Server Unit. A device used to terminate a telephone company
connection and prepare data for a router interface.
DATA MART. A subset of a data warehouse, intended for use by a single department or function.
DATA WAREHOUSE. A database containing copious amounts of information, organized to aid decision-
making in an organization. Data warehouses receive batch updates and are configured for fast online
queries to produce succinct summaries of data.
DEDICATED LINE. A point-to-point, hardwired connection between two service locations.
DEMARCATION LINE. The point at which the local operating company's responsibility for the local loop ends.
Beyond the demarcation point (also known as the network interface), the customer is responsible for
installing and maintaining all equipment and wiring.
DISCARD ELIGIBILITY (DE) BIT. Relevant in situations of high congestion, it indicates that the frame should be
discarded in preference to frames without the DE bit set. The DE bit may be set by the network or by the
user; and once set cannot be reset by the network.
DS-1 OR T-1. A data communication circuit capable of transmitting data at 1.5 Mbps. Currently in
widespread use by medium and large businesses for video, voice, and data applications.
DS-3 OR T-3. A data communications circuit capable of transmitting data at 45 Mbps. The equivalent data
capacity of 28 T-1s. Currently used only by businesses/institutions and carriers for high-end applications.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
50
ELECTRONIC DATA INTERCHANGE (EDI). The electronic communication of business transactions (orders,
confirmations, invoices etc.) of organizations with differing platforms. Third parties provide EDI services
that enable the connection of organizations with incompatible equipment.
ENTERPRISE ASP. An ASP that delivers a select range of high-end business applications, supported by a
significant degree of custom configuration and service.
ENTERPRISE RELATIONSHIP MANAGEMENT (ERM). Solutions that enable the enterprise to share comprehensive,
up-to-date customer, product, competitor and market information to achieve long-term customer
satisfaction, increased revenues, and higher profitability.
ENTERPRISE RESOURCE PLANNING (ERP). An information system or process integrating all manufacturing and
related applications for an entire enterprise. ERP systems permit organizations to manage resources
across the enterprise and completely integrate manufacturing systems.
ETHERNET. A local area network used to connect computers, printers, workstations, and other devices
within the same building. Ethernet operates over twisted wire and coaxial cable.
EXTENDED SUPERFRAME FORMAT. A T1 format that provides a method for easily retrieving diagnostics
information.
FAT CLIENT. A computer that includes an operating system, RAM, ROM, a powerful processor and a wide
range of installed applications that can execute either on the desktop or on the server to which it is
connected. Fat clients can operate in a server-based computing environment or in a stand-alone fashion.
FAULT TOLERANCE. A design method that incorporates redundant system elements to ensure continued
systems operation in the event of the failure of any individual element.
FDDI. Fiber Distributed Data Interface. A standard for transmitting data on optical-fiber cables at a rate of
about 100 Mbps.
FRAME. The basic logical unit in which bit-oriented data is transmitted. The frame consists of the data bits
surrounded by a flag at each end that indicates the beginning and end of the frame. A primary rate can be
thought of as an endless sequence of frames.
FRAME RELAY. A high-speed packet switching protocol popular in networks, including WANs, LANs, and
LAN-to-LAN connections across long distances.
GBPS. Gigabits per second, a measurement of data transmission speed expressed in billions of bits per
second.
HOSTED OUTSOURCING. Complete outsourcing of a company's information technology applications and
associated hardware systems to an ASP.
HOSTING PROVIDER. Provider who operates data center facilities for general-purpose server hosting and
collocation.
INFRASTRUCTURE ISV. And independent software vendor that develops infrastructure software to support
the hosting and online delivery of applications.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
51
INTEGRATED SERVICES DIGITAL NETWORK (ISDN). An information transfer standard for transmitting digital voice
and data over telephone lines at speeds up to 128 Kbps.
INTEGRATION. Equipment, systems, or subsystem integration, assembling equipment or networks with a
specific function or task. Integration is combining equipment/systems with a common objective, easy
monitoring and/or executing commands. It takes three disciplines to execute integration: 1) hardware, 2)
software, and 3) connectivity – transmission media (data link layer), interfacing components. All three
aspects of integration have to be understood to make two or more pieces of equipment or subsystems
support the common objective.
INTER-EXCHANGE CARRIER (IXC). A telecommunications company that provides telecommunication services
between local exchanges on an interstate or intrastate basis.
INTERNET SERVICE PROVIDER (ISP). A company that provides access to the Internet for users and businesses.
INDEPENDENT SOFTWARE VENDOR (ISV). A company that is not a part of a computer systems manufacturer
that develops software applications.
INTERNETWORKING. Sharing data and resources from one network to another.
IT SERVICE PROVIDER. Traditional IT services businesses, including IT outsourcers, systems integrators, IT
consultancies and value added resellers.
KILOBITS PER SECOND (KBPS). A data transmission rate of 1,000 bits per second.
LEASED LINE. A telecommunications line dedicated to a particular customer along predetermined routers.
LOCAL ACCESS TRANSPORT AREA (LATA). One of approximately 164 geographical areas within which local
operating companies connect all local calls and route all long-distance calls to the customer's inter-
exchange carrier.
LOCAL EXCHANGE CARRIER (LEC). A telecommunications company that provides telecommunication services
in a defined geographic area.
LOCAL LOOP. The wires that connect an individual subscriber's telephone or data connection to the
telephone company central office or other local terminating point.
LOCAL/REGIONAL ASP. A company that delivers a range of application services, and often the complete
computing needs, of smaller businesses in their local geographic area.
MEGABITS PER SECOND (MBPS). 1,024 kilobits per second.
METAFRAME. The world's first server-based computing software for Microsoft Windows NT 4.0 Server,
Terminal Server Edition multi-user software (co-developed by Citrix).
MODEM. A device for converting digital signals to analog and vice versa, for data transmission over an
analog telephone line.
MULTIPLEXING. The combining of multiple data channels onto a single transmission medium. Sharing a
circuit - normally dedicated to a single user - between multiple users.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
52
MULTI-USER. The ability for multiple concurrent users to log on and run applications on a single server.
NET-BASED ISV. An ISV whose main business is developing software for Internet-based application services.
This includes vendors who deliver their own applications online, either directly to users or via other
service providers.
NETWORK ACCESS POINT (NAP). A location where ISPs exchange traffic.
NETWORK COMPUTER (NC). A thin-client hardware device that executes applications locally by downloading
them from the network. NCs adhere to a specification jointly developed by Sun, IBM, Oracle, Apple and
Netscape. They typically run Java applets within a Java browser, or Java applications within the Java
Virtual Machine.
NETWORK COMPUTING ARCHITECTURE. A computing architecture in which components are dynamically
downloaded from the network onto the client device for execution by the client. The Java programming
language is at the core of network computing.
ONLINE ANALYTICAL PROCESSING (OLAP). Software that enables decision support via rapid queries to large
databases that store corporate data in multidimensional hierarchies and views.
OPERATIONAL RESOURCE PROVIDER. Operational resources are external business services that an ASP might
use as part of its own infrastructure, such as helpdesk, technical support, financing, or billing and payment
collection.
OUTSOURCING. The transfer of components or large segments of an organization's internal IT infrastructure,
staff, processes or applications to an external resource such as an ASP.
PACKAGED SOFTWARE APPLICATION. A computer program developed for sale to consumers or businesses,
generally designed to appeal to more than a single customer. While some tailoring of the program may be
possible, it is not intended to be custom-designed for each user or organization.
PACKET. A bundle of data organized for transmission, containing control information (destination, length,
origin, etc.), the data itself, and error detection and correction bits.
PACKET SWITCHING. A network in which messages are transmitted as packets over any available route rather
than as sequential messages over circuit-switched or dedicated facilities.
PEERING. The commercial practice under which nationwide ISPs exchange traffic without the payment of
settlement charges.
PERFORMANCE. A major factor in determining the overall productivity of a system, performance is primarily
tied to availability, throughput and response time.
PERMANENT VIRTUAL CIRCUIT (PVC). A PVC connects the customer's port connections, nodes, locations, and
branches. All customer ports can be connected, resembling a mesh, but PVCs usually run between the
host and branch locations.
POINT OF PRESENCE (POP). A telecommunications facility through which the company provides local
connectivity to its customers.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
53
PORTAL. A company whose primary business is operating a Web destination site, hosting content and
applications for access via the Web.
REMOTE ACCESS. Connection of a remote computing device via communications lines such as ordinary
phone lines or wide area networks to access distant network applications and information.
REMOTE PRESENTATION SERVICES PROTOCOL. A set of rules and procedures for exchanging data between
computers on a network, enabling the user interface, keystrokes, and mouse movements to be
transferred between a server and client.
RESELLER/VAR. An intermediary between software and hardware producers and end users. Resellers
frequently add value (thus Value-Added Reseller) by performing consulting, system integration and
product enhancement.
ROUTER. A communications device between networks that determines the best path for optimal
performance. Routers are used in complex networks of networks such as enterprise-wide networks and
the Internet.
SCALABILITY. The ability to expand the number of users or increase the capabilities of a computing solution
without making major changes to the systems or application software.
SERVER. The computer on a local area network that often acts as a data and application repository and that
controls an application's access to workstations, printers and other parts of the network.
SERVER-BASED COMPUTING. A server-based approach to delivering business-critical applications to end-user
devices, whereby an application's logic executes on the server and only the user interface is transmitted
across a network to the client. Benefits include single-point management, universal application access,
bandwidth-independent performance, and improved security for business applications.
SINGLE-POINT CONTROL. One of the benefits of the ASP model, single-point control helps reduce the total
cost of application ownership by enabling widely used applications and data to be deployed, managed
and supported at one location. Single-point control enables application installations, updates and
additions to be made once, on the server, which are then instantly available to users anywhere.
SPECIALIST ASP. Provide applications which serve a specific professional or business activity, such as
customer relationship management, human resources or Web site services.
SYSTEMS MANUFACTURER. Manufacturer of servers, networking and client devices.
TELECOMS PROVIDER. Traditional and new-age telecommunications network providers (telcos).
THIN CLIENT. A low-cost computing device that accesses applications and and/or data from a central server
over a network. Categories of thin clients include Windows-Based Terminals (WBT, which comprise the
largest segment), X-Terminals, and Network Computers (NC).
TOTAL COST OF OWNERSHIP (TCO). Model that helps IT professionals understand and manage the budgeted
(direct) and unbudgeted (indirect) costs incurred for acquiring, maintaining and using an application or a
computing system. TCO normally includes training, upgrades, and administration as well as the purchase
price. Lowering TCO through single-point control is a key benefit of server-based computing.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
54
TOTAL SECURITY ARCHITECTURE (TSA). A comprehensive, end-to-end architecture that protects the network.
TRANSMISSION CONTROL PROTOCOL/INTERNET PROTOCOL (TCP/IP). A suite of network protocols that allow
computers with different architectures and operating system software to communicate over the Internet.
USER INTERFACE. The part of an application that the end user sees on the screen and works with to operate
the application, such as menus, forms and buttons.
VERTICAL MARKET ASP. Provides solutions tailored to the needs of a specific industry, such as the healthcare
industry.
VIRTUAL PRIVATE NETWORK (VPN). A secure, encrypted private connection across a cloud network, such as
the Internet.
WEB HOSTING. Placing a consumer's or organization's web page or web site on a server that can be
accessed via the Internet.
WIDE AREA NETWORK. Local area networks linked together across a large geographic area.
WINDOWS-BASED TERMINAL (WBT). Thin clients with the lowest cost of ownership, as there are no local
applications running on the device. Standards are based on Microsoft's WBT specification developed in
conjunction with Wyse Technology, NCD, and other thin client companies.
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
55
Appendix B – Layer 2 802.1q CoS
The following tables represent best practices for Layer 2 VLAN / Q-in-Q CoS. Each row relates the
appropriate metric to measured minimum acceptable for its respective traffic class.
VLAN 802.1p CoS / Q-in-Q Priority
802.1 PRI
CoS
Min. RX / TX
Bandwidth
Ratio
Max
Jitter
(uSec)
Max
Latency
(uSec)
Max
Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max
Late
(Frames)
7 1 0 >=1 0 0 0 0
6 1 0 2 0 0 0 0
5 .99 1 2 0 0 0 0
4 .98 1 3 0 0 0 0
3 .95 2 5 0 1 1 1
2 .90 3 5 1 1 1 1
1 .85 5 10 1 2 2 2
0 ANY ANY ANY ANY ANY ANY ANY
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
56
Appendix C – RFC 2474 Layer 3 QoS
The following tables represent best practices for Layer 2 VLAN / Q-in-Q CoS. Each row relates the
appropriate metric to measured minimum acceptable for its respective traffic class.
IPv4 / IPv6 DiffServ
Codepoint Max Jitter
(uSec)
Max
Latency
(uSec)
Max Loss
(Frames)
Max
Duplicate
(Frames)
Max
Reordered
(Frames)
Max Late
(Frames)
EF 0 >=1 0 0 0 0
AF31 0 2 0 0 0 0
AF21 2 5 0 1 1 1
AF11 3 5 1 1 1 1
BE ANY ANY ANY ANY ANY ANY
Spirent Journal of Layer 2/3 QoS Test Methodologies | © Spirent Communications 2011
57
Appendix D – RFC 2474 Layer 3 QoS
Definitions
The following table represents the definitions of each DiffServ Codepoint possibility.
DSCP Value DF Code
Point
Equivalent IP
Precedent
Description
000 000 00 BE 000 - Routine Best Effort, Unclassified Quality
001 010 10 AF11 001 - Priority High-Throughput Transactions with high loss
sensitivity
001 100 12 AF12 001 - Priority High-Throughput Transactions with some loss
sensitivity
001 110 14 AF13 001 - Priority High-Throughput Transactions with loss
resiliency
001 010 18 AF21 001 - Immediate Low-Latency Transactions with high loss
sensitivity
010 100 20 AF22 001 - Immediate Low-Latency Transactions with some loss
sensitivity
010 119 22 AF23 001 - Immediate Low-Latency Transaction with loss resiliency
011 010 26 AF31 011 - Flash Broadcast Media with high loss sensitivity
011 110 28 AF32 011 - Flash Broadcast Media with some loss sensitivity
011 110 30 AF33 001 - Flash Broadcast Media with loss resiliency
100 010 34 AF41 100 – Flash Override Live Media with high loss sensitivity
100 110 36 AF42 100 – Flash Override Live Media with some loss sensitivity
100 110 38 AF43 100 – Flash Override Live Media with loss resiliency
101 110 46 EF 101 – Critical Mission Critical Transactions or VoIP
