Network Working Group J. H. Dunn
INTERNET-DRAFT C. E. Martin
Expires: January, 2001 ANC, Inc.
July, 2000
Methodology for ATM Benchmarking
<draft-ietf-bmwg-atm-method-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document discusses and defines a number of tests that may be used
to describe the performance characteristics of ATM based switching
devices. In addition to defining the tests this document also describes
specific formats for reporting the results of the tests.
Appendix A lists the tests and conditions that we believe should be
included for specific cases and gives additional information about
testing practices.
Dunn & Martin [Page 1]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
This memo is a product of the Benchmarking Methodology Working Group
(BMWG) of the Internet Engineering Task Force (IETF).
1. Introduction.
This document defines a specific set of tests that vendors can use to
measure and report the performance characteristics of ATM network
devices. The results of these tests will provide the user comparable
data from different vendors with which to evaluate these devices. The
methods defined in this memo are based on RFC 2544 "Benchmarking
Methodology for Network Interconnect Devices".
The document "Terminology for ATM Benchmarking" (RFC 2761), defines many
of the terms that are used in this document. The terminology document
should be consulted before attempting to make use of this document.
The BMWG produces two major classes of documents: Benchmarking
Terminology documents and Benchmarking Methodology documents. The
Terminology documents present the benchmarks and other related terms.
The Methodology documents define the procedures required to collect the
benchmarks cited in the corresponding Terminology documents.
2. Background
2.1. Test Device Requirements
This document is based on the requirement that a test device is
available. The test device can either be off the shelf or can be easily
built with current technologies. The test device must have a
transmitting and receiving port for the interface type under test. The
test device must be configured to transmit test PDUs and to analyze
received PDUs. The test device should be able to transmit and analyze
received data at the same time.
2.2. Systems Under Test (SUTs)
There are a number of tests described in this document that do not apply
to each SUT. Vendors should perform all of the tests that can be
supported by a specific product type. It will take some time to perform
all of the recommended tests under all of the recommended conditions.
Appendix A lists some of the tests and conditions that we believe should
be included for specific cases.
Dunn & Martin [Page 2]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
2.3. Test Result Evaluation
Performing all of the tests in this document will result in a great deal
of data. The applicability of this data to the evaluation of a
particular SUT will depend on its expected use and the configuration of
the network in which it will be used. For example, the time required by
a switch to provide ILMI services will not be a pertinent measurement in
a network that does not use the ILMI protocol, such as an ATM WAN.
Evaluating data relevant to a particular network installation may
require considerable experience, which may not be readily available.
Finally, test selection and evaluation of test results must be done with
an understanding of generally accepted testing practices regarding
repeatability, variance and the statistical significance of a small
numbers of trials.
2.4. Requirements
In this document, the words that are used to define the significance of
each particular requirement are capitalized. These words are:
* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the
item is an absolute requirement of the specification.
* "SHOULD" This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore this item, but
the full implications should be understood and the case carefully
weighed before choosing a different course.
* "MAY" This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because it enhances the product,
for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more of
the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all the
SHOULD requirements for its protocols is said to be "conditionally
compliant".
2.5. Test Configurations for SONET
Dunn & Martin [Page 3]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The test device can be connected to the SUT in a variety of
configurations depending on the test point. The following
configurations will be used for the tests described in this document.
1) Uni-directional connection: The test devices transmit port (labeled
Tx) is connected to the SUT receive port (labeled Rx). The SUTs
transmit port is connected to the test device receive port (see Figure
1). In this configuration, the test device can verify that all
transmitted packets are acknowledged correctly. Note that this
configuration does not verify internal system functions, but verifies
one port on the SUT.
+-------------+ +-------------+
| Tx|-------------->|Rx |
| Test Rx|<--------------|Tx SUT |
| Device | | |
+-------------+ +-------------+
Figure 1
2) Bi-directional connection: The test devices first transmit port is
connected to the SUTs first receive port. The SUTs first transmit port
is connected to the test devices first receive port. The test devices
second transmit port is connected to the SUTs second receive port. The
SUTs second transmit port is connected to the test devices second
receive port (see Figure 2). In this configuration, the test device can
determine if all of the transmitted packets were received and forwarded
correctly. Note that this configuration does verify internal system
functions, since it verifies two ports on the SUT.
+-------------+ +-------------+
| Test Tx|-------------->|Rx |
| Device Rx|<--------------|Tx SUT |
| Tx Rx | | Tx Rx |
+-------------+ +-------------+
| ^ | ^
| | | |
| +------------------------+ |
Dunn & Martin [Page 4]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
| |
|---------------------------------|
Figure 2
2) Uni-directional passthrough connection: The test devices first
transmit port is connected to the SUT1 receive port. The SUT1 transmit
port is connected to the test devices first receive port. The test
devices second transmit port is connected to the SUT2 receive port. The
SUT2 transmit port is connected to the test devices second receive port
(see Figure 3). In this configuration, the test device can determine if
all of the packets transmitted by SUT1 were correctly acknowledged by
SUT2. Note that this configuration does not verify internal system
functions, but verifies one port on each SUT.
+-------------+ +-------------+ +-------------+
| Tx|---------->|Rx Tx|---------->|Rx |
| SUT1 Rx|<----------|Tx Test Rx|<----------|Tx SUT2 |
| | | Device | | |
+-------------+ +-------------+ +-------------+
Figure 3
2.5. SUT Configuration
The SUT MUST be configured as described in the SUT users guide.
Specifically, it is expected that all of the supported protocols will be
configured and enabled (See Appendix A). It is expected that all of the
tests will be run without changing the configuration or setup of the SUT
in any way other than that required to do the specific test. For
example, it is not acceptable to disable all but one transport protocol
when testing the throughput of that protocol. If PNNI or BISUP is used
to initiate switched virtual connections (SVCs), the SUT configuration
SHOULD include the normally recommended routing update intervals and
keep alive frequency. The specific version of the software and the
exact SUT configuration, including what functions are disabled and used
during the tests MUST be included as part of the report of the results.
2.6. Frame formats
The formats of the test IP PDUs to use for TCP/IP over ATM are shown in
Appendix C: Test Frame Formats. Note that these IP PDUs are in
Dunn & Martin [Page 5]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
accordance with RFC 2225. These exact IP PDU formats SHOULD be used in
the tests described in this document for this protocol/media
combination. These IP PDUs will be used as a template for testing other
protocol/media combinations. The specific formats that are used to
define the test IP PDUs for a particular test series MUST be included in
the report of the results.
2.7. Frame sizes
All of the described tests SHOULD be performed using a number of IP PDU
sizes. Specifically, the sizes SHOULD include the maximum and minimum
legitimate sizes for the protocol under test on the media under test and
enough sizes in between to be able to get a full characterization of the
SUT performance. Except where noted, at least five IP PDU sizes SHOULD
be tested for each test condition.
Theoretically the minimum size UDP Echo request IP PDU would consist of
an IP header (minimum length 20 octets), a UDP header (8 octets), AAL5
trailer (8 octets) and an LLC/SNAP code point header(8 octets);
therefore, the minimum size PDU will fit into one ATM cell. The
theoretical maximum IP PDU size is determined by the size of the length
field in the IP header. In almost all cases the actual maximum and
minimum sizes are determined by the limitations of the media. In the
case of ATM, the maximum IP PDU size SHOULD be the ATM MTU size, which
is 9180 octets.
In theory it would be ideal to distribute the IP PDU sizes in a way that
would evenly distribute the theoretical IP PDU rates. These
recommendations incorporate this theory but specify IP PDU sizes, which
are easy to understand and remember. In addition, many of the same IP
PDU sizes are specified on each of the media types to allow for easy
performance comparisons.
Note: The inclusion of an unrealistically small IP PDU size on some of
the media types (i.e. with little or no space for data) is to help
characterize the per-IP PDU processing overhead of the SUT.
The IP PDU sizes that will be used are:
44, 64, 128, 256, 1024, 1518, 2048, 4472, 9180
The minimum size IP PDU for UDP on ATM is 44 octets, the minimum size of
Dunn & Martin [Page 6]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
44 is recommended to allow direct comparison to token ring performance.
The IP PDU size of 4472 is recommended instead of the theoretical FDDI
maximum size of 4500 octets in order to permit the same type of
comparison. An IP (i.e. not UDP) IP PDU may be used in addition if a
higher data rate is desired, in which case the minimum IP PDU size is 28
octets.
2.8. Verifying received IP PDUs
The test equipment SHOULD discard any IP PDUs received during a test run
that are not actual forwarded test IP PDUs. For example, keep-alive and
routing update IP PDUs SHOULD NOT be included in the count of received
IP PDUs. In any case, the test equipment SHOULD verify the length of
the received IP PDUs and check that they match the expected length.
Preferably, the test equipment SHOULD include sequence numbers in the
transmitted IP PDUs and check for these numbers on the received IP PDUs.
If this is done, the reported results SHOULD include. in addition to the
number of IP PDUs dropped, the number of IP PDUs that were received out
of order, the number of duplicate IP PDUs received and the number of
gaps in the received IP PDU numbering sequence. This functionality is
required for some of the described tests.
2.9. Modifiers
It is useful to characterize the SUTs performance under a number of
conditions. Some of these conditions are noted below. The reported
results SHOULD include as many of these conditions as the test equipment
is able to generate. The suite of tests SHOULD be run first without any
modifying conditions, then repeated under each of the modifying
conditions separately. To preserve the ability to compare the results
of these tests, any IP PDUs that are required to generate the modifying
conditions (excluding management queries) will be included in the same
data stream as that of the normal test IP PDUs and in place of one of
the test IP PDUs. They MUST not be supplied to the SUT on a separate
network port.
2.9.1. Management IP PDUs
Most ATM data networks now make use of ILMI, signaling and OAM. In many
environments, there can be a number of management stations sending
queries to the same SUT at the same time.
Dunn & Martin [Page 7]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Management queries MUST be made in accordance with the applicable
specification, e.g., ILMI sysUpTime getNext requests will be made in
accordance with ILMI 4.0. The response to the query MUST be verified by
the test equipment. Note that, for each management protocol in use, this
requires that the test equipment implement the associated protocol state
machine. One example of the specific query IP PDU that should be used
is shown in Appendix B.
2.9.2. Routing update IP PDUs
The processing of PNNI updates could have a significant impact on the
ability of a switch to forward cells and complete calls. If PNNI is
configured on the SUT, one routing update MUST be transmitted before the
first test IP PDU is transmitted during the trial. The test SHOULD
verify that the SUT has properly processed the routing update.
PNNI routing update IP PDUs SHOULD be sent at the rate specified in
Appendix B. Appendix C defines two routing update PDUs for the TCP/IP
over ATM example. The routing updates are designed to change the
routing on a number of networks that are not involved in the forwarding
of the test data. The first IP PDU sets the routing table state to "A",
the second one changes the state to "B". The IP PDUs MUST be alternated
during the trial. The test SHOULD verify that the SUT has properly
processed the routing update.
2.10. Filters
Filters are added to switches to selectively inhibit the forwarding of
cells that would normally be forwarded. This is usually done to
implement security controls on the data that is accepted between one
area and another. Different products have different capabilities to
implement filters. Filters are applicable only if the SUT supports the
filtering feature.
The SUT SHOULD be first configured to add one filter condition and the
tests performed. This filter SHOULD permit the forwarding of the test
data stream. This filter SHOULD be of the form as described in the SUT
Users Guide.
The SUT SHOULD be then reconfigured to implement a total of 25 filters.
The first 24 of these filters SHOULD be based on 24 separate ATM NSAP
Network Prefix addresses.
Dunn & Martin [Page 8]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The 24 ATM NSAP Network Prefix addresses SHOULD not be any that are
represented in the test data stream. The last filter SHOULD permit the
forwarding of the test data stream. By "first" and "last" we mean to
ensure that in the second case, 25 conditions must be checked before the
data IP over ATM PDUs will match the conditions that permit the
forwarding of the IP PDU. Of course, if the SUT reorders the filters or
does not use a linear scan of the filter rules the effect of the
sequence in which the filters are input is properly lost.
The exact filters configuration command lines used SHOULD be included
with the report of the results.
2.10.1. Filter Addresses
Two sets of filter addresses are required, one for the single filter
case and one for the 25 filter case.
The single filter case should permit traffic from ATM address [Switch
Network Prefix] 00 00 00 00 00 01 00 to ATM address [Switch Network
Prefix] 00 00 00 00 00 02 00 and deny all other traffic. Note that the
13 octet Switch Network Prefix MUST be configured before this test can
be run.
The 25 filter case should follow the following sequence.
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 03 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 04 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 05 00
...
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 0C 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 0D 00
allow [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 02 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 0E 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 0F 00
Dunn & Martin [Page 9]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
...
deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 18 00
deny all else
All previous filter conditions should be cleared from the switch before
this sequence is entered. The sequence is selected to test to see if
the switch sorts the filter conditions or accepts them in the order that
they were entered. Both of these procedures will result in a greater
impact on performance than will some form of hash coding.
2.11. Protocol addresses
It is easier to implement these tests using a single logical stream of
data, with one source ATM address and one destination ATM address, and
for some conditions like the filters described above, a practical
requirement. Networks in the real world are not limited to single
streams of data. The test suite SHOULD be first run with a single ATM
source and destination address pair. The tests SHOULD then be repeated
with using a random destination address. In the case of testing single
switches, the addresses SHOULD be random and uniformly distributed over
a range of 256 seven octet user parts. In the case of testing multiple
interconnected switches, the addresses SHOULD be random and uniformly
distributed over the 256 network prefixes, each of which should support
256 seven octet user parts. The specific address ranges to use for ATM
are shown in Appendix B. IP to ATM address mapping MUST be accomplished
as described in RFC 2225.
2.12. Route Set Up
It is not reasonable that all of the routing information necessary to
forward the test stream, especially in the multiple address case, will
be manually set up. If PNNI and/or ILMI are running, at the start of
each trial a routing update MUST be sent to the SUT. This routing update
MUST include all of the ATM addresses that will be required for the
trial. This routing update will have to be repeated at the interval
required by PNNI or ILMI. An example of the format and repetition
interval of the update IP PDUs is given in Appendix B.
2.13. Bidirectional traffic
Bidirectional performance tests SHOULD be run with the same data rate
Dunn & Martin [Page 10]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
being offered from each direction. The sum of the data rates should not
exceed the theoretical limit for the media.
2.14. Single stream path
The full suite of tests SHOULD be run with the appropriate modifiers for
a single receive and transmit port on the SUT. If the internal design of
the SUT has multiple distinct pathways, for example, multiple interface
cards each with multiple network ports, then all possible permutations
of pathways SHOULD be tested separately. If multiple interconnected
switches are tested, the test MUST specify routes, which allow only one
path between source and destination ATM addresses.
2.15. Multi-port
Many switch products provide several network ports on the same interface
module. Each port on an interface module SHOULD be stimulated in an
identical manner. Specifically, half of the ports on each module SHOULD
be receive ports and half SHOULD be transmit ports. For example if a
SUT has two interface module each of which has four ports, two ports on
each interface module be receive ports and two will be transmit ports.
Each receive port MUST be offered the same data rate. The addresses in
the input data streams SHOULD be set so that an IP PDU will be directed
to each of the transmit ports in sequence. That is, all transmit ports
will receive an identical distribution of IP PDUs from a particular
receive port.
Consider the following 6 port SUT:
--------------
---------| Rx A Tx X|--------
---------| Rx B Tx Y|--------
---------| Rx C Tx Z|--------
--------------
The addressing of the data streams for each of the inputs SHOULD be:
stream sent to Rx A:
IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
stream sent to Rx B:
IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
Dunn & Martin [Page 11]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
stream sent to Rx C
IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
Note: Each stream contains the same sequence of IP destination
addresses; therefore, each transmit port will receive 3 IP PDUs
simultaneously. This procedure ensures that the SUT will have to process
multiple IP PDUs addressed to the same transmit port simultaneously.
The same configuration MAY be used to perform a bi-directional multi-
stream test. In this case all of the ports are considered both receive
and transmit ports. Each data stream MUST consist of IP PDUs whose
addresses correspond to the ATM addresses all of the other ports.
2.16. Multiple protocols
This document does not address the issue of testing the effects of a
mixed protocol environment other than to suggest that if such tests are
wanted then PDUs SHOULD be distributed between all of the test
protocols. The distribution MAY approximate the conditions on the
network in which the SUT would be used.
2.17. Multiple IP PDU sizes
This document does not address the issue of testing the effects of a
mixed IP PDU size environment other than to suggest that, if such tests
are required, then IP PDU size SHOULD be evenly distributed among all of
the PDU sizes listed in this document. The distribution MAY approximate
the conditions on the network in which the SUT would be used.
2.18. Testing beyond a single SUT
In the performance testing of a single SUT, the paradigm can be
described as applying some input to a SUT and monitoring the output. The
results of which can be used to form a basis of characterization of that
device under those test conditions.
This model is useful when the test input and output are homogenous
(e.g., 64-byte IP, AAL5 PDUs into the SUT; 64 byte IP, AAL5 PDUs out).
By extending the single SUT test model, reasonable benchmarks regarding
multiple SUTs or heterogeneous environments may be collected. In this
extension, the single SUT is replaced by a system of interconnected
Dunn & Martin [Page 12]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
network SUTs. This test methodology would support the benchmarking of a
variety of device/media/service/protocol combinations. For example, a
configuration for a LAN-to-WAN-to-LAN test might be:
(1) ATM UNI -> SUT 1 -> BISUP -> SUT 2 -> ATM UNI
Or an extended LAN configuration might be:
(2) ATM UNI -> SUT 1 -> PNNI Network -> SUT 2 -> ATM UNI
In both examples 1 and 2, end-to-end benchmarks of each system could be
empirically ascertained. Other behavior may be characterized through the
use of intermediate devices. In example 2, the configuration may be used
to give an indication of the effect of PNNI routing on IP throughput.
Because multiple SUTs are treated as a single system, there are
limitations to this methodology. For instance, this methodology may
yield an aggregate benchmark for a tested system. That benchmark alone,
however, may not necessarily reflect asymmetries in behavior between the
SUTs, latencies introduced by other apparatus (e.g., CSUs/DSUs,
switches), etc.
Further, care must be used when comparing benchmarks of different
systems by ensuring that the SUTs' features and configuration of the
tested systems have the appropriate common denominators to allow
comparison.
2.19. Maximum IP PDU rate
The maximum IP PDU rates that should be used when testing LAN
connections SHOULD be the listed theoretical maximum rate for the IP PDU
size on the media.
The maximum IP PDU rate that should be used when testing WAN connections
SHOULD be greater than the listed theoretical maximum rate for the IP
PDU size on that speed connection. The higher rate for WAN tests is to
compensate for the fact that some vendors employ various forms of header
compression.
A list of maximum IP PDU rates for LAN connections is included in
Appendix B.
Dunn & Martin [Page 13]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
2.20. Bursty traffic
It is convenient to measure the SUT performance under steady state load;
however, this is an unrealistic way to gauge the functioning of a SUT.
Actual network traffic normally consists of bursts of IP PDUs.
Some of the tests described below SHOULD be performed with both constant
bit rate, bursty Unspecified Bit Rate (UBR) Best Effort [AF-TM4.1] and
Variable Bit Rate Non-real Time (VBR-nrt) Best Effort [AF-TM4.1]. The
IP PDUs within a burst are transmitted with the minimum legitimate
inter-IP PDU gap.
The objective of the test is to determine the minimum interval between
bursts that the SUT can process with no IP PDU loss. Tests SHOULD be
run with burst sizes of 10% of Maximum Burst Size (MBS), 20% of MBS, 50%
of MBS and 100% MBS. Note that the number of IP PDUs in each burst will
depend on the PDU size. For UBR, the MBS refers to the associated VBR
traffic parameters.
2.21. Trial description
A particular test consists of multiple trials. Each trial returns one
piece of information, for example the loss rate at a particular input IP
PDU rate. Each trial consists of five of phases:
a) If the SUT is a switch supporting PNNI, send the routing update to
the SUT receive port and wait two seconds to be sure that the routing
has settled.
b) Send an ATM ARP PDU to determine the ATM address corresponding to the
destination IP address. The formats of the ATM ARP PDU that should be
used are shown in the Test Frame Formats document and MUST be in
accordance with RFC 2225.
c) Stimulate SUT with traffic load.
d) Wait for two seconds for any residual IP PDUs to be received.
e) Wait for at least five seconds for the SUT to restabilize.
2.22. Trial duration
Dunn & Martin [Page 14]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The objective of the tests defined in this document is to accurately
characterize the behavior of a particular piece of network equipment
under varying traffic loads. The choice of test duration must be a
compromise between this objective and keeping the duration of the
benchmarking test suite within reasonable bounds. The SUT SHOULD be
stimulated for at least 60 seconds. If this time period results in a
high variance in the test results, the SUT SHOULD be stimulated for at
least 300 seconds.
2.23. Address resolution
The SUT MUST be able to respond to address resolution requests sent by
another SUT, an ATM ARP server or the test equipment in accordance with
RFC 2225.
2.24. Synchronized Payload Bit Pattern.
Some measurements assume that both the transmitter and receiver payload
information is synchronized. Synchronization MUST be achieved by
supplying a known bit pattern to both the transmitter and receiver.
This bit pattern MUST be one of the following: PRBS-15, PRBS-23, 0xFF00,
or 0xAA55.
2.25. Burst Traffic Descriptors.
Some measurements require busty traffic patterns. These patterns MUST
conform to one of the following traffic descriptors:
1) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=8192
2) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=4096
3) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=8192
4) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=4096
5) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=8192
6) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=4096
7) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=65536
Dunn & Martin [Page 15]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
8) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=32768
The allotted line rate refers to the total available line rate divided
by the number of VCCs in use.
3. Performance Metrics
3.1. Physical Layer- SONET
3.1.1. Pointer Movements
3.1.1.1. Pointer Movement Propagation.
Objective: To determine that the SUT does not propagate pointer movements
as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP PDUs at a specific rate through the SUT.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
3) Count the IP PDUs that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test, else lower the test device traffic rate
until the counts are the same.
4) Inject one forward payload pointer movement. Verify that the SUT
does not change the pointer.
5) Inject one forward payload pointer movement every 1 second. Verify
that the SUT does not change the pointer.
6) Discontinue the payload pointer movement.
7) Inject five forward payload pointer movements every 1 second. Verify
Dunn & Martin [Page 16]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
that the SUT does not change the pointer.
8) Discontinue the payload pointer movement.
9) Inject one backward payload pointer movement. Verify that the SUT
does not change the pointer.
10) Inject one backward payload pointer movement every 1 second. Verify
that the SUT does not change the pointer.
11) Discontinue the payload pointer movement.
12) Inject five backward payload pointer movements every 1 second.
Verify that the SUT does not change the pointer.
13) Discontinue the payload pointer movement.
Reporting Format:
The results of the pointer movement propagation test SHOULD be reported
in a form of a table. The rows SHOULD be labeled single pointer
movement, one pointer movement per second, and five pointer movements
per second. The columns SHOULD be labeled pointer movement and loss of
pointer. The elements of the table SHOULD be either True or False,
indicating whether the particular condition was observed for each test.
The table MUST also indicate the IP PDU size in octets and traffic rate
in IP PDUs per second as generated by the test device.
3.1.1.2. Cell Loss due to Pointer Movement.
Objective: To determine if the SUT will drop cells due to pointer movements
as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of cells at a specific rate through the SUT.
Dunn & Martin [Page 17]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one forward payload pointer movement. Verify that the SUT
does not drop any cells.
5) Inject one forward payload pointer movement every 1 second. Verify
that the SUT does not drop any cells.
6) Discontinue the payload pointer movement.
7) Inject five forward payload pointer movements every 1 second. Verify
that the SUT does not drop any cells.
8) Discontinue the payload pointer movement.
9) Inject one backward payload pointer movement. Verify that the SUT
does not drop any cells.
10) Inject one backward payload pointer movement every 1 second. Verify
that the SUT does not drop any cells.
11) Discontinue the payload pointer movement.
12) Inject five backward payload pointer movements every 1 second.
Verify that the SUT does not drop any cells.
13) Discontinue the payload pointer movement.
Reporting Format:
The results of the cell loss due to pointer movement test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single pointer
movement, one pointer movement per second, and five pointer movements
per second. The columns SHOULD be labeled cell loss and number of cells
Dunn & Martin [Page 18]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
lost. The elements of column 1 SHOULD be either True or False,
indicating whether the particular condition was observed for each test.
The elements of column 2 SHOULD be non-negative integers.
The table MUST also indicate the traffic rate in IP PDUs per second as
generated by the test device.
3.1.1.3. IP Packet Loss due to Pointer Movement.
Objective: To determine if the SUT will drop IP packets due to pointer
movements as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP packets at a specific rate through the
SUT. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one forward payload pointer movement. Verify that the SUT
does not drop any packets.
5) Inject one forward payload pointer movement every 1 second. Verify
that the SUT does not drop any packets.
6) Discontinue the payload pointer movement.
7) Inject five forward payload pointer movements every 1 second. Verify
that the SUT does not drop any packets.
8) Discontinue the payload pointer movement.
9) Inject one backward payload pointer movement. Verify that the SUT
Dunn & Martin [Page 19]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
does not drop any packets.
10) Inject one backward payload pointer movement every 1 second. Verify
that the SUT does not drop any packets.
11) Discontinue the payload pointer movement.
12) Inject five backward payload pointer movements every 1 second.
Verify that the SUT does not drop any packets.
13) Discontinue the payload pointer movement.
Reporting Format:
The results of the IP packet loss due to pointer movement test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single pointer
movement, one pointer movement per second, and five pointer movements
per second. The columns SHOULD be labeled packet loss and number of
packets lost. The elements of column 1 SHOULD be either True or False,
indicating whether the particular condition was observed for each test.
The elements of column 2 SHOULD be non-negative integers.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.1.2. Transport Overhead (TOH) Error Count
3.1.2.1. TOH Error Propagation.
Objective: To determine that the SUT does not propagate TOH errors as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP PDUs at a specific rate through the SUT.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
Dunn & Martin [Page 20]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3) Count the IP PDUs that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test, else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the first bit of the A1 and A2 Frameword. Verify
that the SUT does not propagate the error.
5) Inject one error in the first bit of the A1 and A2 Frameword every 1
second. Verify that the SUT does not propagate the error.
6) Discontinue the Frameword error.
7) Inject one error in the first bit of the A1 and A2 Frameword for 4
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT indicates
Loss of Frame.
8) Discontinue the Frameword error.
Reporting Format:
The results of the TOH error propagation test SHOULD be reported in a
form of a table. The rows SHOULD be labeled single error, one error per
second, and four consecutive errors every 6 IP PDUs. The columns SHOULD
be labeled error propagated and loss of IP PDU. The elements of the
table SHOULD be either True or False, indicating whether the particular
condition was observed for each test.
The table MUST also indicate the IP PDU size in octets and traffic rate
in IP PDUs per second as generated by the test device.
3.1.2.2. c TOH Error.
Objective: To determine if the SUT will drop cells due TOH Errors as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of cells at a specific rate through the SUT.
Dunn & Martin [Page 21]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the first bit of the A1 and A2 Frameword. Verify
that the SUT does not drop any cells.
5) Inject one error in the first bit of the A1 and A2 Frameword every 1
second. Verify that the SUT does not drop any cells.
6) Discontinue the Frameword error.
7) Inject one error in the first bit of the A1 and A2 Frameword for 4
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does drop
cells.
8) Discontinue the Frameword error.
Reporting Format:
The results of the Cell Loss due to TOH errors test SHOULD be reported
in a form of a table. The rows SHOULD be labeled single error, one error
per second, and four consecutive errors every 6 IP PDUs. The columns
SHOULD be labeled cell loss and number of cells lost. The elements of
column 1 SHOULD be either True or False, indicating whether the
particular condition was observed for each test. The elements of column
2 SHOULD be non-negative integers.
The table MUST also indicate the traffic rate in IP PDUs per second as
generated by the test device.
3.1.2.3. IP Packet Loss due to TOH Error.
Objective: To determine if the SUT will drop IP packets due to TOH errors
as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 22]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP packets at a specific rate through the
SUT. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the first bit of the A1 and A2 Frameword. Verify
that the SUT does not drop any packets.
5) Inject one error in the first bit of the A1 and A2 Frameword every 1
second. Verify that the SUT does not drop any packets.
6) Discontinue the Frameword error.
7) Inject one error in the first bit of the A1 and A2 Frameword for 4
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does drop
packets.
8) Discontinue the Frameword error.
Reporting Format:
The results of the IP packet loss due to TOH errors test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single error,
one error per second, and four consecutive errors every 6 IP PDUs. The
columns SHOULD be labeled packet loss and number of packets lost. The
elements of column 1 SHOULD be either True or False, indicating whether
the particular condition was observed for each test. The elements of
column 2 SHOULD be non-negative integers.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.1.3. Path Overhead (POH) Error Count
Dunn & Martin [Page 23]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3.1.3.1. POH Error Propagation.
Objective: To determine that the SUT does not propagate POH errors as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP PDUs at a specific rate through the SUT.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
3) Count the IP PDUs that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test, else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT
does not propagate the error.
5) Inject one error in the B3 byte every 1 second. Verify that the SUT
does not propagate the error.
6) Discontinue the POH error.
Reporting Format:
The results of the POH error propagation test SHOULD be reported in a
form of a table. The rows SHOULD be labeled single error and one error
per second. The columns SHOULD be labeled error propagated and loss of
IP PDU. The elements of the table SHOULD be either True or False,
indicating whether the particular condition was observed for each test.
The table MUST also indicate the IP PDU size in octets and traffic rate
in IP PDUs per second as generated by the test device.
3.1.3.2. Cell Loss due to POH Error.
Dunn & Martin [Page 24]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Objective: To determine if the SUT will drop cells due POH Errors as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of cells at a specific rate through the SUT.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT
does not drop any cells.
5) Inject one error in the B3 byte every 1 second. Verify that the SUT
does not drop any cells.
6) Discontinue the POH error.
Reporting Format:
The results of the Cell Loss due to POH errors test SHOULD be reported
in a form of a table. The rows SHOULD be labeled single error and one
error per second. The columns SHOULD be labeled cell loss and number of
cells lost. The elements of column 1 SHOULD be either True or False,
indicating whether the particular condition was observed for each test.
The elements of column 2 SHOULD be non-negative integers.
The table MUST also indicate the traffic rate in IP PDUs per second as
generated by the test device.
3.1.3.3. IP Packet Loss due to POH Error.
Objective: To determine if the SUT will drop IP packets due to POH errors
as defined in RFC 2761 "Terminology for ATM Benchmarking".
Dunn & Martin [Page 25]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP packets at a specific rate through the
SUT. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT
does not drop any packets.
5) Inject one error in the B3 byte every 1 second. Verify that the SUT
does not drop any packets.
6) Discontinue the POH error.
Reporting Format:
The results of the IP packet loss due to POH errors test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single error
and one error per second. The columns SHOULD be labeled packet loss and
number of packets lost. The elements of column 1 SHOULD be either True
or False, indicating whether the particular condition was observed for
each test. The elements of column 2 SHOULD be non-negative integers.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.2. ATM Layer
3.2.1. Two-Point Cell Delay Variation (CDV)
3.2.1.1. Test Setup
The cell delay measurements assume that both the transmitter and
Dunn & Martin [Page 26]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
receiver timestamp information is synchronized. Synchronization SHOULD
be achieved by supplying a common clock signal (minimum of 100 Mhz or 10
ns resolution) to both the transmitter and receiver. The maximum
timestamp values MUST be recorded to ensure synchronization in the case
of counter rollover. The cell delay measurements SHOULD utilize the
O.191 cell (ITUT-O.191) encapsulated in a valid IP packet. If the O.191
cell is not available, a test cell encapsulated in a valid IP packet MAY
be used. The test cell MUST contain a transmit timestamp which can be
correlated with a receive timestamp. A description of the test cell MUST
be included in the test results. The description MUST include the
timestamp length (in bits), counter rollover value, and the timestamp
accuracy (in ns).
3.2.1.2. Two-point CDV/Steady Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCC. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
Dunn & Martin [Page 27]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the Two-point CDV/Steady Load/One VCC test SHOULD be
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, maximum and minimum CDV
during the test in us, and peak-to-peak CDV in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in
us. The integration time per point MUST be indicated.
The histogram results SHOULD display the peak-to-peak cell delay. The
x- coordinate SHOULD be the cell delay in us with at least 256 bins.
The y- coordinate SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.3. Two-point CDV/Steady Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCCs. All
of the VPI/VCI pairs will generate traffic at the same traffic rate.
Dunn & Martin [Page 28]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Steady Load/Twelve VCCs test SHOULD be
reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in ms. There SHOULD be 12 curves on the graph, one curves
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay
in us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.4. Two-point CDV/Steady Load/Maximum VCCs
Dunn & Martin [Page 29]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCCs. All
of the VPI/VCI pairs will generate traffic at the same traffic rate.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Steady Load/Maximum VCCs test SHOULD be
reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. There will be
Dunn & Martin [Page 30]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in us. There SHOULD be no more than 10 curves on each graph,
one curve indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCC. Since this test
is not a throughput test, the rate should not be greater than 90% of
line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
Dunn & Martin [Page 31]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
The results of the Two-point CDV/Bursty VBR Load/One VCC test SHOULD be
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, maximum and minimum CDV
during the test in us, and peak-to-peak CDV in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in
us. The integration time per point MUST be indicated.
The histogram results SHOULD display the peak-to-peak cell delay. The
x- coordinate SHOULD be the cell delay in us with at least 256 bins.
The y- coordinate SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.1.6. Two-point CDV/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
Dunn & Martin [Page 32]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Bursty VBR Load/Twelve VCCs test SHOULD
be reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in ms. There SHOULD be 12 curves on the graph, one curves
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay
in us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
Dunn & Martin [Page 33]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.1.7. Two-point CDV/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Bursty VBR Load/Maximum VCCs test
SHOULD be reported in a form of text, graphs, and histograms.
Dunn & Martin [Page 34]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. There will be
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in us. There SHOULD be no more than 10 curves on each graph,
one curve indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.1.5. Two-point CDV/Bursty UBR Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
Dunn & Martin [Page 35]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
specific UBR through the SUT via the defined test VCC. Since this test
is not a throughput test, the rate should not be greater than 90% of
line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
The results of the Two-point CDV/Bursty UBR Load/One VCC test SHOULD be
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, maximum and minimum CDV
during the test in us, and peak-to-peak CDV in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in
us. The integration time per point MUST be indicated.
The histogram results SHOULD display the peak-to-peak cell delay. The
x- coordinate SHOULD be the cell delay in us with at least 256 bins.
The y- coordinate SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.6. Two-point CDV/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Dunn & Martin [Page 36]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Bursty UBR Load/Twelve VCCs test SHOULD
be reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in ms. There SHOULD be 12 curves on the graph, one curves
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
Dunn & Martin [Page 37]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay
in us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.7. Two-point CDV/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
Dunn & Martin [Page 38]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the Two-point CDV/Bursty UBR Load/Maximum VCCs test
SHOULD be reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. There will be
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in us. There SHOULD be no more than 10 curves on each graph,
one curve indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.8. Two-point CDV/Mixed Load/Three VCC's
Objective: To determine the SUT variation in cell transfer delay with three
VCC's as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class: one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]).
Dunn & Martin [Page 39]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3) Send a specific number of IP packets containing timestamps through
the SUT via the defined test VCCs. Each generated VCC stream MUST match
the corresponding VCC Bearer class. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCC's.
Reporting Format:
The results of the Two-point CDV/Mixed Load/Three VCC test SHOULD be
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, maximum and minimum CDV
during the test in us, and peak-to-peak CDV in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in
us. The integration time per point MUST be indicated.
The histogram results SHOULD display the peak-to-peak cell delay. The
x- coordinate SHOULD be the cell delay in us with at least 256 bins.
The y- coordinate SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
Dunn & Martin [Page 40]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3.2.1.9. Two-point CDV/Mixed Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through
the SUT via the defined test VCCs. Each generated VCC stream MUST match
the corresponding VCC Bearer class. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. The x-
Dunn & Martin [Page 41]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in ms. There SHOULD be 12 curves on the graph, one curves
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay
in us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.1.10. Two-point CDV/Mixed Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. If the maximum
number of VCC's is not divisible by 3, the total for each bearer class
MUST be within 3 VCC's of each other. The VPI/VCI MUST not be one of
the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through
the SUT via the defined test VCCs. Each generated VCC stream MUST match
the corresponding VCC Bearer class. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
Dunn & Martin [Page 42]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Mixed Load/Maximum VCCs test SHOULD be
reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. There will be
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in us. There SHOULD be no more than 10 curves on each graph,
one curve indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
Dunn & Martin [Page 43]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3.2.2. Cell Error Ratio (CER)
3.2.2.1. Test Setup
The cell error ratio measurements assume that both the transmitter and
receiver payload information is synchronized. Synchronization MUST be
achieved by supplying a known bit pattern to both the transmitter and
receiver. If this bit pattern is longer than the packet size, the
receiver MUST synchronize with the transmitter before tests can be run.
3.2.2.2. CER/Steady Load/One VCC
Objective: To determine the SUT ratio of errored cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device.
Reporting Format:
Dunn & Martin [Page 44]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CER/Steady Load/One VCC test SHOULD be reported in a
form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated.
The generated bit pattern MUST also be indicated.
3.2.2.3. CER/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
Dunn & Martin [Page 45]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Steady Load/Twelve VCCs test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.4. CER/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 46]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Steady Load/Maximum VCCs test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
Dunn & Martin [Page 47]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.5. CER/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of errored cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be
configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device.
Reporting Format:
The results of the CER/Bursty VBR Load/One VCC test SHOULD be reported
Dunn & Martin [Page 48]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.6. CER/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using
one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
Dunn & Martin [Page 49]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.7. CER/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 50]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
Dunn & Martin [Page 51]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.5. CER/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of errored cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device.
Reporting Format:
Dunn & Martin [Page 52]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CER/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.6. CER/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
Dunn & Martin [Page 53]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.7. CER/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 54]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The
PCR, SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
Dunn & Martin [Page 55]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.1.8. CER/Mixed Load/Three VCC's
Objective: To determine the SUT ratio of errored cells with the three VCCs
supported on the SUT in relation to the total cells sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
Dunn & Martin [Page 56]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CER/Bursty Mixed Load/Three VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.1.9. CER/Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
Dunn & Martin [Page 57]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.1.10. CER/Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 58]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty Mixed Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
Dunn & Martin [Page 59]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.3. Cell Loss Ratio (CLR)
3.2.3.1. CLR/Steady Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCC. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cells transmitted and received on the test
device.
Reporting Format:
Dunn & Martin [Page 60]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CLR/Steady Load/One VCC test SHOULD be reported in a
form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.2. CLR/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
Dunn & Martin [Page 61]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Steady Load/Twelve VCCs test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each VCC.
There should be 12 curves on the graph, on curve indicated and labeled
for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.3. CLR/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 62]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Steady Load/Maximum VCCs test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
Dunn & Martin [Page 63]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.4. CLR/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be
configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cells transmitted and received on the test
device.
Reporting Format:
The results of the CLR/Bursty VBR Load/One VCC test SHOULD be reported
Dunn & Martin [Page 64]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using
one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
Dunn & Martin [Page 65]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 66]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as either a CBR or VBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
Dunn & Martin [Page 67]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.4. CLR/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cells transmitted and received on the test
device.
Reporting Format:
Dunn & Martin [Page 68]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CLR/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.5. CLR/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
Dunn & Martin [Page 69]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.6. CLR/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 70]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be one
of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR,
SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
Dunn & Martin [Page 71]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.4. CLR/Bursty Mixed Load/Three VCC
Objective: To determine the SUT ratio of lost cells on three VCC's in
relation to the total cells sent as defined in RFC 2761 "Terminology for
ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
MBS must be configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Dunn & Martin [Page 72]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Reporting Format:
The results of the CLR/Bursty Mixed Load/Three VCC test SHOULD be
reported in in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.5. CLR/Bursty Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
Dunn & Martin [Page 73]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.6. CLR/Bursty Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
Dunn & Martin [Page 74]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty Mixed Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
Dunn & Martin [Page 75]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4. Cell Misinsertion Rate (CMR)
3.2.4.1. CMR/Steady Load/One VCC
Objective: To determine the SUT ratio of cell misinsertion on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC MUST be
configured as either a CBR, VBR, or UBR connection. The VCC SHOULD
contain one VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCC. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
Dunn & Martin [Page 76]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
the test device.
Reporting Format:
The results of the CMR/Steady Load/One VCC test SHOULD be reported in a
form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.2. CMR/Steady Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
Dunn & Martin [Page 77]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Steady Load/Twelve VCCs test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each VCC.
There should be 12 curves on the graph, on curve indicated and labeled
for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.3. CMR/Steady Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Dunn & Martin [Page 78]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Steady Load/Maximum VCCs test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
each graph. The x-coordinate SHOULD be the test run time in either
seconds, minutes or days depending on the total length of the test. The
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be
Dunn & Martin [Page 79]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
the CMR for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.4. CMR/Bursty VBR Load/One VCC
Objective: To determine the SUT rate of misinserted cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be
configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device.
Reporting Format:
Dunn & Martin [Page 80]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CMR/Bursty VBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using
one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
Dunn & Martin [Page 81]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 82]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
each graph. The x-coordinate SHOULD be the test run time in either
seconds, minutes or days depending on the total length of the test. The
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be
Dunn & Martin [Page 83]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
the CMR for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.4. CMR/Bursty UBR Load/One VCC
Objective: To determine the SUT rate of misinserted cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device.
Reporting Format:
Dunn & Martin [Page 84]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CMR/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.5. CMR/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
Dunn & Martin [Page 85]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.6. CMR/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 86]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The
PCR, SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
each graph. The x-coordinate SHOULD be the test run time in either
seconds, minutes or days depending on the total length of the test. The
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be
Dunn & Martin [Page 87]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
the CMR for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.4. CMR/Bursty Mixed Load/Three VCC
Objective: To determine the SUT rate of misinserted cells on three VCC's in
relation to the total cells sent as defined in RFC 2761 "Terminology for
ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
MBS must be configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device.
Dunn & Martin [Page 88]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Reporting Format:
The results of the CMR/Bursty Mixed Load/Three VCC test SHOULD be
reported reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.5. CMR/Bursty Mixed Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
Dunn & Martin [Page 89]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.6. CMR/Bursty Mixed Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
Dunn & Martin [Page 90]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty Mixed Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
Dunn & Martin [Page 91]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
each graph. The x-coordinate SHOULD be the test run time in either
seconds, minutes or days depending on the total length of the test. The
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be
the CMR for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5. CRC Error Ratio (CRC-ER)
3.2.5.1. CRC-ER/Steady Load/One VCC
Objective: To determine the SUT ratio of CRC errors on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCC. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
Dunn & Martin [Page 92]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
5) Record the number of CRC errored cells received on the test device.
Reporting Format:
The results of the CRC-ER/Steady Load/One VCC test SHOULD be reported in
a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.2. CRC-ER/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
Dunn & Martin [Page 93]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device.
Reporting Format:
The results of the CRC-ER/Steady Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.3. CRC-ER/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
Dunn & Martin [Page 94]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device.
Reporting Format:
The results of the CRC-ER/Steady Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
Dunn & Martin [Page 95]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.4. CRC-ER/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be
configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
Dunn & Martin [Page 96]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
device.
Reporting Format:
The results of the CRC-ER/Bursty VBR Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.5. CRC-ER/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using
one of the specified traffic descriptors.
Dunn & Martin [Page 97]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device for all VCCs.
Reporting Format:
The results of the CRC-ER/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.6. CRC-ER/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
Dunn & Martin [Page 98]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as either a CBR or VBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device for all VCCs.
Reporting Format:
The results of the CRC-ER/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
Dunn & Martin [Page 99]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The graph results SHOULD display the CRC Error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.7. CRC-ER/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
Dunn & Martin [Page 100]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
5) Record the number of CRC errored cells received per VCC on the test
device.
Reporting Format:
The results of the CRC-ER/Bursty UBR Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.8. CRC-ER/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
Dunn & Martin [Page 101]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device for all VCCs.
Reporting Format:
The results of the CRC-ER/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.9. CRC-ER/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
Dunn & Martin [Page 102]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be one
of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR,
SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device for all VCCs.
Reporting Format:
The results of the CRC-ER/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
Dunn & Martin [Page 103]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The graph results SHOULD display the CRC Error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.10. CRC-ER/Bursty Mixed Load/Three VCC
Objective: To determine the SUT ratio of lost cells on three VCC's in
relation to the total cells sent as defined in RFC 2761 "Terminology for
ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
MBS must be configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
Dunn & Martin [Page 104]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device.
Reporting Format:
The results of the CRC-ER/Bursty Mixed Load/Three VCC test SHOULD be
reported in in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.5.11. CRC-ER/Bursty Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
Dunn & Martin [Page 105]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device for all VCCs.
Reporting Format:
The results of the CRC-ER/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
entire test.
The graph results SHOULD display the CRC Error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
Dunn & Martin [Page 106]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3.2.5.12. CRC-ER/Bursty Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of CRC errored cells received per VCC on the test
device for all VCCs.
Reporting Format:
The results of the CRC-ER/Bursty Mixed Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CRC-ER for the
Dunn & Martin [Page 107]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
entire test.
The graph results SHOULD display the CRC Error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.7. Cell Transfer Delay (CTD)
3.2.7.1. Test Setup
The cell transfer delay measurements assume that both the transmitter
and receiver timestamp information is synchronized. Synchronization
SHOULD be achieved by supplying a common clock signal (minimum of 100
Mhz or 10 ns resolution) to both the transmitter and receiver. The
maximum timestamp values MUST be recorded to ensure synchronization in
the case of counter rollover. The cell transfer delay measurements
SHOULD utilize the O.191 cell (ITUT-O.191) encapsulated in a valid IP
packet. If the O.191 cell is not available, a test cell encapsulated in
a valid IP packet MAY be used. The test cell MUST contain a transmit
timestamp which can be correlated with a receive timestamp. A
description of the test cell MUST be included in the test results. The
description MUST include the timestamp length (in bits), counter
rollover value, and the timestamp accuracy (in ns).
3.2.7.2. CTD/Steady Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 108]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCC. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
The results of the CTD/Steady Load/One VCC test SHOULD be reported in a
form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, minimum, maximum, and mean
CTD during the test in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay in us. The integration time per point MUST be indicated.
The histogram results SHOULD display the cell transfer delay. The x-
coordinate SHOULD be the cell transfer delay in us with at least 256
bins. The y-coordinate SHOULD be the number of cells observed in each
bin.
Dunn & Martin [Page 109]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.7.3. CTD/Steady Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCCs. All
of the VPI/VCI pairs will generate traffic at the same traffic rate.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Steady Load/Twelve VCCs test SHOULD be reported
in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
Dunn & Martin [Page 110]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay for each VCC in ms. There SHOULD be 12 curves on the graph, one
curves indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.7.4. CTD/Steady Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCCs. All
of the VPI/VCI pairs will generate traffic at the same traffic rate.
Dunn & Martin [Page 111]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Steady Load/Maximum VCCs test SHOULD be reported
in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
cell transfer delay for each VCC in us. There SHOULD be no more than 10
curves on each graph, one curve indicated and labeled for each VCC. The
integration time per point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.7.5. CTD/Bursty VBR Load/One VCC
Dunn & Martin [Page 112]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCC. Since this test
is not a throughput test, the rate should not be greater than 90% of
line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
The results of the CTD/Bursty VBR Load/One VCC test SHOULD be reported
in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, minimum, maximum, and mean
CTD during the test in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay in us. The integration time per point MUST be indicated.
Dunn & Martin [Page 113]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The histogram results SHOULD display the cell transfer delay. The x-
coordinate SHOULD be the cell transfer delay in us with at least 256
bins. The y-coordinate SHOULD be the number of cells observed in each
bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.7.6. CTD/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
Dunn & Martin [Page 114]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CTD/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay for each VCC in ms. There SHOULD be 12 curves on the graph, one
curves indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.7.7. CTD/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
Dunn & Martin [Page 115]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
cell transfer delay for each VCC in us. There SHOULD be no more than 10
curves on each graph, one curve indicated and labeled for each VCC. The
integration time per point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
Dunn & Martin [Page 116]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.7.5. CTD/Bursty UBR Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCC. Since this test
is not a throughput test, the rate should not be greater than 90% of
line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
The results of the CTD/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
Dunn & Martin [Page 117]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VPI/VCI during the test in positive integers, minimum, maximum, and mean
CTD during the test in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay in us. The integration time per point MUST be indicated.
The histogram results SHOULD display the cell transfer delay. The x-
coordinate SHOULD be the cell transfer delay in us with at least 256
bins. The y-coordinate SHOULD be the number of cells observed in each
bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.7.6. CTD/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
Dunn & Martin [Page 118]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay for each VCC in ms. There SHOULD be 12 curves on the graph, one
curves indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.7.7. CTD/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
Dunn & Martin [Page 119]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
cell transfer delay for each VCC in us. There SHOULD be no more than 10
curves on each graph, one curve indicated and labeled for each VCC. The
integration time per point MUST be indicated.
Dunn & Martin [Page 120]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.7.8. CTD/Mixed Load/Three VCC's
Objective: To determine the SUT variation in cell transfer delay with three
VCC's as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class: one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through
the SUT via the defined test VCCs. Each generated VCC stream MUST match
the corresponding VCC Bearer class. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCC's.
Reporting Format:
Dunn & Martin [Page 121]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CTD/Mixed Load/Three VCC test SHOULD be reported in a
form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, minimum, maximum, and mean
CTD during the test in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay in us. The integration time per point MUST be indicated.
The histogram results SHOULD display the cell transfer delay. The x-
coordinate SHOULD be the cell transfer delay in us with at least 256
bins. The y-coordinate SHOULD be the number of cells observed in each
bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.7.9. CTD/Mixed Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through
Dunn & Martin [Page 122]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
the SUT via the defined test VCCs. Each generated VCC stream MUST match
the corresponding VCC Bearer class. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Mixed Load/Twelve VCCs test SHOULD be reported in
a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell transfer
delay for each VCC in ms. There SHOULD be 12 curves on the graph, one
curves indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
Dunn & Martin [Page 123]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
indicated.
3.2.7.10. CTD/Mixed Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. If the maximum
number of VCC's is not divisible by 3, the total for each bearer class
MUST be within 3 VCC's of each other. The VPI/VCI MUST not be one of
the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through
the SUT via the defined test VCCs. Each generated VCC stream MUST match
the corresponding VCC Bearer class. All of the VPI/VCI pairs will
generate traffic at the same traffic rate. Since this test is not a
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the CTD/Mixed Load/Maximum VCCs test SHOULD be reported
in a form of text, graphs, and histograms.
Dunn & Martin [Page 124]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The text results SHOULD display the numerical values of the CTD. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CTD on each
VCC during the test in us, and mean CTD on each VCC in us.
The graph results SHOULD display the cell transfer delay values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
cell transfer delay for each VCC in us. There SHOULD be no more than 10
curves on each graph, one curve indicated and labeled for each VCC. The
integration time per point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will be one
histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5)
3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors
Objective: To determine if the SUT will drop IP packets due AAL5 Re-
assembly Errors as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of cells at a specific rate through the SUT.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
Dunn & Martin [Page 125]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the first bit of the AAL5 payload. Verify that
the SUT does not drop any AAL5 PDU's.
5) Discontinue the AAL5 payload error.
6) Inject one error in the first bit of the AAL5 header for 4
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does drop
the AAL5 PDU's.
7) Discontinue the AAL5 payload error.
Reporting Format:
The results of the AAL5 PDU Loss due to AAL5 PDU errors test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single error,
one error per second, and four consecutive errors every 6 IP PDUs. The
columns SHOULD be labeled AAL5 PDU loss and number of PDU's lost. The
elements of column 1 SHOULD be either True or False, indicating whether
the particular condition was observed for each test. The elements of
column 2 SHOULD be non-negative integers.
The table MUST also indicate the traffic rate in IP PDUs per second as
generated by the test device.
3.3.2. AAL5 Reassembly Time.
Objective: To determine the SUT AAL5 Reassembly Time as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP packets at a specific rate through the
Dunn & Martin [Page 126]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
SUT. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5. The AAL5 PDU size is 65535 octets or 1365 ATM cells.
3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Given an AAL5 reassembly timer of 'x' seconds, where 'x' is the
actual value of the AAL5 reassembly timer on the SUT, sent traffic at
1365 cells per 'x' seconds. The expected results are that no AAL5 PDU's
will be dropped.
5) Send traffic at 1360 cells per 'x' seconds. The expected results are
that all AAL5 PDU's will be dropped.
Reporting Format:
The results of the IP packet loss due to AAL5 reassumbly timeout test
SHOULD be reported in a form of a table. The rows SHOULD be labeled 1365
cells per 'x' seconds and 1360 cells per 'x' seconds. The columns SHOULD
be labeled packet loss and number of packets lost. The elements of
column 1 SHOULD be either True or False, indicating whether the
particular condition was observed for each test. The elements of column
2 SHOULD be non-negative integers.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device, including the
value of
3.3.3. AAL5 CRC Error Ratio.
3.3.2.1. Test Setup
The AAL5 CRC error ratio measurements assume that both the transmitter
and receiver payload information is synchronized. Synchronization MUST
be achieved by supplying a known bit pattern to both the transmitter and
receiver. If this bit pattern is longer than the packet size, the
receiver MUST synchronize with the transmitter before tests can be run.
Dunn & Martin [Page 127]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3.3.2.2. AAL5-CRC-ER/Steady Load/One VCC
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device.
Reporting Format:
The results of the AAL5-CRC-ER/Steady Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
Dunn & Martin [Page 128]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated.
The generated bit pattern MUST also be indicated.
3.3.2.3. AAL5-CRC-ER/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Dunn & Martin [Page 129]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Reporting Format:
The results of the AAL5-CRC-ER/Steady Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.4. AAL5-CRC-ER/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
Dunn & Martin [Page 130]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Steady Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
Dunn & Martin [Page 131]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
3.3.2.5. AAL5-CRC-ER/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be
configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty VBR Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
Dunn & Martin [Page 132]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using
one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Dunn & Martin [Page 133]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Reporting Format:
The results of the AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
Dunn & Martin [Page 134]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
Dunn & Martin [Page 135]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
generated bit pattern MUST also be indicated.
3.3.2.5. AAL5-CRC-ER/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty UBR Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
Dunn & Martin [Page 136]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.6. AAL5-CRC-ER/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
Dunn & Martin [Page 137]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty UBR Load/Twelve VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.7. AAL5-CRC-ER/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
Dunn & Martin [Page 138]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
VCC's MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The
PCR, SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty UBR Load/Maximum VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
Dunn & Martin [Page 139]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.1.8. AAL5-CRC-ER/Mixed Load/Three VCC's
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on three VCC's
in a transmission in relation to the total AAL5 PDU's sent as defined in
RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty Mixed Load/Three VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
Dunn & Martin [Page 140]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.1.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
Dunn & Martin [Page 141]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty Mixed Load/Twelve VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.1.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
Dunn & Martin [Page 142]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty Mixed Load/Maximum VCCs test
SHOULD be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
Dunn & Martin [Page 143]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.4. ATM Service: Signaling
3.4.1. CAC Denial Time and Connection Establishment Time
Objective: To determine the CAC rejection time and Connection Establishment
Time on the SUT as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will not allow CAC to reject the call.
3) Send the UNI signaling setup message. Note the time the setup message
was sent. Verify that the SVC has been setup with the correct
parameters. Note the time the connect message was received
4) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will allow CAC to reject the call.
5) Send the UNI signaling setup message. Note the time the setup
message was sent. Verify that the SVC has been rejected with the
correct cause code. Note the time the release complete message was
received.
6) Compute the rejection time as the difference between the time the
release complete message was received and the time setup message was
send.
Reporting Format:
Dunn & Martin [Page 144]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the CAC Denial Time and Connection Establishment Time
tests SHOULD be reported in a form of a table. The rows SHOULD be
labeled call accepted and call rejected. The columns SHOULD be labeled
time setup sent, time response recieved, and correct response. The
elements of the columns 1 and 2 SHOULD be in seconds. The elements of
column 3 SHOULD be be either True or False, indicating whether the
particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.4.2. Connection Teardown Time
Objective: To determine the Connection Teardown Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will not allow CAC to reject the call.
3) Send the UNI signaling setup message. Note the time the setup message
was sent. Verify that the SVC has been setup with the correct
parameters. Note the time the connect message was received
4) Create a UNI signaling release message, as described in Appendix C,
specifying a cause code of normal call clearing.
5) Send the UNI signaling release message. Note the time the release
message was sent. Verify that the SVC has been terminated with the
correct cause code. Note the time the release complete message was
received.
6) Compute the release time as the difference between the time the
release complete message was received and the time release message was
send.
Reporting Format:
Dunn & Martin [Page 145]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the Connection Teardown Time tests SHOULD be reported in
a form of a table. The rows SHOULD be labeled call accepted and call
released. The columns SHOULD be labeled time message sent, time response
received, and correct response. The elements of the columns 1 and 2
SHOULD be in seconds. The elements of column 3 SHOULD be be either True
or False, indicating whether the particular condition was observed for
each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.4.3. Crankback Time
Objective: To determine the Crankback Time on the SUT as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional passthrough
configuration.
2) Create a PNNI signaling setup message, as described in Appendix C,
specifying a DTL which is not blocked by the far end SUT.
3) Send the PNNI signaling setup message. Note the time the setup
message was sent. Verify that the connect message has been received by
the near- end switch. Note the time the connect message was received
4) Create a PNNI signaling setup message, as described in Appendix C,
specifying a DTL which is blocked by the far end SUT.
5) Send the PNNI signaling release message. Note the time the release
message was sent. Note the time the release complete message was
received. Note the time the near-end switch sends it's own PNNI setup
message (referred to as the near-end setup message) specifying the non-
blocked DTL.
6) Compute the crankback time as the difference between the time the
near- end setup message was received and the time release message was
send.
Reporting Format:
Dunn & Martin [Page 146]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the Crankback Time tests SHOULD be reported in a form of
a table. The rows SHOULD be labeled DTL call accepted and call released.
The columns SHOULD be labeled time message sent, time response received,
and correct response. The elements of the columns 1 and 2 SHOULD be in
seconds. The elements of column 3 SHOULD be be either True or False,
indicating whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.4.4. Route Update Response Time
Objective: To determine the Route Update Response Time on the SUT as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional passthrough
configuration.
2) Create a PNNI PTSE as described in Appendix C, specifying a routing
topology. Verify that the routing tables on the far-end and near-end
switches are empty.
3) Send the PTSE message to the far-end switch. Note the time the PTSE
message was sent. Verify that the PTSE message has been received by the
far-end switch. Note the time the PTSE message was received.
4) Create another PNNI PTSE as described in Appendix C, specifying a
change in the routing topology. Verify that the routing tables on the
far-end and near-end switches contain the previous PTSE routes.
5) Send the PTSE message to the far-end switch. Note the time the PTSE
message was sent. Verify that the PTSE message has been received by the
far-end switch. Note the time the PTSE message was received. Note the
time the PTSE was sent to the near-end switch. Note the time the PTSE
message was received on the near-end switch.
6) Compute the Route Update Response time as the difference between the
time the far-end PTSE message was sent and the time far-end PTSE message
was received by the near-end.
Dunn & Martin [Page 147]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Reporting Format:
The results of the Route Update Response Time tests SHOULD be reported
in a form of a table. The rows SHOULD be labeled PTSE call accepted,
far-end PTSE message send, and near-end message received. The columns
SHOULD be labeled time message sent, time response received, and correct
response. The elements of the columns 1 and 2 SHOULD be in seconds.
The elements of column 3 SHOULD be be either True or False, indicating
whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.5. ATM Service: ILMI
3.5.1. MIB Alignment Time
Objective: To determine the MIB Alignment Time on the SUT as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Send a Cold Start message to the SUT. Note the time the message was
sent to the SUT. Verify that the Cold Start message has been received
by the SUT. Note the time the message was received.
3) Send a Get Request message to the SUT. Note the time the message was
sent to the SUT. Verify that the Get Request message has been received
by the SUT. Note the time the message was received.
4) After all MIB elements are exchanged, verify that the final Get
Request message has been received by the SUT. Note the time the message
was send and received by the SUT.
5) Compute the MIB Alignment Time as the difference between the time the
Cold Start message was sent and the time the final Get Request was
received by the SUT.
Dunn & Martin [Page 148]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Reporting Format:
The results of the MIB Alignment Time tests SHOULD be reported in a form
of a table. The rows SHOULD be labeled Cold Start Send, Cold Start
accepted, Final Get Request send, and Final Get Request received. The
columns SHOULD be labeled time message sent, time response received, and
correct response. The elements of the columns 1 and 2 SHOULD be in
seconds. The elements of column 3 SHOULD be be either True or False,
indicating whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.5.2. Address Registration Time
Objective: To determine the Address Registration Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Send a Set Request message to the SUT. Note the time the message was
sent to the SUT. Verify that the Set Request message has been received
by the SUT. Note the time the message was received.
3) Send a Get Request message to the SUT. Note the time the message was
sent to the SUT. Verify that the Get Request message has been received
by the SUT. Note the time the message was received.
4) After all MIB elements are exchanged, verify that the final Get
Request message has been received by the SUT. Note the time the message
was send and received by the SUT.
5) Compute the Address Registration Time as the difference between the
time the Set Request message was sent and the time the final Get Request
was received by the SUT.
Reporting Format:
Dunn & Martin [Page 149]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
The results of the Address Registration Time tests SHOULD be reported in
a form of a table. The rows SHOULD be labeled Set Request Send, Set
Request saccepted, Final Get Request send, and Final Get Request
received. The columns SHOULD be labeled time message sent, time response
received, and correct response. The elements of the columns 1 and 2
SHOULD be in seconds. The elements of column 3 SHOULD be be either True
or False, indicating whether the particular condition was observed for
each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
4. Security Considerations.
As this document is solely for the purpose of providing methodology and
describes neither a protocol nor an implementation, there are no
security considerations associated with this document.
5. Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETFs procedures
with respect to rights in standards-track and standards-related
documentation can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license
or permission for the use of such proprietary rights by implementors or
users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
6. Disclaimer
Dunn & Martin [Page 150]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
7. References
[IETF-RFC-2544] IETF RFC 2544 "Benchmarking Methodology for Network
Interconnect Devices", March, 1999.
[IETF-RFC-2225] IETF RFC 2225 "Classical IP and ARP over ATM", April,
1998.
[IETF-RFC-2761] IETF RFC 2761 "Terminology for ATM Benchmarking" Draft,
2000.
[AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version
4.0, af-ilmi-0065.000, September 1996.
[AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-test-
0022.00, December 1994.
Dunn & Martin [Page 151]
INTERNET-DRAFT Methodology for ATM Benchmarking July 2000
[AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1, af-
tm- 0121.00, April 1996.
[AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1,
September 1994.
[AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0,
July 1996.
8. Editor's Addresses
Jeffrey Dunn
Advanced Network Consultants, Inc.
4214 Crest Place, Ellicott City, MD 21043 USA
Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net
Cynthia Martin
Advanced Network Consultants, Inc.
4214 Crest Place, Ellicott City, MD 21043 USA
Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net
Dunn & Martin [Page 152]
