path: root/doc/rfc/rfc3116.txt

Network Working Group                                            J. Dunn
Request for Comments: 3116                                     C. Martin
Category: Informational                                        ANC, Inc.
                                                               June 2001


                    Methodology for ATM Benchmarking

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document discusses and defines a number of tests that may be
   used to describe the performance characteristics of ATM (Asynchronous
   Transfer Mode) based switching devices.  In addition to defining the
   tests this document also describes specific formats for reporting the
   results of the tests.

   This memo is a product of the Benchmarking Methodology Working Group
   (BMWG) of the Internet Engineering Task Force (IETF).

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1. Test Device Requirements . . . . . . . . . . . . . . . . . .  5
   2.2. Systems Under Test (SUTs). . . . . . . . . . . . . . . . . .  5
   2.3. Test Result Evaluation . . . . . . . . . . . . . . . . . . .  5
   2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.5. Test Configurations for SONET. . . . . . . . . . . . . . . .  6
   2.6. SUT Configuration. . . . . . . . . . . . . . . . . . . . . .  7
   2.7. Frame Formats. . . . . . . . . . . . . . . . . . . . . . . .  8
   2.8. Frame Sizes. . . . . . . . . . . . . . . . . . . . . . . . .  8
   2.9. Verifying Received IP PDU's. . . . . . . . . . . . . . . . .  9
   2.10. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . .  9
   2.10.1. Management IP PDU's . . . . . . . . . . . . . . . . . . .  9
   2.10.2. Routing Update IP PDU's . . . . . . . . . . . . . . . . . 10
   2.11. Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   2.11.1. Filter Addresses. . . . . . . . . . . . . . . . . . . . . 11
   2.12. Protocol Addresses. . . . . . . . . . . . . . . . . . . . . 12



Dunn & Martin                Informational                      [Page 1]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   2.13. Route Set Up. . . . . . . . . . . . . . . . . . . . . . . . 12
   2.14. Bidirectional Traffic . . . . . . . . . . . . . . . . . . . 12
   2.15. Single Stream Path. . . . . . . . . . . . . . . . . . . . . 12
   2.16. Multi-port. . . . . . . . . . . . . . . . . . . . . . . . . 13
   2.17. Multiple Protocols. . . . . . . . . . . . . . . . . . . . . 14
   2.18. Multiple IP PDU Sizes . . . . . . . . . . . . . . . . . . . 14
   2.19. Testing Beyond a Single SUT . . . . . . . . . . . . . . . . 14
   2.20. Maximum IP PDU Rate . . . . . . . . . . . . . . . . . . . . 15
   2.21. Busty Traffic . . . . . . . . . . . . . . . . . . . . . . . 15
   2.22. Trial Description . . . . . . . . . . . . . . . . . . . . . 16
   2.23. Trial Duration. . . . . . . . . . . . . . . . . . . . . . . 16
   2.24. Address Resolution. . . . . . . . . . . . . . . . . . . . . 16
   2.25. Synchronized Payload Bit Pattern. . . . . . . . . . . . . . 16
   2.26. Burst Traffic Descriptors . . . . . . . . . . . . . . . . . 17
   3. Performance Metrics. . . . . . . . . . . . . . . . . . . . . . 17
   3.1. Physical Layer-SONET . . . . . . . . . . . . . . . . . . . . 17
   3.1.1. Pointer Movements. . . . . . . . . . . . . . . . . . . . . 17
   3.1.1.1. Pointer Movement Propagation . . . . . . . . . . . . . . 17
   3.1.1.2. Cell Loss due to Pointer Movement. . . . . . . . . . . . 19
   3.1.1.3. IP Packet Loss due to Pointer Movement . . . . . . . . . 20
   3.1.2. Transport Overhead (TOH) Error Count . . . . . . . . . . . 21
   3.1.2.1. TOH Error Propagation. . . . . . . . . . . . . . . . . . 21
   3.1.2.2. Cell Loss due to TOH Error . . . . . . . . . . . . . . . 22
   3.1.2.3. IP Packet Loss due to TOH Error. . . . . . . . . . . . . 23
   3.1.3. Path Overhead (POH) Error Count. . . . . . . . . . . . . . 24
   3.1.3.1. POH Error Propagation. . . . . . . . . . . . . . . . . . 24
   3.1.3.2. Cell Loss due to POH Error . . . . . . . . . . . . . . . 25
   3.1.3.3. IP Packet Loss due to POH Error. . . . . . . . . . . . . 26
   3.2. ATM Layer. . . . . . . . . . . . . . . . . . . . . . . . . . 27
   3.2.1. Two-Point Cell Delay Variation (CDV) . . . . . . . . . . . 27
   3.2.1.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 27
   3.2.1.2. Two-point CDV/Steady Load/One VCC. . . . . . . . . . . . 27
   3.2.1.3. Two-point CDV/Steady Load/Twelve VCCs. . . . . . . . . . 28
   3.2.1.4. Two-point CDV/Steady Load/Maximum VCCs . . . . . . . . . 30
   3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC. . . . . . . . . . 31
   3.2.1.6. Two-point CDV/Bursty VBR Load/Twelve VCCs. . . . . . . . 32
   3.2.1.7. Two-point CDV/Bursty VBR Load/Maximum VCCs . . . . . . . 34
   3.2.1.8. Two-point CDV/Mixed Load/Three VCC's . . . . . . . . . . 35
   3.2.1.9. Two-point CDV/Mixed Load/Twelve VCCs . . . . . . . . . . 36
   3.2.1.10. Two-point CDV/Mixed Load/Maximum VCCs . . . . . . . . . 38
   3.2.2. Cell Error Ratio (CER) . . . . . . . . . . . . . . . . . . 39
   3.2.2.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 39
   3.2.2.2. CER/Steady Load/One VCC. . . . . . . . . . . . . . . . . 40
   3.2.2.3. CER/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 41
   3.2.2.4. CER/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 42
   3.2.2.5. CER/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 43
   3.2.2.6. CER/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 44
   3.2.2.7. CER/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 46



Dunn & Martin                Informational                      [Page 2]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   3.2.3. Cell Loss Ratio (CLR). . . . . . . . . . . . . . . . . . . 47
   3.2.3.1. CLR/Steady Load/One VCC. . . . . . . . . . . . . . . . . 47
   3.2.3.2. CLR/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 48
   3.2.3.3. CLR/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 49
   3.2.3.4. CLR/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 51
   3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 52
   3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 53
   3.2.4. Cell Misinsertion Rate (CMR) . . . . . . . . . . . . . . . 54
   3.2.4.1. CMR/Steady Load/One VCC. . . . . . . . . . . . . . . . . 54
   3.2.4.2. CMR/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 55
   3.2.4.3. CMR/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 57
   3.2.4.4. CMR/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 58
   3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 59
   3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 60
   3.2.5. CRC Error Ratio (CRC-ER) . . . . . . . . . . . . . . . . . 62
   3.2.5.1. CRC-ER/Steady Load/One VCC . . . . . . . . . . . . . . . 62
   3.2.5.2. CRC-ER/Steady Load/Twelve VCCs . . . . . . . . . . . . . 63
   3.2.5.3. CRC-ER/Steady Load/Maximum VCCs. . . . . . . . . . . . . 64
   3.2.5.4. CRC-ER/Bursty VBR Load/One VCC . . . . . . . . . . . . . 65
   3.2.5.5. CRC-ER/Bursty VBR Load/Twelve VCCs . . . . . . . . . . . 66
   3.2.5.6. CRC-ER/Bursty VBR Load/Maximum VCCs. . . . . . . . . . . 68
   3.2.5.7. CRC-ER/Bursty UBR Load/One VCC . . . . . . . . . . . . . 69
   3.2.5.8. CRC-ER/Bursty UBR Load/Twelve VCCs . . . . . . . . . . . 70
   3.2.5.9. CRC-ER/Bursty UBR Load/Maximum VCCs. . . . . . . . . . . 71
   3.2.5.10. CRC-ER/Bursty Mixed Load/Three VCC. . . . . . . . . . . 73
   3.2.5.11. CRC-ER/Bursty Mixed Load/Twelve VCCs. . . . . . . . . . 74
   3.2.5.12. CRC-ER/Bursty Mixed Load/Maximum VCCs . . . . . . . . . 75
   3.2.6. Cell Transfer Delay (CTD). . . . . . . . . . . . . . . . . 76
   3.2.6.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 76
   3.2.6.2. CTD/Steady Load/One VCC. . . . . . . . . . . . . . . . . 77
   3.2.6.3. CTD/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 78
   3.2.6.4. CTD/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 79
   3.2.6.5. CTD/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 81
   3.2.6.6. CTD/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 82
   3.2.6.7. CTD/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 83
   3.2.6.8. CTD/Bursty UBR Load/One VCC. . . . . . . . . . . . . . . 85
   3.2.6.9. CTD/Bursty UBR Load/Twelve VCCs. . . . . . . . . . . . . 86
   3.2.6.10. CTD/Bursty UBR Load/Maximum VCCs. . . . . . . . . . . . 87
   3.2.6.11. CTD/Mixed Load/Three VCC's. . . . . . . . . . . . . . . 88
   3.2.6.12. CTD/Mixed Load/Twelve VCCs. . . . . . . . . . . . . . . 90
   3.2.6.13. CTD/Mixed Load/Maximum VCCs . . . . . . . . . . . . . . 91
   3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5) . . . . . . . . . . 93
   3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors. . . . . . . 93
   3.3.2. AAL5 Re-assembly Time. . . . . . . . . . . . . . . . . . . 94
   3.3.3. AAL5 CRC Error Ratio . . . . . . . . . . . . . . . . . . . 95
   3.3.3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 95
   3.3.3.2. AAL5-CRC-ER/Steady Load/One VCC. . . . . . . . . . . . . 95
   3.3.3.3. AAL5-CRC-ER/Steady Load/Twelve VCCs. . . . . . . . . . . 96



Dunn & Martin                Informational                      [Page 3]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   3.3.3.4. AAL5-CRC-ER/Steady Load/Maximum VCCs . . . . . . . . . . 97
   3.3.3.5. AAL5-CRC-ER/Bursty VBR Load/One VCC. . . . . . . . . . . 99
   3.3.3.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs. . . . . . . . .100
   3.3.3.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs . . . . . . . .101
   3.3.3.8. AAL5-CRC-ER/Mixed Load/Three VCC's . . . . . . . . . . .102
   3.3.3.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs . . . . . . . . . . .104
   3.3.3.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs . . . . . . . . . .105
   3.4. ATM Service: Signaling . . . . . . . . . . . . . . . . . . .106
   3.4.1. CAC Denial Time and Connection Establishment Time. . . . .106
   3.4.2. Connection Teardown Time . . . . . . . . . . . . . . . . .107
   3.4.3. Crankback Time . . . . . . . . . . . . . . . . . . . . . .108
   3.4.4. Route Update Response Time . . . . . . . . . . . . . . . .109
   3.5. ATM Service: ILMI. . . . . . . . . . . . . . . . . . . . . .110
   3.5.1. MIB Alignment Time . . . . . . . . . . . . . . . . . . . .110
   3.5.2. Address Registration Time. . . . . . . . . . . . . . . . .111
   4. Security Considerations  . . . . . . . . . . . . . . . . . . .112
   5. Notices. . . . . . . . . . . . . . . . . . . . . . . . . . . .112
   6. References . . . . . . . . . . . . . . . . . . . . . . . . . .113
   7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .113
   APPENDIX A  . . . . . . . . . . . . . . . . . . . . . . . . . . .114
   APPENDIX B  . . . . . . . . . . . . . . . . . . . . . . . . . . .114
   APPENDIX C  . . . . . . . . . . . . . . . . . . . . . . . . . . .116
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . .127

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.








Dunn & Martin                Informational                      [Page 4]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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.

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.




Dunn & Martin                Informational                      [Page 5]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   *  "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

   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.





Dunn & Martin                Informational                      [Page 6]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


            +-------------+               +-------------+
            |     Test  Tx|-------------->|Rx           |
            |    Device Rx|<--------------|Tx   SUT     |
            |    Tx   Rx  |               |   Tx   Rx   |
            +-------------+               +-------------+
                  |   ^                        |    ^
                  |   |                        |    |
                  |   +------------------------+    |
                  |                                 |
                  |---------------------------------|

                             Figure 2

   3) 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.6. 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.  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.




Dunn & Martin                Informational                      [Page 7]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


2.7. Frame formats

   The formats of the test IP PDUs to use for TCP/IP and UPC/IP over ATM
   are shown in Appendix C: Test Frame Formats.  Note that these IP PDUs
   are in 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.8. 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 44 is recommended to allow direct comparison to token ring
   performance.  The IP PDU size of 4472 is recommended instead of the



Dunn & Martin                Informational                      [Page 8]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.9. 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.10. 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.10.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.

   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





Dunn & Martin                Informational                      [Page 9]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   use, this requires that the test equipment implement the associated
   protocol state machine.  One example of the specific query IP PDU
   (ICMP) that should be used is shown in Appendix C.

2.10.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 one routing update PDU 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.11. 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.

   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.



Dunn & Martin                Informational                     [Page 10]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   The exact filters configuration command lines used SHOULD be included
   with the report of the results.

2.11.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
          ...
         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.







Dunn & Martin                Informational                     [Page 11]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


2.12. 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 A.  IP to ATM
   address mapping MUST be accomplished as described in RFC 2225.

2.13. 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
   (interval and size) and Appendix C (format).

2.14. Bidirectional traffic

   Bidirectional performance tests SHOULD be run with the same data rate
   being offered from each direction.  The sum of the data rates should
   not exceed the theoretical limit for the media.

2.15. 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.






Dunn & Martin                Informational                     [Page 12]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


2.16. 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
      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.









Dunn & Martin                Informational                     [Page 13]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


2.17. 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.18. 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.19. 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 homogeneous
   (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 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.




Dunn & Martin                Informational                     [Page 14]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.20. 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.

2.21. 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.





Dunn & Martin                Informational                     [Page 15]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


2.22. 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.23. Trial duration

   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.24. 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.25. 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.






Dunn & Martin                Informational                     [Page 16]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


2.26. 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

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.







Dunn & Martin                Informational                     [Page 17]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.








Dunn & Martin                Informational                     [Page 18]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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.  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.






Dunn & Martin                Informational                     [Page 19]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.




Dunn & Martin                Informational                     [Page 20]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   9)  Inject one backward payload pointer movement.  Verify that the
       SUT 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.

   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.



Dunn & Martin                Informational                     [Page 21]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.  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.




Dunn & Martin                Informational                     [Page 22]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

   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.




Dunn & Martin                Informational                     [Page 23]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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

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.







Dunn & Martin                Informational                     [Page 24]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.

   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.



Dunn & Martin                Informational                     [Page 25]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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".

   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.






Dunn & Martin                Informational                     [Page 26]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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
   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]).




Dunn & Martin                Informational                     [Page 27]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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".




Dunn & Martin                Informational                     [Page 28]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.







Dunn & Martin                Informational                     [Page 29]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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

   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.




Dunn & Martin                Informational                     [Page 30]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.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.




Dunn & Martin                Informational                     [Page 31]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.




Dunn & Martin                Informational                     [Page 32]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

      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.







Dunn & Martin                Informational                     [Page 33]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.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.

      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




Dunn & Martin                Informational                     [Page 34]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.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]).

   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.





Dunn & Martin                Informational                     [Page 35]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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.

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".





Dunn & Martin                Informational                     [Page 36]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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-
      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                Informational                     [Page 37]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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 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.




Dunn & Martin                Informational                     [Page 38]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.

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.








Dunn & Martin                Informational                     [Page 39]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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:

      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.





Dunn & Martin                Informational                     [Page 40]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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 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.



Dunn & Martin                Informational                     [Page 41]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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:

   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.



Dunn & Martin                Informational                     [Page 42]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.






Dunn & Martin                Informational                     [Page 43]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.



Dunn & Martin                Informational                     [Page 44]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.



Dunn & Martin                Informational                     [Page 45]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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:

   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.





Dunn & Martin                Informational                     [Page 46]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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 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.




Dunn & Martin                Informational                     [Page 47]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   Reporting Format:

      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.  The IP PDUs MUST be encapsulated in AAL5.







Dunn & Martin                Informational                     [Page 48]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

   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



Dunn & Martin                Informational                     [Page 49]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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 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                Informational                     [Page 50]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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 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.



Dunn & Martin                Informational                     [Page 51]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.  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



Dunn & Martin                Informational                     [Page 52]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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:

   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.







Dunn & Martin                Informational                     [Page 53]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.




Dunn & Martin                Informational                     [Page 54]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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".




Dunn & Martin                Informational                     [Page 55]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.  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.



Dunn & Martin                Informational                     [Page 56]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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".

   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



Dunn & Martin                Informational                     [Page 57]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.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:

      The results of the CMR/Bursty VBR Load/One VCC test SHOULD be
      reported in a form of text and graph.



Dunn & Martin                Informational                     [Page 58]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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 greater than 90% of line
       rate.  The PCR, SCR, and MBS must be indicated.  The IP PDUs MUST
       be encapsulated in AAL5.







Dunn & Martin                Informational                     [Page 59]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

   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



Dunn & Martin                Informational                     [Page 60]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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 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.




Dunn & Martin                Informational                     [Page 61]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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.

   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.




Dunn & Martin                Informational                     [Page 62]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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]).

   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.





Dunn & Martin                Informational                     [Page 63]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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 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.





Dunn & Martin                Informational                     [Page 64]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.  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



Dunn & Martin                Informational                     [Page 65]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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 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



Dunn & Martin                Informational                     [Page 66]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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.  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.







Dunn & Martin                Informational                     [Page 67]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


3.2.5.6. CRC-ER/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:

   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.

      The graph results SHOULD display the CRC Error ratio values.



Dunn & Martin                Informational                     [Page 68]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.

   5)  Record the number of CRC errored cells received per VCC on the
       test device.





Dunn & Martin                Informational                     [Page 69]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.

   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.




Dunn & Martin                Informational                     [Page 70]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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



Dunn & Martin                Informational                     [Page 71]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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.

      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.





Dunn & Martin                Informational                     [Page 72]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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 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



Dunn & Martin                Informational                     [Page 73]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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 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.



Dunn & Martin                Informational                     [Page 74]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.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.




Dunn & Martin                Informational                     [Page 75]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.6. Cell Transfer Delay (CTD)

3.2.6.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



Dunn & Martin                Informational                     [Page 76]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.6.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:

   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,



Dunn & Martin                Informational                     [Page 77]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.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.






Dunn & Martin                Informational                     [Page 78]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.6.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]).




Dunn & Martin                Informational                     [Page 79]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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/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.





Dunn & Martin                Informational                     [Page 80]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


3.2.6.5. CTD/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.

   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                Informational                     [Page 81]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.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:

      The results of the CTD/Bursty VBR Load/Twelve VCCs test SHOULD be
      reported in a form of text, graph, and histograms.





Dunn & Martin                Informational                     [Page 82]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.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 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



Dunn & Martin                Informational                     [Page 83]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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.

      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                Informational                     [Page 84]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


3.2.6.8. 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 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                Informational                     [Page 85]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.9. 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 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



Dunn & Martin                Informational                     [Page 86]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.10. 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:

   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.




Dunn & Martin                Informational                     [Page 87]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.

      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.6.11. 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".






Dunn & Martin                Informational                     [Page 88]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

      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.







Dunn & Martin                Informational                     [Page 89]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.12. 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 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.



Dunn & Martin                Informational                     [Page 90]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.6.13. 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]).





Dunn & Martin                Informational                     [Page 91]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.

      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.



Dunn & Martin                Informational                     [Page 92]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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.  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.




Dunn & Martin                Informational                     [Page 93]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


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 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 reassembly 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









Dunn & Martin                Informational                     [Page 94]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


3.3.3. AAL5 CRC Error Ratio.

3.3.3.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.

3.3.3.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.






Dunn & Martin                Informational                     [Page 95]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.  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.3.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.







Dunn & Martin                Informational                     [Page 96]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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/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.3.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



Dunn & Martin                Informational                     [Page 97]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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 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                Informational                     [Page 98]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


3.3.3.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 x-coordinate SHOULD be the test run time in either seconds,
      minutes or days depending on the total length of the test.  The





Dunn & Martin                Informational                     [Page 99]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.3.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                Informational                    [Page 100]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.3.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., [0,5], [0,16]).  The PCR, SCR, and MBS
       must be configured using one of the specified traffic
       descriptors.





Dunn & Martin                Informational                    [Page 101]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 generated bit pattern MUST
      also be indicated.

3.3.3.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".



Dunn & Martin                Informational                    [Page 102]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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



Dunn & Martin                Informational                    [Page 103]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.3.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 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.



Dunn & Martin                Informational                    [Page 104]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


      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.3.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
       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.




Dunn & Martin                Informational                    [Page 105]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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 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.





Dunn & Martin                Informational                    [Page 106]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

      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 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.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



Dunn & Martin                Informational                    [Page 107]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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:

      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



Dunn & Martin                Informational                    [Page 108]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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:

      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



Dunn & Martin                Informational                    [Page 109]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


       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.

   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.





Dunn & Martin                Informational                    [Page 110]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   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.

   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.






Dunn & Martin                Informational                    [Page 111]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   Reporting Format:

      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 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.

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.










Dunn & Martin                Informational                    [Page 112]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


6. References

   [RFC2544]      Bradner, S. and J. McQuaid, "Benchmarking Methodology
                  for Network Interconnect Devices", RFC 2544, March
                  1999.

   [RFC2225]      Laubach, M. and J. Halpern, "Classical IP and ARP over
                  ATM", RFC 2225, April 1998.

   [RFC2761]      Dunn, J. and C. Martin, "Terminology for ATM
                  Benchmarking", RFC 2761, February 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.

   [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.

7. Authors' Addresses

   Jeffrey Dunn
   Advanced Network Consultants, Inc.
   4214 Crest Place
   Ellicott City, MD 21043, USA

   Phone: +1 (410) 750-1700
   EMail: Jeffrey.Dunn@worldnet.att.net


   Cynthia Martin
   Advanced Network Consultants, Inc.
   4214 Crest Place
   Ellicott City, MD 21043, USA

   Phone: +1 (410) 750-1700
   EMail: Cynthia.E.Martin@worldnet.att.net






Dunn & Martin                Informational                    [Page 113]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


Appendix A: Ranges

   ATM NSAP Network Prefix.
     39 0000 0000 0000 0000 0000 0000-39 0000 0000 0000 0000 0000 00FF
     39 0000 0000 0000 0000 0001 0000-39 0000 0000 0000 0000 0001 00FF
     39 0000 0000 0000 0001 0000 0000
     39 0000 0000 0000 0002 0020 0000
     39 0000 0000 0300 0002 0030 0000
     39 0000 0000 4000 0002 0060 0000
     39 0000 0006 0060 0002 0030 0000
     39 0000 0006 0050 0002 0030 0000
     39 0000 0009 0300 0002 0030 0000
     39 0000 00A0 0300 0002 0030 0000
     39 0000 0B00 0300 0002 0030 0000
     39 0000 C000 0300 0002 0030 0000

   ATM NSAP End System Identifier.
     1111 1111 1111 00-1111 1111 11FF 00
     2222 2222 2000 00-2222 2222 2222 00
     9999 999A 0000 00-9999 999C 0000 00

Appendix B: Rates

   PNNI Routing Update Size.

   1) 1 PNNI routing entry update on non-aggregated addresses

   2) 2 PNNI routing entry updates on non-aggregated addresses

   3) 5 PNNI routing entry updates on non-aggregated addresses

   4) 1 % of total available bandwidth or 1 Mb/s, whichever is less on
      non- aggregated addresses

   5) 1 % of total available bandwidth or 1 Mb/s, whichever is less on
      of non-aggregated addresses and of aggregated addresses

   6) 1 % of total available bandwidth or 1 Mb/s, whichever is less on
      aggregated addresses

   7) 2 % of total available bandwidth or 2 Mb/s, whichever is less on
      non- aggregated addresses

   8) 2 % of total available bandwidth or 2 Mb/s, whichever is less on
      of non-aggregated addresses and of aggregated addresses

   9) 2 % of total available bandwidth or 2 Mb/s, whichever is less on
      aggregated addresses



Dunn & Martin                Informational                    [Page 114]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   PNNI Routing Update Repetition Interval.

   Repetition Interval begins after initial PNNI routing table
      stabilizes.

   1) 1 update every 1 hour, for 24 hours

   2) 1 update every 30 minutes, for 24 hours

   3) 1 update every 5 minutes, for 1 hour

   4) 1 update every 1 minute, for 15 minutes

   5) 1 update every 30 seconds, for 5 minutes

   6) 1 update every 30 seconds, for 1 minute

   7) 1 update every 1 second, for 30 seconds

   Maximum WAN Connection rates in packets per second (pps):

                    25.6        OC-3c       OC-12c
   IP Packet Size
   octets/cells
       44/2         30188       176603      706412
       64/2         30188       176603      706412
      128/3         20125       117735      470940
      256/6         10062        58867      235468
    1024/22          2744        16054      64216
    1518/32          1886        11037      44148
    2048/43          1404         8214      32856
    4472/94           642         3757      15028
   9180/192           314         1839       7356

   Maximum LAN Connection rates in packets per second (pps):

                    DS-1       DS-3       E1        E3
   IP Packet Size
   octets/cells
       44/2          1811      52133      2340     40000
       64/2          1811      52133      2340     40000
      128/3          1207      34755      1560     26666
      256/6           603      17377       780     13333
    1024/22           164       4739       212      3636
    1518/32           113       3258       146      2500
    2048/43            84       2424       108      1860
    4472/94            38       1109        49       851
    9180/192           18        543        24       416



Dunn & Martin                Informational                    [Page 115]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   Notes: 1.  PDU size in cells is computed based on ceiling( ( PDU size
   in octets + 16) / 48).  This assumes an 8 octet LLC/SNAP header and
   an 8 octet AAL/5 trailer.

   2.  Due to the number of possible configurations, IMA pps rates are
   not listed, but may be derived from the following formula: floor
   (IDCR/cells per packet), where cells per packet is computed as in
   note 1.

   3. The following cell rates were used: DS-1 = 3622 cps (using ATM TC)
   E1 = 4681 cps 25.6 Mb/s = 60377 cps E3 = 80000 cps (using ATM TC)
   DS-3 = 104266 cps (using ATM TC) OC-3c = 353207 cps OC-12c = 1412828
   cps

Appendix C: PDU's

 TCP/IP over ATM Example 1.
    LLC:    DSAP                        0xAA (SNAP-SAP)
                SSAP                       0xAA (SNAP-SAP)
                Control                    0x03 (Unnumbered Information)
    SNAP: OUI                           0x00-00-00 (Ethertype)
                 PID                       0x0800 (Internet Protocol)
    IP:      Version = 4
             Header length = 20
             Type of service = 0
                 000. .... Precedence = Routine(0)
                 ...0 .... Delay = Normal (0)
                 .... 0... Throughput = Normal (0)
                 .... .0.. Reliability = Normal (0)
             Packet length = 40
             Id = 0
             Fragmentation Info = 0x0000
                 .0.. ....  .... .... Don't Fragment Bit = FALSE
                 ..0. ....  .... .... More Fragments Bit = FALSE
                 ...0 0000  0000 0000 Fragment offset = 0
             Time to live = 255
             Protocol = TCP (6)
             Header checksum = F9CF
             Source address = 15.19.209.236
             Destination address = 15.19.209.237
    TCP:     Source port = smtp (25)
             Destination port = smtp (25)
             Sequence number = 1
             Ack number = 0
             Data offset = 20
             Flags = 0x02
                 ..0. .... URGENT Flag = FALSE
                 ...0 .... ACK Flag = FALSE



Dunn & Martin                Informational                    [Page 116]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


                 .... 0... PUSH Flag = FALSE
                 .... .0.. RST Flag = FALSE
                 .... ..1. SYN Flag = TRUE
                 .... ...0 FIN Flag = FALSE
             Window = 0
             Checksum = EDAF
             Urgent pointer = 00000000

 TCP/IP over ATM Example 2.
LLC:     DSAP                         0xAA (SNAP-SAP)
             SSAP                        0xAA (SNAP-SAP)
             Control                     0x03 (Unnumbered Information)
    SNAP:  OUI                        0x00-00-00 (Ethertype)
             PID                         0x0800 (Internet Protocol)
    IP:      Version = 4
             Header length = 20
             Type of service = 0
                 000. .... Precedence = Routine(0)
                 ...0 .... Delay = Normal (0)
                 .... 0... Throughput = Normal (0)
                 .... .0.. Reliability = Normal (0)
             Packet length = 40
             Id = 0
             Fragmentation Info = 0x0000
                 .0.. ....  .... .... Don't Fragment Bit = FALSE
                 ..0. ....  .... .... More Fragments Bit = FALSE
                 ...0 0000  0000 0000 Fragment offset = 0
             Time to live = 255
             Protocol = TCP (6)
             Header checksum = F9CF
             Source address = 15.19.209.236
             Destination address = 15.19.209.237
    TCP:     Source port = ftp-data (20)
             Destination port = 2000
             Sequence number = 1
             Ack number = 0
             Data offset = 20
             Flags = 0x02
                 ..0. .... URGENT Flag = FALSE
                 ...0 .... ACK Flag = FALSE
                 .... 0... PUSH Flag = FALSE
                 .... .0.. RST Flag = FALSE
                 .... ..1. SYN Flag = TRUE
                 .... ...0 FIN Flag = FALSE
             Window = 0
             Checksum = E5FD
             Urgent pointer = 00000000




Dunn & Martin                Informational                    [Page 117]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


 UDP/IP over ATM Example.
    LLC:    DSAP                        0xAA (SNAP-SAP)
            SSAP                        0xAA (SNAP-SAP)
            Control                     0x03 (Unnumbered Information)
    SNAP:   OUI                         0x00-00-00 (Ethertype)
            PID                         0x0800 (Internet Protocol)
    IP:      Version = 4
             Header length = 20
             Type of service = 0
                 000. .... Precedence = Routine(0)
                 ...0 .... Delay = Normal (0)
                 .... 0... Throughput = Normal (0)
                 .... .0.. Reliability = Normal (0)
             Packet length = 28
             Id = 0
             Fragmentation Info = 0x0000
                 .0.. ....  .... .... Don't Fragment Bit = FALSE
                 ..0. ....  .... .... More Fragments Bit = FALSE
                 ...0 0000  0000 0000 Fragment offset = 0
             Time to live = 255
             Protocol = ICMP (1)
             Header checksum = F9E0
             Source address = 15.19.209.236
             Destination address = 15.19.209.237
    ICMP:    Type = Echo request (8)
             Code = 0
             Checksum = F7FF
             Identifier = 0 (0x0)
             Sequence Number = 0 (0x0)

 RIP Routing Update over ATM.

    -- DATAGRAM HEADER
          offset data (hex)            description
          00     FF FF FF FF FF FF     dest MAC address is broadcast
          06     xx xx xx xx xx xx     source hardware address
          12     08 00                 type

          -- IP HEADER
          14     45                    IP version - 4, header length (4
         byte units) - 5
          15     00                    service field
          16     00 EE                 total length
          18     00 00                 ID
          20     40 00                 flags (3 bits) 4 (do not
         fragment),
                                       fragment offset-0
          22     0A                    TTL



Dunn & Martin                Informational                    [Page 118]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


          23     11                    protocol - 17 (UDP)
          24     C4 8D                 header checksum
          26     xx xx xx xx           source IP address
          30     xx xx xx              destination IP address
          33     FF                    host part = FF for broadcast

          -- UDP HEADER
          34     02 08                 source port 208 = RIP
          36     02 08                 destination port 208 = RIP
          38     00 DA                 UDP message length
          40     00 00                 UDP checksum

          -- RIP packet
          42     02                  command = response
          43     01                  version = 1
          44     00 00               0

          -- net 1
          46     00 02               family = IP
          48     00 00               0
          50     xx xx xx            net 1 IP address
          53     00                  net not node
          54     00 00 00 00         0
          58     00 00 00 00         0
          62     00 00 00 07         metric 7

          -- net 2

          66     00 02               family = IP
          68     00 00               0
          70     xx xx xx            net 2 IP address
          73     00                  net not node
          74     00 00 00 00         0
          78     00 00 00 00         0
          82     00 00 00 07         metric 7

          -- net 3
          86     00 02               family = IP
          88     00 00               0
          90     xx xx xx            net 3 IP address
          93     00                  net not node
          94     00 00 00 00         0
          98     00 00 00 00         0
          102    00 00 00 07         metric 7

          -- net 4
          106    00 02               family = IP
          108    00 00               0



Dunn & Martin                Informational                    [Page 119]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


          110    xx xx xx            net 4 IP address
          113    00                  net not node
          114    00 00 00 00         0
          118    00 00 00 00         0
          122    00 00 00 07         metric 7

          -- net 5
          126    00 02               family = IP
          128    00 00               0
          130    00                  net 5 IP address
          133    00                  net not node
          134    00 00 00 00         0
          138    00 00 00 00         0
          142    00 00 00 07         metric 7

          -- net 6
          146    00 02               family = IP
          148    00 00               0
          150    xx xx xx            net 6 IP address
          153    00                  net not node
          154    00 00 00 00         0
          158    00 00 00 00         0
          162    00 00 00 07         metric 7

   UNI  3.1 Signaling Setup Message Example.  PCR will not allow CAC to
   reject the call.

    Protocol Discriminator    : Q.93B UNI call control
    Call Reference Length     : 3
    Call Reference Flag       : orig
    Call Reference Value      : 0
    Message Type              : SETUP
    Ext                       : last octet
    Action Indicator          : clear call
    Message Length            : 50
    Information Element ID    : ATM Traffic Descriptor
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 9
    Cell Rate Subfield ID     : forward peak CR(CLP=0+1)
    Forward Peak Cell Rate    : 1
    Cell Rate Subfield ID     : backward peak CR(CLP=0+1)
    Backward Peak Cell Rate   : 1
    Cell Rate Subfield ID     : best effort indicator
    Information Element ID    : Broadband Bearer Capability
    Ext                       : last octet
    Coding Standard           : ITU-T standard



Dunn & Martin                Informational                    [Page 120]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


    Action Indicator          : clear call
    IE Length                 : 2
    Ext                       : last octet
    Bearer Class              : BCOB-X
    Ext                       : last octet
    Clipping Susceptibility   : not susceptible to clipping
    User Plane Connection CFG : point-to-point
    Information Element ID    : Called Party Number
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 21
    Ext                       : last octet
    Addressing/Numbering Plan : ISO NSAP addressing
    ISO NSAP Address Octets   : 3900000000000000000000000011111111111100
    Information Element ID    : Quality of Service Parameter
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 2
    QoS Class Forward         : QoS class 0 - unspecified
    QoS Class Backward        : QoS class 0 - unspecified

   UNI 3.1 Signaling Setup Message Reject Example.  PCR  will  allow
   CAC  to reject the call.

    Protocol Discriminator    : Q.93B UNI call control
    Call Reference Length     : 3
    Call Reference Flag       : orig
    Call Reference Value      : 0
    Message Type              : SETUP
    Ext                       : last octet
    Action Indicator          : clear call
    Message Length            : 50
    Information Element ID    : ATM Traffic Descriptor
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 8
    Cell Rate Subfield ID     : forward peak CR(CLP=0+1)
    Forward Peak Cell Rate    : 300000
    Cell Rate Subfield ID     : backward peak CR(CLP=0+1)
    Backward Peak Cell Rate   : 300000
    Information Element ID    : Broadband Bearer Capability
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Flag                      : not significant
    Action Indicator          : clear call



Dunn & Martin                Informational                    [Page 121]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


    IE Length                 : 3
    Ext                       : another octet
    Bearer Class              : BCOB-X
    Ext                       : last octet
    Traffic Type              : constant bit rate
    Timing Requirements       : end-to-end timing required
    Ext                       : last octet
    Clipping Susceptibility   : not susceptible to clipping
    User Plane Connection CFG : point-to-point
    Information Element ID    : Called Party Number
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 21
    Ext                       : last octet
    Addressing/Numbering Plan : ISO NSAP addressing
    ISO NSAP Address Octets   : 3900000000000000000000000011111111111100
    Information Element ID    : Quality of Service Parameter
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 2
    QoS Class Forward         : QoS class 0 - unspecified
    QoS Class Backward        : QoS class 0 - unspecified

   UNI  3.1 Signaling Release Message, specifying a cause code of normal
   call clearing.

    Protocol Discriminator   : Q.93B UNI call control
    Call Reference Length    : 3
    Call Reference Flag      : orig
    Call Reference Value     : 0
    Message Type             : RELEASE
    Ext                      : last octet
    Action Indicator         : clear call
    Message Length           : 6
    Information Element ID   : Cause
    Ext                      : last octet
    Coding Standard          : ITU-T standard
    Action Indicator         : clear call
    IE Length                : 2
    Ext                      : last octet
    Location                 : user
    Ext                      : last octet
    Cause Value              : NE:normal call clearing

   PNNI Signaling Setup Message, specifying a DTL which is not blocked
   by the far end SUT.



Dunn & Martin                Informational                    [Page 122]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


    Protocol Discriminator    : PNNI signalling
    Call Reference Length     : 3
    Call Reference Flag       : from
    Message Type              : SETUP
    Ext                       : last octet
    Pass Along Request        : no pass along request
    Action Indicator          : clear call
    Message Length            : 56
    Information Element ID    : ATM Traffic Descriptor
    Ext                       : last octet
    Coding Standard           : ITU-T standardized
    Pass Along Request        : no pass along request
    Action Indicator          : clear call
    IE Length                 : 0
    Information Element ID    : Broadband Bearer Capability
    Ext                       : last octet
    Coding Standard           : ITU-T standardized
    Pass Along Request        : no pass along request
    Action Indicator          : clear call
    IE Length                 : 3
    Ext                       : another octet
    Bearer Class              : BCOB-X
    Ext                       : last octet
    ATM Transfer Capability   : reserved for bwd compatibility
    Ext                       : last octet
    Clipping Susceptibility   : not susceptible to clipping
    User Plane Connection cfg : point-to-point
    Information Element ID    : Called Party Number
    Ext                       : last octet
    Coding Standard           : ITU-T standardized
    Pass Along Request        : no pass along request
    Action Indicator          : clear call
    IE Length                 : 8
    Ext                       : last octet
    Type of Number            : unknown
    Addressing/Numbering Plan : ATM endsystem address
    ATM Endsystem Address Oct : 11111111111101
    Information Element ID    : Designated Transit List
    Ext                       : last octet
    Coding Standard           : ATM Forum specific
    Pass Along Request        : no pass along request
    Action Indicator          : clear call
    IE Length                 : 29
    Current Transit Pointer   : 0
    Logical Node/Port Indicat : Logical Node/Port Indicator
    Logical Node Identifier   : 3900000000000000000000000011111111111100





Dunn & Martin                Informational                    [Page 123]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   PNNI  Signaling Setup Message Reject, specifying a DTL which is
   blocked by the far end SUT.

Protocol Discriminator      : PNNI signalling
    Call Reference Length   : 3
    Call Reference Flag     : from
    Call Reference Value    : 0
    Message Type            : SETUP
    Ext                     : last octet
    Pass Along Request      : no pass along request
    Action Indicator        : clear call
    Message Length          : 56
    Information Element ID  : ATM Traffic Descriptor
    Ext                     : last octet
    Coding Standard         : ITU-T standardized
    Pass Along Request      : no pass along request
    Action Indicator        : clear call
    IE Length               : 0
    Information Element ID  : Broadband Bearer Capability
    Ext                     : last octet
    Coding Standard         : ITU-T standardized
    Pass Along Request      : no pass along request
    Action Indicator        : clear call
    IE Length               : 3
    Bearer Class            : BCOB-X
    Ext                     : last octet
    ATM Transfer Capability : reserved for bwd compatibility
    Ext                     : last octet
    Clipping Susceptibility : not susceptible to clipping
    User Plane Connection cfg : point-to-point
    Information Element ID  : Called Party Number
    Ext                     : last octet
    Coding Standard         : ITU-T standardized
    Pass Along Request      : no pass along request
    Action Indicator        : clear call
    IE Length               : 8
    Ext                     : last octet
    Addressing/Numbering Plan : ATM endsystem address
    ATM Endsystem Address Oct : 11111111111101
    Information Element ID    : Designated Transit List
    Ext                       : last octet
    Coding Standard           : ATM Forum specific
    Pass Along Request        : no pass along request
    Action Indicator          : clear call
    IE Length                 : 29
    Current Transit Pointer   : 0
    Logical Node/Port Indicat : Logical Node/Port Indicator
    Logical Node Identifier   : 3900000000000000000000000011111111111100



Dunn & Martin                Informational                    [Page 124]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   PNNI Far End Request Message.

Header:  Packet Type                    5 (PTSE REQUEST)
             Packet Length             40
             Protocol Version           1
             Newest Version Supported   1
             Oldest Version Supported   0
             Reserved                   0
    IG:      Information Group Type   513 (Requested PTSE Header)
             Information Group Length  32
             Originating Node ID
                   00013900-00000000-00000000-00000011-11111111-1100
             PTSE Request Count     1
             PTSE Identifier        0

   PNNI PTSE, specifying a routing topology.

Header:  Packet Type                    4 (DATABASE SUMMARY)
             Packet Length             76
             Protocol Version           1
             Newest Version Supported   1
             Oldest Version Supported   0
             Reserved                   0
             Initialize (I)Bit          1 (during init. of DB syn
                                           process)
             More (M)Bit                1 (PTSEs to summarize)
             Master (MS)Bit             1 (both nodes)
             Reserved                   0
             Reserved                   0
             DS Sequence Number         0
    IG:      Information Group Type   512 (Nodal PTSE Summaries)
             Information Group Length  60
             Originating Node ID
                 00013900-00000000-00000000-00000011-11111111-1100
             Originating Node's Peer Group 00000000-00000000-00000000-
                                           0001
             Reserved                    0
             PTSE Summary Count          1
             PTSE Type                   0
             Reserved                    0
             PTSE Identifier             0
             PTSE Sequence Number        0
             PTSE Checksum               0
             PTSE Remaining Lifetime     0







Dunn & Martin                Informational                    [Page 125]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


   PNNI PTSE Update, specifying a change in the routing topology.

Header:  Packet Type                    2 (PTSP)
             Packet Length             96
             Protocol Version           1
             Newest Version Supported   1
             Oldest Version Supported   0
             Reserved                   0
             Originating Node ID
                 00013900-00000000-00000000-00000011-11111111-1100
             Originating Node's Peer Group 00000000-00000000-00000000-
                                           0001
    IG:      Information Group Type     64 (PTSE)
             Information Group Length   52
             PTSE Type                   0
             Reserved                    0
             PTSE Identifier             0
             PTSE Sequence Number        0
             PTSE Checksum           42252
             PTSE Remaining Lifetime  3600
    IG:       Information Group Type   224 (Internal Reachable ATM
                                            Addresses)
             Information Group Length   32
             VP Capability Flag          1 (VPCs supported)
             Reserved                    0
             Reserved                    0
             Port ID                     0
             Scope of Advertisement     96
             Address Information Length 14
             Address Information Count   1
             Prefix Length              13
             Reachable Address Prefix   39000000-00000000-00000000-01



















Dunn & Martin                Informational                    [Page 126]
^L
RFC 3116            Methodology for ATM Benchmarking           June 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Dunn & Martin                Informational                    [Page 127]
^L