Network Working Group                                      J. H. Dunn
INTERNET-DRAFT                                             C. E. Martin
Expires: January, May, 2001                                         ANC, Inc.

                                                           July,

                                                           November, 2000
                     Methodology for ATM Benchmarking
                    <draft-ietf-bmwg-atm-method-02.txt>
                    <draft-ietf-bmwg-atm-method-03.txt>

Status of this Memo

   This  document  is an Internet-Draft and is in full conformance with all
   provisions  of  Section  10  of  RFC2026.  Internet-Drafts  are  working
   documents  of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute  working
   documents as Internet-Drafts.

   Internet-Drafts  are  draft  documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by  other  documents  at  any
   time.   It is inappropriate to use Internet-Drafts as reference material
   or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

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

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.1. Test Device Requirements . . . . . . . . . . . . . . . . 2
   2.2. Systems Under Test (SUTs). . . . . . . . . . . . . . . . 2
   2.3. Test Result Evalutation. . . . . . . . . . . . . . . . . 3
   2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
   2.5. Test Configurations for SONET. . . . . . . . . . . . . . 3
   2.6. SUT Configuration. . . . . . . . . . . . . . . . . . . . 5
   2.7. Frame Formats. . . . . . . . . . . . . . . . . . . . . . 5
   2.8. Frame Sizes. . . . . . . . . . . . . . . . . . . . . . . 6
   2.9. Verifying Received IP PDU's. . . . . . . . . . . . . . . 7
   2.10. Modifiers . . . . . . . . . . . . . . . . . . . . . . . 7
   2.10.1. Management IP PDU's . . . . . . . . . . . . . . . . . 7
   2.10.2. Routing Update IP PDU's . . . . . . . . . . . . . . . 8
   2.11. Filters . . . . . . . . . . . . . . . . . . . . . . . . 8
   2.11.1. Filter Addresses. . . . . . . . . . . . . . . . . . . 9
   2.12. Protocol Addresses. . . . . . . . . . . . . . . . . . . 10
   2.13. Route Set Up. . . . . . . . . . . . . . . . . . . . . . 10
   2.14. Bidirectional Traffic . . . . . . . . . . . . . . . . . 10
   2.15. Single Stream Path. . . . . . . . . . . . . . . . . . . 11
   2.16. Multi-port. . . . . . . . . . . . . . . . . . . . . . . 11
   2.17. Multiple Protocols. . . . . . . . . . . . . . . . . . . 12
   2.18. Multiple IP PDU Sizes . . . . . . . . . . . . . . . . . 12
   2.19. Testing Beyond a Single SUT . . . . . . . . . . . . . . 12
   2.20. Maximum IP PDU Rate . . . . . . . . . . . . . . . . . . 13
   2.21. Busty Traffic . . . . . . . . . . . . . . . . . . . . . 14
   2.22. Trial Description . . . . . . . . . . . . . . . . . . . 14
   2.23. Trial Duration. . . . . . . . . . . . . . . . . . . . . 14
   2.24. Address Resolution. . . . . . . . . . . . . . . . . . . 15
   2.25. Synchronized Payload Bit Pattern. . . . . . . . . . . . 15
   2.26. Burst Traffic Descriptors . . . . . . . . . . . . . . . 15
   3. Performance Metrics. . . . . . . . . . . . . . . . . . . . 16
   3.1. Physical Layer- SONET. . . . . . . . . . . . . . . . . . 16
   3.1.1. Pointer Movements. . . . . . . . . . . . . . . . . . . 16
   3.1.1.1. Pointer Movement Propagation . . . . . . . . . . . . 16
   3.1.1.2. Cell Loss due to Pointer Movement. . . . . . . . . . 17
   3.1.1.3. IP Packet Loss due to Pointer Movement . . . . . . . 19
   3.1.2. Transport Overhead (TOH) Error Count . . . . . . . . . 20
   3.1.2.1. TOH Error Propagation. . . . . . . . . . . . . . . . 20
   3.1.2.2. Cell Loss due to TOH Error . . . . . . . . . . . . . 21
   3.1.2.3. IP Packet Loss due to TOH Error. . . . . . . . . . . 22
   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. . . . . . . . . . . . . . . . . . . . . . . . 26
   3.2.1. Two-Point Cell Delay Variation (CDV) . . . . . . . . . 26
   3.2.2. Cell Error Ratio (CER) . . . . . . . . . . . . . . . . 44
   3.2.3. Cell Loss Ratio (CLR). . . . . . . . . . . . . . . . . 60
   3.2.4. Cell Misinsertion Rate (CMR) . . . . . . . . . . . . . 76
   3.2.5. CRC Error Ratio (CRC-ER) . . . . . . . . . . . . . . . 92
   3.2.6. Cell Transfer Delay (CTD). . . . . . . . . . . . . . . 108
   3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5) . . . . . . . . 125
   3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors. . . . . 125
   3.3.2. AAL5 Re-assembly Time. . . . . . . . . . . . . . . . . 126
   3.3.3. AAL5 CRC Error Ratio . . . . . . . . . . . . . . . . . 127
   3.4. ATM Service: Signaling . . . . . . . . . . . . . . . . . 144
   3.4.1. CAC Denial Time and Connection Establishment Time. . . 144
   3.4.2. Connection Teardown Time . . . . . . . . . . . . . . . 145
   3.4.3. Crankback Time . . . . . . . . . . . . . . . . . . . . 146
   3.4.4. Route Update Response Time . . . . . . . . . . . . . . 147
   3.5. ATM Service: ILMI. . . . . . . . . . . . . . . . . . . . 148
   3.5.1. MIB Alignment Time . . . . . . . . . . . . . . . . . . 148
   3.5.2. Address Registration Time. . . . . . . . . . . . . . . 149
   4. Security Consideration . . . . . . . . . . . . . . . . . . 151
   5. Notices. . . . . . . . . . . . . . . . . . . . . . . . . . 151
   6. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . 151
   7. References . . . . . . . . . . . . . . . . . . . . . . . . 152
   8. Author's Address . . . . . . . . . . . . . . . . . . . . . 153
   APPENDIX A  . . . . . . . . . . . . . . . . . . . . . . . . . 154
   APPENDIX B  . . . . . . . . . . . . . . . . . . . . . . . . . 154
   APPENDIX C  . . . . . . . . . . . . . . . . . . . . . . . . . 156

Abstract

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

   Appendix  A  lists  the  tests  and conditions that we believe should be
   included for specific  cases  and  gives  additional  information  about
   testing practices.

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

1. Introduction.

   This document defines a specific set of tests that vendors  can  use  to
   measure  and  report  the  performance  characteristics  of  ATM network
   devices.  The results of these tests will provide  the  user  comparable
   data  from  different vendors with which to evaluate these devices.  The
   methods defined in  this  memo  are  based  on  RFC  2544  "Benchmarking
   Methodology for Network Interconnect Devices".

   The document "Terminology for ATM Benchmarking" (RFC 2761), defines many
   of the terms that are used in this document.  The  terminology  document
   should be consulted before attempting to make use of this document.

   The   BMWG   produces  two  major  classes  of  documents:  Benchmarking
   Terminology  documents  and  Benchmarking  Methodology  documents.   The
   Terminology  documents  present  the benchmarks and other related terms.
   The Methodology documents define the procedures required to collect  the
   benchmarks cited in the corresponding Terminology documents.

2. Background

2.1. Test Device Requirements

   This  document  is  based  on  the  requirement  that  a  test device is
   available.  The test device can either be off the shelf or can be easily
   built   with   current  technologies.   The  test  device  must  have  a
   transmitting and receiving port for the interface type under test.   The
   test  device  must  be  configured  to transmit test PDUs and to analyze
   received PDUs.  The test device should be able to transmit  and  analyze
   received data at the same time.

2.2. Systems Under Test (SUTs)

   There are a number of tests described in this document that do not apply
   to each SUT. Vendors should  perform  all  of  the  tests  that  can  be
   supported by a specific product type.  It will take some time to perform
   all of the recommended tests under all of the recommended conditions.
   Appendix A lists some of the tests and conditions that we believe should
   be included for specific cases.

2.3. Test Result Evaluation

   Performing all of the tests in this document will result in a great deal
   of  data.  The  applicability  of  this  data  to  the  evaluation  of a
   particular SUT will depend on its expected use and the configuration  of
   the network in which it will be used.  For example, the time required by
   a switch to provide ILMI services will not be a pertinent measurement in
   a  network  that  does  not  use  the ILMI protocol, such as an ATM WAN.
   Evaluating data  relevant  to  a  particular  network  installation  may
   require  considerable  experience,  which  may not be readily available.
   Finally, test selection and evaluation of test results must be done with
   an  understanding  of  generally  accepted  testing  practices regarding
   repeatability, variance and the  statistical  significance  of  a  small
   numbers of trials.

2.4. Requirements

   In  this document, the words that are used to define the significance of
   each particular requirement are capitalized. These words are:

   * "MUST" This word, or the words "REQUIRED" and "SHALL"  mean  that  the
   item is an absolute requirement of the specification.

   * "SHOULD" This word or the adjective "RECOMMENDED" means that there may
   exist valid reasons in particular circumstances to ignore this item, but
   the  full  implications  should  be  understood  and  the case carefully
   weighed before choosing a different course.

   * "MAY" This word or the adjective "OPTIONAL" means that  this  item  is
   truly  optional.   One  vendor  may choose to include the item because a
   particular marketplace requires it or because it enhances  the  product,
   for example; another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more of
   the  MUST  requirements   for   the   protocols   it   implements.    An
   implementation   that   satisfies  all  the  MUST  and  all  the  SHOULD
   requirements  for  its  protocols  is  said   to   be   "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all the
   SHOULD requirements for its  protocols  is  said  to  be  "conditionally
   compliant".

2.5. Test Configurations for SONET

   The   test  device  can  be  connected  to  the  SUT  in  a  variety  of
   configurations   depending   on   the   test   point.    The   following
   configurations will be used for the tests described in this document.

   1)  Uni-directional  connection: The test devices transmit port (labeled
   Tx) is connected to  the  SUT  receive  port  (labeled  Rx).   The  SUTs
   transmit  port  is connected to the test device receive port (see Figure
   1).  In  this  configuration,  the  test  device  can  verify  that  all
   transmitted   packets   are  acknowledged  correctly.   Note  that  this
   configuration does not verify internal system  functions,  but  verifies
   one port on the SUT.

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

                      Figure 1

   2) Bi-directional connection: The test devices first transmit port is
   connected to the SUTs first receive port.  The SUTs first transmit port
   is connected to the test devices first receive port.  The test devices
   second transmit port is connected to the SUTs second receive port.  The
   SUTs second transmit port is connected to the test devices second
   receive port (see Figure 2). In this configuration, the test device can
   determine if all of the transmitted packets were received and forwarded
   correctly.  Note that this configuration does verify internal system
   functions, since it verifies two ports on the SUT.

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

                       Figure 2

   2) Uni-directional passthrough connection: The test devices first
   transmit port is connected to the SUT1 receive port.  The SUT1 transmit
   port is connected to the test devices first receive port. The test
   devices second transmit port is connected to the SUT2 receive port.  The
   SUT2 transmit port is connected to the test devices second receive port
   (see Figure 3). In this configuration, the test device can determine if
   all of the packets transmitted by SUT1 were correctly acknowledged by
   SUT2.  Note that this configuration does not verify internal system
   functions, but verifies one port on each SUT.

   +-------------+           +-------------+           +-------------+
   |           Tx|---------->|Rx         Tx|---------->|Rx           |
   |     SUT1  Rx|<----------|Tx   Test  Rx|<----------|Tx   SUT2    |
   |             |           |    Device   |           |             |
   +-------------+           +-------------+           +-------------+

                              Figure 3

2.5.

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 (See Appendix A).  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.

2.6.

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

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 theoretical FDDI
   maximum size of 4500  octets  in  order  to  permit  the  same  type  of
   comparison.  An  IP  (i.e.  not UDP) IP PDU may be used in addition if a
   higher data rate is desired, in which case the minimum IP PDU size is 28
   octets.

2.8.

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

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

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

2.9.2. 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 two one routing update PDUs  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.10.

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.

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

2.10.1.

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.

2.11.

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

2.12.

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.

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

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.

2.15.

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.

2.16.

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

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

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 homogenous
   (e.g., 64-byte IP, AAL5 PDUs into the SUT; 64 byte IP, AAL5 PDUs out).

   By extending the single SUT test model, reasonable benchmarks  regarding
   multiple  SUTs  or  heterogeneous environments may be collected. In this
   extension, the single SUT is replaced  by  a  system  of  interconnected
   network  SUTs. This test methodology would support the benchmarking of a
   variety of device/media/service/protocol combinations.  For  example,  a
   configuration for a LAN-to-WAN-to-LAN test might be:

       (1) ATM UNI -> SUT 1 -> BISUP -> SUT 2 -> ATM UNI

   Or an extended LAN configuration might be:

       (2) ATM UNI -> SUT 1 -> PNNI Network -> SUT 2 -> ATM UNI

   In  both examples 1 and 2, end-to-end benchmarks of each system could be
   empirically ascertained. Other behavior may be characterized through the
   use of intermediate devices. In example 2, the configuration may be used
   to give an indication of the effect of PNNI routing on IP throughput.

   Because multiple  SUTs  are  treated  as  a  single  system,  there  are
   limitations  to  this  methodology.  For  instance, this methodology may
   yield an aggregate benchmark for a tested system. That benchmark  alone,
   however, may not necessarily reflect asymmetries in behavior between the
   SUTs,  latencies  introduced  by  other  apparatus   (e.g.,   CSUs/DSUs,
   switches), etc.

   Further,  care  must  be  used  when  comparing  benchmarks of different
   systems by ensuring that the SUTs' features  and  configuration  of  the
   tested  systems  have  the  appropriate  common  denominators  to  allow
   comparison.

2.19.

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

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.

2.21.

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

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

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

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.

2.25.

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.

   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.

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.

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.

   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.

   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.

   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.

   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.

   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.

   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.

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

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

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.

   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.

   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.

   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.

   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.

   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  each  VCC
   during  the  test  in positive integers, maximum and minimum CDV on each
   VCC during the test in us, and peak-to-peak CDV on each VCC in us.

   The graph results SHOULD display the cell delay values.  There  will  be
   (Max  number  of  VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the cell  delay  for
   each  VCC  in us.  There SHOULD be no more than 10 curves on each graph,
   one curve indicated and labeled for each VCC. The integration  time  per
   point MUST be indicated.

   The histograms SHOULD display the peak-to-peak cell delay. There will be
   one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
   us  with  at  least  256 bins.  The y-coordinate SHOULD be the number of
   cells observed in each bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.1.5. Two-point CDV/Bursty UBR Load/One VCC

Objective: To determine the SUT variation in cell transfer delay  with  one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device  with  one  VCC.   The  VCC  SHOULD
   contain  one  VPI/VCI.  The  VCC MUST be configured as a UBR connection.
   The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
   [0,5], [0,16]).

   3)  Send  a  specific  number  of  IP packets containing timestamps at a
   specific UBR through the SUT via the defined test VCC.  Since this  test
   is  not  a  throughput  test, the rate should not be greater than 90% of
   line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

   5) Record the packets timestamps at the transmitter and receiver ends of
   the test device.

Reporting Format:

   The results of the Two-point CDV/Bursty UBR Load/One VCC test SHOULD  be
   reported in a form of text, graph, and histogram.

   The  text  results  SHOULD display the numerical values of the CDV.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, maximum  and  minimum  CDV
   during the test in us, and peak-to-peak CDV in us.

   The  graph  results  SHOULD  display  the  cell  delay  values.   The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the  cell  delay  in
   us.  The integration time per point MUST be indicated.

   The  histogram  results SHOULD display the peak-to-peak cell delay.  The
   x- coordinate SHOULD be the cell delay in us with  at  least  256  bins.
   The y- coordinate SHOULD be the number of cells observed in each bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The  VCC  and  VPI/VCI values MUST be indicated. The bearer class of the
   created VCC MUST also be indicated.

3.2.1.6. Two-point CDV/Bursty UBR Load/Twelve VCCs

Objective: To determine the SUT  variation  in  cell  transfer  delay  with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with twelve VCCs, using 1  VPI  and
   12 VCIs. The VCC's MUST be configured as a UBR connection.  The VPI/VCIs
   MUST not be one of the reserved  ATM  signaling  channels  (e.g.  [0,5],
   [0,16]).

   3)  Send  a  specific  number  of  IP packets containing timestamps at a
   specific UBR through the SUT via the defined  test  VCCs.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the packets timestamps at the transmitter and receiver ends of
   the test device for all VCCs.

Reporting Format:

   The results of the Two-point CDV/Bursty UBR Load/Twelve VCCs test SHOULD
   be reported in a form of text, graph, and histograms.

   The text results SHOULD display the numerical values of  the  CDV.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   values, total number of cells  transmitted  and  received  on  each  VCC
   during  the  test  in positive integers, maximum and minimum CDV on each
   VCC during the test in us, and peak-to-peak CDV on each VCC in us.

   The graph  results  SHOULD  display  the  cell  delay  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.  The y-coordinate SHOULD be the cell delay for
   each VCC in ms.  There SHOULD be 12 curves  on  the  graph,  one  curves
   indicated  and labeled for each VCC. The integration time per point MUST
   be indicated.

   The histograms SHOULD display the peak-to-peak cell delay. There will be
   one  histogram  for each VCC.  The x-coordinate SHOULD be the cell delay
   in us with at least 256 bins.  The y-coordinate SHOULD be the number  of
   cells observed in each bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The  VCC  and  VPI/VCI values MUST be indicated. The bearer class of the
   created VCC MUST also be indicated.

3.2.1.7. Two-point CDV/Bursty UBR Load/Maximum VCCs

Objective: To determine the SUT variation in cell transfer delay  with  the
maximum   number  VCCs  supported  on  the  SUT  as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and test device with the maximum number of VCCs
   supported on the SUT.  For  example,  if  the  maximum  number  of  VCCs
   supported  on  the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
   VCC MUST be configured as a UBR connection.  The VPI/VCIs  MUST  not  be
   one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3)  Send  a  specific  number  of  IP packets containing timestamps at a
   specific UBR through the SUT via the defined  test  VCCs.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the packets timestamps at the transmitter and receiver ends of
   the test device for all VCCs.

Reporting Format:

   The  results  of  the  Two-point  CDV/Bursty  UBR Load/Maximum VCCs test
   SHOULD be reported in a form of text, graphs, and histograms.

   The text results SHOULD display the numerical values of  the  CDV.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   values, total number of cells  transmitted  and  received  on  each  VCC
   during  the  test  in positive integers, maximum and minimum CDV on each
   VCC during the test in us, and peak-to-peak CDV on each VCC in us.

   The graph results SHOULD display the cell delay values.  There  will  be
   (Max  number  of  VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the cell  delay  for
   each  VCC  in us.  There SHOULD be no more than 10 curves on each graph,
   one curve indicated and labeled for each VCC. The integration  time  per
   point MUST be indicated.

   The histograms SHOULD display the peak-to-peak cell delay. There will be
   one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
   us  with  at  least  256 bins.  The y-coordinate SHOULD be the number of
   cells observed in each bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The bearer  class  of  the
   created VCC MUST also be indicated.

3.2.1.8. Two-point CDV/Mixed Load/Three VCC's

Objective: To determine the SUT variation in cell transfer delay with three
VCC's as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2) Configure the SUT and test device with three VCC's.  Each VCC MUST be
   defined as a different Bearer class: one CBR, one UBR and one VBR.  Each
   VCC  SHOULD  contain  one  VPI/VCI.   The VPI/VCI MUST not be one of the
   reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets  containing  timestamps  through
   the  SUT via the defined test VCCs. Each generated VCC stream MUST match
   the corresponding VCC Bearer class.   All  of  the  VPI/VCI  pairs  will
   generate  traffic  at  the  same traffic rate.  Since this test is not a
   throughput test, the rate should not be greater than 90% of  line  rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the packets timestamps at the transmitter and receiver ends of
   the test device for all VCC's.

Reporting Format:

   The  results  of  the  Two-point CDV/Mixed Load/Three VCC test SHOULD be
   reported in a form of text, graph, and histogram.

   The text results SHOULD display the numerical values of  the  CDV.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI  during  the  test in positive integers, maximum and minimum CDV
   during the test in us, and peak-to-peak CDV in us.

   The graph  results  SHOULD  display  the  cell  delay  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The y-coordinate SHOULD be the cell delay in
   us.  The integration time per point MUST be indicated.

   The histogram results SHOULD display the peak-to-peak cell  delay.   The
   x-  coordinate  SHOULD  be  the cell delay in us with at least 256 bins.
   The y- coordinate SHOULD be the number of cells observed in each bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.1.9. Two-point CDV/Mixed Load/Twelve VCCs

Objective: To determine the SUT  variation  in  cell  transfer  delay  with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:
   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with twelve VCC's.  Each  VCC  MUST
   be  defined  as  one of the Bearer classes for a total of four CBR, four
   UBR and four VBR VCC's.  Each  VCC  SHOULD  contain  one  VPI/VCI.   The
   VPI/VCI  MUST  not  be  one of the reserved ATM signaling channels (e.g.
   [0,5], [0,16]).

   3) Send a specific number of IP packets  containing  timestamps  through
   the  SUT via the defined test VCCs. Each generated VCC stream MUST match
   the corresponding VCC Bearer class.   All  of  the  VPI/VCI  pairs  will
   generate  traffic  at  the  same traffic rate.  Since this test is not a
   throughput test, the rate should not be greater than 90% of  line  rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the packets timestamps at the transmitter and receiver ends of
   the test device for all VCCs.

Reporting Format:

   The  results  of the Two-point CDV/Mixed Load/Twelve VCCs test SHOULD be
   reported in a form of text, graph, and histograms.

   The text results SHOULD display the numerical values of  the  CDV.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   values, total number of cells  transmitted  and  received  on  each  VCC
   during  the  test  in positive integers, maximum and minimum CDV on each
   VCC during the test in us, and peak-to-peak CDV on each VCC in us.

   The graph  results  SHOULD  display  the  cell  delay  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.  The y-coordinate SHOULD be the cell delay for
   each VCC in ms.  There SHOULD be 12 curves  on  the  graph,  one  curves
   indicated  and labeled for each VCC. The integration time per point MUST
   be indicated.

   The histograms SHOULD display the peak-to-peak cell delay. There will be
   one  histogram  for each VCC.  The x-coordinate SHOULD be the cell delay
   in us with at least 256 bins.  The y-coordinate SHOULD be the number  of
   cells observed in each bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.1.10. Two-point CDV/Mixed Load/Maximum VCCs

Objective:  To  determine the SUT variation in cell transfer delay with the
maximum  number  VCCs  supported  on  the  SUT  as  defined  in  RFC   2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT  and  test  device  with  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI.  Each
   VCC  MUST  be  defined  as one of the Bearer classes for a total of (max
   VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's.  If  the  maximum
   number  of  VCC's is not divisible by 3, the total for each bearer class
   MUST be within 3 VCC's of each other.  The VPI/VCI MUST not  be  one  of
   the reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3)  Send  a  specific number of IP packets containing timestamps through
   the SUT via the defined test VCCs. Each generated VCC stream MUST  match
   the  corresponding  VCC  Bearer  class.   All  of the VPI/VCI pairs will
   generate traffic at the same traffic rate.  Since this  test  is  not  a
   throughput  test,  the rate should not be greater than 90% of line rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5) Record the packets timestamps at the transmitter and receiver ends of
   the test device for all VCCs.

Reporting Format:

   The results of the Two-point CDV/Mixed Load/Maximum VCCs test SHOULD  be
   reported in a form of text, graphs, and histograms.

   The  text  results  SHOULD display the numerical values of the CDV.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   values,  total  number  of  cells  transmitted  and received on each VCC
   during the test in positive integers, maximum and minimum  CDV  on  each
   VCC during the test in us, and peak-to-peak CDV on each VCC in us.

   The  graph  results SHOULD display the cell delay values.  There will be
   (Max number of VCCs/10) graphs, with 10 VCCs indicated  on  each  graph.
   The  x-coordinate SHOULD be the test run time in either seconds, minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD  be  configurable.  The y-coordinate SHOULD be the cell delay for
   each VCC in us.  There SHOULD be no more than 10 curves on  each  graph,
   one  curve  indicated and labeled for each VCC. The integration time per
   point MUST be indicated.

   The histograms SHOULD display the peak-to-peak cell delay. There will be
   one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
   us with at least 256 bins.  The y-coordinate SHOULD  be  the  number  of
   cells observed in each bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.2. Cell Error Ratio (CER)

3.2.2.1. Test Setup

   The  cell  error ratio measurements assume that both the transmitter and
   receiver payload information is synchronized.  Synchronization  MUST  be
   achieved  by  supplying  a known bit pattern to both the transmitter and
   receiver.  If this bit pattern is  longer  than  the  packet  size,  the
   receiver  MUST synchronize with the transmitter before tests can be run.

3.2.2.2. CER/Steady Load/One VCC

Objective: To determine the SUT ratio of errored cells  on  one  VCC  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device with one VCC.  The VCC SHOULD
   contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
   UBR  connection.   The  VPI/VCI  MUST  not  be  one  of the reserved ATM
   signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  at  a  constant rate through the SUT via the defined test
   VCC.  Since this test is not a throughput test, the rate should  not  be
   greater  than  90%  of  line  rate.  The IP PDUs MUST be encapsulated in
   AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device.

Reporting Format:

   The results of the CER/Steady Load/One VCC test SHOULD be reported in  a
   form of text and graph.

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The  graph  results  SHOULD display the cell error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.   The  y-coordinate  SHOULD  be  the  CER.   The
   integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created  VCC  MUST  be  indicated.
   The generated bit pattern MUST also be indicated.

3.2.2.3. CER/Steady Load/Twelve VCCs

Objective:  To determine the SUT ratio of errored cells on twelve VCCs in a
transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with twelve VCCs, using 1  VPI  and
   12  VCIs.  The  VCC's  MUST  be  configured as either a CBR, VBR, or UBR
   connection.  The VPI/VCIs MUST not be one of the reserved ATM  signaling
   channels (e.g. [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a constant rate through the SUT  via  the  defined  test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than  90%  of  line  rate.  The IP PDUs MUST be encapsulated in
   AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the CER/Steady Load/Twelve VCCs test SHOULD  be  reported
   in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The  graph  results  SHOULD display the cell error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CER  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.4. CER/Steady Load/Maximum VCCs

Objective:  To  determine  the  SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC's  MUST  be configured as either a CBR, VBR, or UBR connection.  The
   VPI/VCIs MUST not be one of the reserved ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a constant rate through the SUT  via  the  defined  test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than  90%  of  line  rate.  The IP PDUs MUST be encapsulated in
   AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the CER/Steady Load/Maximum VCCs test SHOULD be  reported
   in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio values. There will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The  x-coordinate SHOULD be the test run time in either seconds, minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CER for each
   VCC.  There SHOULD be no more than 10 curves on each  graph,  one  curve
   indicated  and labeled for each VCC. The integration time per point MUST
   be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.5. CER/Bursty VBR Load/One VCC

Objective: To determine the SUT ratio of errored cells  on  one  VCC  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device with one VCC.  The VCC SHOULD
   contain one VPI/VCI. The VCC MUST be configured as either a CBR  or  VBR
   connection.   The  VPI/VCI MUST not be one of the reserved ATM signaling
   channels  (e.g.   [0,5],  [0,16]).   The  PCR,  SCR,  and  MBS  must  be
   configured using one of the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific VBR rate through the SUT via the defined test
   VCC.   Since  this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of bit errors at  the  receiver  end  of  the  test
   device.

Reporting Format:

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

   The text results SHOULD display the numerical values of  the  CER.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate  SHOULD  be  the CER.  The
   integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.6. CER/Bursty VBR Load/Twelve VCCs

Objective: To determine the SUT ratio of errored cells on twelve VCCs in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
   The  VPI/VCIs  MUST  not  be  one of the reserved ATM signaling channels
   (e.g.  [0,5], [0,16]). The PCR, SCR, and MBS must  be  configured  using
   one of the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific VBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than 90% of line rate. The PCR, SCR, and MBS must be indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

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

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The  graph  results  SHOULD display the cell error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CER  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.7. CER/Bursty VBR Load/Maximum VCCs

Objective:  To  determine  the  SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC's  MUST  be  configured  as  either  a  CBR or VBR connection.   The
   VPI/VCIs MUST not be one of the reserved ATM  signaling  channels  (e.g.
   [0,5],  [0,16]).  The  PCR, SCR, and MBS must be configured using one of
   the specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit patterns at a specific VBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.   Since this test is not a throughput test, the rate should not be
   greater than 90% of line rate.  The IP  PDUs  MUST  be  encapsulated  in
   AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of bit errors at  the  receiver  end  of  the  test
   device for all VCCs.

Reporting Format:

   The  results  of  the  CER/Bursty  VBR  Load/Maximum VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CER.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio values. There will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CER  for  each
   VCC.   There  SHOULD  be no more than 10 curves on each graph, one curve
   indicated and labeled for each VCC. The integration time per point  MUST
   be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.5. CER/Bursty UBR Load/One VCC

Objective:  To  determine  the  SUT  ratio of errored cells on one VCC in a
transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device  with  one  VCC.   The  VCC  SHOULD
   contain  one  VPI/VCI.  The  VCC MUST be configured as a UBR connection.
   The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
   [0,5],  [0,16]).   The PCR, SCR, and MBS must be configured using one of
   the specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit patterns at a specific UBR rate through the SUT via the defined test
   VCC.  Since this test is not a throughput test, the rate should  not  be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device.

Reporting Format:

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

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The  graph  results  SHOULD display the cell error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.   The  y-coordinate  SHOULD  be  the  CER.   The
   integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.6. CER/Bursty UBR Load/Twelve VCCs

Objective:  To determine the SUT ratio of errored cells on twelve VCCs in a
transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with twelve VCCs, using 1  VPI  and
   12 VCIs. The VCC's MUST be configured as a UBR connection.  The VPI/VCIs
   MUST not be one of the reserved  ATM  signaling  channels  (e.g.  [0,5],
   [0,16]).  The  PCR,  SCR,  and  MBS  must be configured using one of the
   specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit patterns at a specific UBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.   Since this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The PCR, SCR, and MBS must be  indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of bit errors at  the  receiver  end  of  the  test
   device for all VCCs.

Reporting Format:

   The  results  of  the  CER/Bursty  UBR  Load/Twelve  VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CER.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CER for each
   VCC.  There should be 12 curves on the graph,  on  curve  indicated  and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.2.7. CER/Bursty UBR Load/Maximum VCCs

Objective: To determine the SUT ratio of errored  cells  with  the  maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and test device with the maximum number of VCCs
   supported on the SUT.  For  example,  if  the  maximum  number  of  VCCs
   supported  on  the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
   VCC's MUST be configured as a UBR connection.   The VPI/VCIs MUST not be
   one  of  the  reserved  ATM signaling channels (e.g. [0,5], [0,16]). The
   PCR, SCR, and MBS must be configured using one of the specified  traffic
   descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific UBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than  90%  of  line  rate.  The IP PDUs MUST be encapsulated in
   AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the CER/Bursty  UBR  Load/Maximum  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio values. There will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The  x-coordinate SHOULD be the test run time in either seconds, minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CER for each
   VCC.  There SHOULD be no more than 10 curves on each  graph,  one  curve
   indicated  and labeled for each VCC. The integration time per point MUST
   be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.1.8. CER/Mixed Load/Three VCC's

Objective: To determine the SUT ratio of errored cells with the three  VCCs
supported  on the SUT in relation to the total cells sent as defined in RFC
2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2) Configure the SUT and test device with three VCC's.  Each VCC MUST be
   defined as a different Bearer class; one CBR, one UBR and one VBR.  Each
   VCC  SHOULD  contain  one  VPI/VCI.   The VPI/VCI MUST not be one of the
   reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of bit errors at  the  receiver  end  of  the  test
   device for all VCCs.

Reporting Format:

   The  results  of  the  CER/Bursty  Mixed  Load/Three VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CER.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CER for each
   VCC.  There should be 12 curves on the graph,  on  curve  indicated  and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.1.9. CER/Mixed Load/Twelve VCCs

Objective: To determine the SUT ratio of errored  cells  with  the  maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:
   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCC's.  Each VCC MUST
   be defined as one of the Bearer classes for a total of  four  CBR,  four
   UBR  and  four  VBR  VCC's.   Each  VCC SHOULD contain one VPI/VCI.  The
   VPI/VCI MUST not be one of the reserved  ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns through the SUT via the defined test VCCs.  Each  generated
   VCC  stream  MUST  match the corresponding VCC Bearer class.  All of the
   VPI/VCI pairs will generate traffic at the  same  traffic  rate.   Since
   this  test is not a throughput test, the rate should not be greater than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number  of  bit  errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the CER/Bursty Mixed  Load/Twelve  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The  graph  results  SHOULD display the cell error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CER  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.1.10. CER/Mixed Load/Maximum VCCs

Objective:  To  determine  the  SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT  and  test  device  with  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI.  Each
   VCC  MUST  be  defined  as one of the Bearer classes for a total of (max
   VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI  MUST
   not  be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of bit errors at  the  receiver  end  of  the  test
   device for all VCCs.

Reporting Format:

   The  results  of  the  CER/Bursty Mixed Load/Maximum VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CER.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CER for the entire
   test.

   The graph results SHOULD display the cell error ratio values. There will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CER  for  each
   VCC.   There  SHOULD  be no more than 10 curves on each graph, one curve
   indicated and labeled for each VCC. The integration time per point  MUST
   be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.2.3. Cell Loss Ratio (CLR)

3.2.3.1. CLR/Steady Load/One VCC

Objective:  To  determine  the  SUT  ratio  of  lost  cells on one VCC in a
transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device  with  one  VCC.   The  VCC  SHOULD
   contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
   UBR connection. The  VPI/VCI  MUST  not  be  one  of  the  reserved  ATM
   signaling channels (e.g. [0,5], [0,16]).

   3)  Send  a  specific  number  of IP packets at a specific constant rate
   through the SUT via the defined test VCC.  Since  this  test  is  not  a
   throughput  test,  the rate should not be greater than 90% of line rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

   5)  Record  the  number  of  cells  transmitted and received on the test
   device.

Reporting Format:

   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.

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

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.

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

   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.3.4. CLR/Bursty UBR Load/One VCC

Objective: To determine the SUT ratio  of  lost  cells  on  one  VCC  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device with one VCC.  The VCC SHOULD
   contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
   VPI/VCI  MUST  not  be  one of the reserved ATM signaling channels (e.g.
   [0,5], [0,16]).  The PCR, SCR, and MBS must be configured using  one  of
   the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific rate through the SUT  via  the  defined  test
   VCC.   Since  this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of cells  transmitted  and  received  on  the  test
   device.

Reporting Format:

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

   The text results SHOULD display the numerical values of  the  CLR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CLR for the entire
   test.

   The graph results SHOULD display the Cell Loss  ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate  SHOULD  be  the CLR.  The
   integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.3.5. CLR/Bursty UBR Load/Twelve VCCs

Objective: To determine the SUT ratio of lost cells on  twelve  VCCs  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC MUST be configured as a UBR  connection.  The  VPI/VCIs
   MUST  not  be  one  of  the reserved ATM signaling channels (e.g. [0,5],
   [0,16]).  The PCR, SCR, and MBS must be  configured  using  one  of  the
   specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific rate through the SUT  via  the  defined  test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than 90% of line rate. The PCR, SCR, and MBS must be indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number of cells transmitted and received per VCC on the
   test device.

Reporting Format:

   The results of the  CLR/Bursty  UBR  Load/Twelve  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CLR.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CLR for the entire
   test.

   The  graph  results  SHOULD  display the Cell Loss ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CLR  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.3.6. CLR/Bursty UBR Load/Maximum VCCs

Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total  cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be one
   of the reserved ATM signaling channels (e.g. [0,5],  [0,16]).  The  PCR,
   SCR,  and  MBS  must  be  configured  using one of the specified traffic
   descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  at  a  specific rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.   Since this test is not a throughput test, the rate should not be
   greater than 90% of line rate.  The IP  PDUs  MUST  be  encapsulated  in
   AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of cells transmitted and received per  VCC  on  the
   test device.

Reporting Format:

   The  results  of  the  CLR/Bursty  UBR  Load/Maximum VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CLR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CLR for the entire
   test.

   The graph results SHOULD display the Cell Loss ratio values. There  will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CLR  for  each
   VCC.   There  SHOULD  be no more than 10 curves on each graph, one curve
   indicated and labeled for each VCC. The integration time per point  MUST
   be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.3.4. CLR/Bursty Mixed Load/Three VCC

Objective:  To  determine  the  SUT  ratio  of lost cells on three VCC's in
relation to the total cells sent as defined in RFC  2761  "Terminology  for
ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with three VCC's.  Each VCC MUST be
   defined as a different Bearer class; one CBR, one UBR and one VBR.  Each
   VCC SHOULD contain one VPI/VCI.  The VPI/VCI MUST  not  be  one  of  the
   reserved  ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
   MBS must be configured using one of the specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of cells transmitted and received per  VCC  on  the
   test device.

Reporting Format:

   The  results  of  the  CLR/Bursty  Mixed  Load/Three  VCC test SHOULD be
   reported in in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CLR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CLR for the entire
   test.

   The graph results SHOULD display the Cell Loss  ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CLR for each
   VCC.  There should be 12 curves on the graph,  on  curve  indicated  and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.3.5. CLR/Bursty Mixed Load/Twelve VCCs

Objective: To determine the SUT ratio of lost cells on  twelve  VCCs  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCC's.  Each VCC MUST
   be defined as one of the Bearer classes for a total of  four  CBR,  four
   UBR  and  four  VBR  VCC's.   Each  VCC SHOULD contain one VPI/VCI.  The
   VPI/VCI MUST not be one of the reserved  ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns through the SUT via the defined test VCCs.  Each  generated
   VCC  stream  MUST  match the corresponding VCC Bearer class.  All of the
   VPI/VCI pairs will generate traffic at the  same  traffic  rate.   Since
   this  test is not a throughput test, the rate should not be greater than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record  the  number of cells transmitted and received per VCC on the
   test device.

Reporting Format:

   The results of the CLR/Bursty Mixed  Load/Twelve  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CLR.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CLR for the entire
   test.

   The  graph  results  SHOULD  display the Cell Loss ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CLR  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.3.6. CLR/Bursty Mixed Load/Maximum VCCs

Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total  cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT  and  test  device  with  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI.  Each
   VCC  MUST  be  defined  as one of the Bearer classes for a total of (max
   VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI  MUST
   not  be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of cells transmitted and received per  VCC  on  the
   test device.

Reporting Format:

   The  results  of  the  CLR/Bursty Mixed Load/Maximum VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CLR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CLR for the entire
   test.

   The graph results SHOULD display the Cell Loss ratio values. There  will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CLR  for  each
   VCC.   There  SHOULD  be no more than 10 curves on each graph, one curve
   indicated and labeled for each VCC. The integration time per point  MUST
   be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.4. Cell Misinsertion Rate (CMR)

3.2.4.1. CMR/Steady Load/One VCC

Objective:  To determine the SUT ratio of cell misinsertion on one VCC in a
transmission in relation to the total cells sent as  defined  in  RFC  2761

"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with  one  VCC.  The  VCC  MUST  be
   configured  as  either  a  CBR,  VBR,  or UBR connection. The VCC SHOULD
   contain one VPI/VCI.  The VPI/VCI MUST not be one of  the  reserved  ATM
   signaling channels (e.g. [0,5], [0,16]).

   3)  Send  a  specific  number  of IP packets at a specific constant rate
   through the SUT via the defined test VCC.  Since  this  test  is  not  a
   throughput  test,  the rate should not be greater than 90% of line rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

   5)  Record the number of cell misinsertion errors at the receiver end of
   the test device.

Reporting Format:

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

   The  text  results  SHOULD display the numerical values of the CMR.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display the Cell misinsertion rate values.  The
   x-coordinate SHOULD be the test run time in either seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.   The  y-coordinate  SHOULD  be  the  CMR.   The
   integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.4.2. CMR/Steady Load/Twelve VCCs

Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with twelve VCCs, using 1  VPI  and
   12  VCIs.  The  VCC's  MUST  be  configured as either a CBR, VBR, or UBR
   connection. The VPI/VCIs MUST not be one of the reserved  ATM  signaling
   channels (e.g. [0,5], [0,16]).

   3)  Send  a  specific  number  of IP packets at a specific constant rate
   through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
   generate  traffic  at  the  same traffic rate.  Since this test is not a
   throughput test, the rate should not be greater than 90% of  line  rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of cell misinsertion errors at the receiver end  of
   the test device per VCC.

Reporting Format:

   The  results  of the CMR/Steady Load/Twelve VCCs test SHOULD be reported
   in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CMR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display the Cell misinsertion rate values.  The
   x-coordinate  SHOULD  be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD be configurable. The y-coordinate SHOULD be the CMR for each VCC.
   There should be 12 curves on the graph, on curve indicated  and  labeled
   for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.4.3. CMR/Steady Load/Maximum VCCs

Objective:  To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC's  MUST  be configured as either a CBR, VBR, or UBR connection.  The
   VPI/VCIs MUST not be one of the reserved ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send  a  specific  number  of IP packets at a specific constant rate
   through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
   generate  traffic  at  the  same traffic rate.  Since this test is not a
   throughput test, the rate should not be greater than 90% of  line  rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of cell misinsertion errors at the receiver end  of
   the test device per VCC.

Reporting Format:

   The  results of the CMR/Steady Load/Maximum VCCs test SHOULD be reported
   in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CMR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display  the  Cell  misinsertion  rate  values.
   There  will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
   each graph.  The x-coordinate SHOULD be the  test  run  time  in  either
   seconds,  minutes or days depending on the total length of the test. The
   x- coordinate time SHOULD be configurable.  The y-coordinate  SHOULD  be
   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.

   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.

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

3.2.4.4. CMR/Bursty UBR Load/One VCC

Objective: To determine the SUT rate of misinserted cells on one VCC  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device with one VCC.  The VCC SHOULD
   contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
   VPI/VCI  MUST  not  be  one of the reserved ATM signaling channels (e.g.
   [0,5], [0,16]).  The PCR, SCR, and MBS must be configured using  one  of
   the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific rate through the SUT  via  the  defined  test
   VCC.   Since  this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of cell misinsertion errors at the receiver end  of
   the test device.

Reporting Format:

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

   The text results SHOULD display the numerical values of  the  CMR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display the Cell misinsertion rate values.  The
   x-coordinate  SHOULD  be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate  SHOULD  be  the CMR.  The
   integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.4.5. CMR/Bursty UBR Load/Twelve VCCs

Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a  transmission  in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC's MUST be configured as a UBR connection. The  VPI/VCIs
   MUST  not  be  one  of  the reserved ATM signaling channels (e.g. [0,5],
   [0,16]). The PCR, SCR, and MBS must  be  configured  using  one  of  the
   specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific rate through the SUT  via  the  defined  test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than 90% of line rate. The PCR, SCR, and MBS must be indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of cell misinsertion errors at the receiver end of
   the test device per VCC.

Reporting Format:

   The results of the  CMR/Bursty  UBR  Load/Twelve  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CMR.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display the Cell misinsertion rate values.  The
   x-coordinate SHOULD be the test run time in either seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CMR  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.4.6. CMR/Bursty UBR Load/Maximum VCCs

Objective:  To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC's  MUST  be configured as a UBR connection. The VPI/VCIs MUST not be
   one of the reserved ATM signaling channels  (e.g.  [0,5],  [0,16]).  The
   PCR,  SCR, and MBS must be configured using one of the specified traffic
   descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  at  a  specific rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.   Since this test is not a throughput test, the rate should not be
   greater than 90% of line rate.  The IP  PDUs  MUST  be  encapsulated  in
   AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of cell misinsertion errors at the receiver end  of
   the test device per VCC.

Reporting Format:

   The  results  of  the  CMR/Bursty  UBR  Load/Maximum VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CMR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display  the  Cell  misinsertion  rate  values.
   There  will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
   each graph.  The x-coordinate SHOULD be the  test  run  time  in  either
   seconds,  minutes or days depending on the total length of the test. The
   x- coordinate time SHOULD be configurable.  The y-coordinate  SHOULD  be
   the  CMR  for  each  VCC. There SHOULD be no more than 10 curves on each
   graph, one curve indicated and labeled for  each  VCC.  The  integration
   time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.4.4. CMR/Bursty Mixed Load/Three VCC

Objective: To determine the SUT rate of misinserted cells on three VCC's in
relation to the total cells sent as defined in RFC  2761  "Terminology  for
ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with three VCC's.  Each VCC MUST be
   defined as a different Bearer class; one CBR, one UBR and one VBR.  Each
   VCC SHOULD contain one VPI/VCI.  The VPI/VCI MUST  not  be  one  of  the
   reserved  ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
   MBS must be configured using one of the specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of cell misinsertion errors at the receiver end  of
   the test device.

Reporting Format:

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

   The text results SHOULD display the numerical values of  the  CMR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display the Cell misinsertion rate values.  The
   x-coordinate  SHOULD  be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CMR for each
   VCC.  There should be 12 curves on the graph,  on  curve  indicated  and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.4.5. CMR/Bursty Mixed Load/Twelve VCCs

Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a  transmission  in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCC's.  Each VCC MUST
   be defined as one of the Bearer classes for a total of  four  CBR,  four
   UBR  and  four  VBR  VCC's.   Each  VCC SHOULD contain one VPI/VCI.  The
   VPI/VCI MUST not be one of the reserved  ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns through the SUT via the defined test VCCs.  Each  generated
   VCC  stream  MUST  match the corresponding VCC Bearer class.  All of the
   VPI/VCI pairs will generate traffic at the  same  traffic  rate.   Since
   this  test is not a throughput test, the rate should not be greater than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of cell misinsertion errors at the receiver end of
   the test device per VCC.

Reporting Format:

   The results of the CMR/Bursty Mixed  Load/Twelve  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The  text  results  SHOULD display the numerical values of the CMR.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display the Cell misinsertion rate values.  The
   x-coordinate SHOULD be the test run time in either seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  CMR  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.4.6. CMR/Bursty Mixed Load/Maximum VCCs

Objective:  To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT  and  test  device  with  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI.  Each
   VCC  MUST  be  defined  as one of the Bearer classes for a total of (max
   VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI  MUST
   not  be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of cell misinsertion errors at the receiver end  of
   the test device per VCC.

Reporting Format:

   The  results  of  the  CMR/Bursty Mixed Load/Maximum VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of  the  CMR.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI during the test in positive integers, and the CMR for the entire
   test.

   The graph results SHOULD display  the  Cell  misinsertion  rate  values.
   There  will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
   each graph.  The x-coordinate SHOULD be the  test  run  time  in  either
   seconds,  minutes or days depending on the total length of the test. The
   x- coordinate time SHOULD be configurable.  The y-coordinate  SHOULD  be
   the  CMR  for  each  VCC. There SHOULD be no more than 10 curves on each
   graph, one curve indicated and labeled for  each  VCC.  The  integration
   time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.5. CRC Error Ratio (CRC-ER)

3.2.5.1. CRC-ER/Steady Load/One VCC

Objective:  To  determine  the  SUT  ratio  of  CRC  errors on one VCC in a

transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device  with  one  VCC.   The  VCC  SHOULD
   contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
   UBR connection. The  VPI/VCI  MUST  not  be  one  of  the  reserved  ATM
   signaling channels (e.g. [0,5], [0,16]).

   3)  Send  a  specific  number  of IP packets at a specific constant rate
   through the SUT via the defined test VCC.  Since  this  test  is  not  a
   throughput  test,  the rate should not be greater than 90% of line rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

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

Reporting Format:

   The results of the CRC-ER/Steady Load/One VCC test SHOULD be reported in
   a form of text and graph.

   The text results SHOULD display the numerical values of the CRC-ER.  The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI  during  the  test  in positive integers, and the CRC-ER for the
   entire test.

   The graph results SHOULD display the CRC Error  ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the CRC-ER.  The
   integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.5.2. CRC-ER/Steady Load/Twelve VCCs

Objective: To determine the SUT ratio of lost cells on  twelve  VCCs  in  a
transmission  in  relation  to  the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC's MUST be configured as  either  a  CBR,  VBR,  or  UBR
   connection.   The VPI/VCIs MUST not be one of the reserved ATM signaling
   channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets  at  a  specific  constant  rate
   through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
   generate traffic at the same traffic rate.  Since this  test  is  not  a
   throughput  test,  the rate should not be greater than 90% of line rate.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

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

Reporting Format:

   The results  of  the  CRC-ER/Steady  Load/Twelve  VCCs  test  SHOULD  be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of the CRC-ER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and  the  CRC-ER  for  the
   entire test.

   The  graph  results  SHOULD  display the CRC Error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER  for  each
   VCC.   There  should  be  12 curves on the graph, on curve indicated and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.5.3. CRC-ER/Steady Load/Maximum VCCs

Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total  cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC's  MUST  be configured as either a CBR, VBR, or UBR connection.  The
   VPI/VCIs MUST not be one of the reserved ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send  a  specific  number  of IP packets at a specific constant rate
   through the SUT via the defined test VCCs. All of the VPI/VCI pairs will
   generate  traffic  at  the  same traffic rate.  Since this test is not a
   throughput test, the rate should not be greater than 90% of  line  rate.

   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

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

Reporting Format:

   The  results  of  the  CRC-ER/Steady  Load/Maximum  VCCs  test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of the CRC-ER.  The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI  during  the  test  in positive integers, and the CRC-ER for the
   entire test.

   The graph results SHOULD display the CRC Error ratio values. There  will
   be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
   The x-coordinate SHOULD be the test run time in either seconds,  minutes
   or days depending on the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the CRC-ER for  each
   VCC.  There  SHOULD  be  no more than 10 curves on each graph, one curve
   indicated and labeled for each VCC. The integration time per point  MUST
   be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.5.4. CRC-ER/Bursty VBR Load/One VCC

Objective:  To  determine  the  SUT  ratio  of  lost  cells on one VCC in a
transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device  with  one  VCC.   The  VCC  SHOULD
   contain  one  VPI/VCI. The VCC MUST be configured as either a CBR or VBR
   connection.  The VPI/VCI MUST not be one of the reserved  ATM  signaling
   channels  (e.g.   [0,5],  [0,16]).   The  PCR,  SCR,  and  MBS  must  be
   configured using one of the specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  at  a  specific rate through the SUT via the defined test
   VCC.  Since this test is not a throughput test, the rate should  not  be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that  are  transmitted  by  the  SUT  to  verify
   connectivity  and  load.  If the count on the test device is the same on
   the SUT, continue the test; else lower  the  test  device  traffic  rate
   until the counts are the same.

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

Reporting Format:

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

   The text results SHOULD display the numerical values of the CRC-ER.  The
   values given SHOULD include: time period of  test  in  s,  test  VPI/VCI
   value,  total  number  of  cells  transmitted  and received on the given
   VPI/VCI during the test in positive integers, and  the  CRC-ER  for  the
   entire test.

   The  graph  results  SHOULD  display the CRC Error ratio values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD  be  the  CRC-ER.   The
   integration time per point MUST be indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.5.5. CRC-ER/Bursty VBR Load/Twelve VCCs

Objective:  To  determine  the  SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as  defined  in  RFC  2761
"Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with twelve VCCs, using 1  VPI  and
   12  VCIs.  The VCC MUST be configured as either a CBR or VBR connection.
   The VPI/VCIs MUST not be one of  the  reserved  ATM  signaling  channels
   (e.g.   [0,5],  [0,16]).  The PCR, SCR, and MBS must be configured using
   one of the specified traffic descriptors.

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  at  a  specific rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.   Since this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The PCR, SCR, and MBS must be  indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

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

Reporting Format:

   The  results  of  the  CRC-ER/Bursty VBR Load/Twelve VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of the CRC-ER.  The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   value, total number of cells  transmitted  and  received  on  the  given
   VPI/VCI  during  the  test  in positive integers, and the CRC-ER for the
   entire test.

   The graph results SHOULD display the CRC Error  ratio  values.   The  x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be configurable.  The y-coordinate SHOULD be the CRC-ER for each
   VCC.  There should be 12 curves on the graph,  on  curve  indicated  and
   labeled for each VCC.  The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.5.6. CRC-ER/Bursty VBR Load/Maximum VCCs

Objective: To determine the SUT ratio of lost cells with the maximum number
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. 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.

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.

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

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

   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.

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

   3.2.6. Cell Transfer Delay (CTD)

   3.2.7.1.
   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 MUST contain a transmit
   timestamp  which  can  be  correlated  with  a  receive   timestamp.   A
   description  of the test cell MUST be included in the test results.  The
   description  MUST  include  the  timestamp  length  (in  bits),  counter
   rollover value, and the timestamp accuracy (in ns).

3.2.7.2.

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, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The y-coordinate SHOULD be the cell transfer
   delay in us.  The integration time per point MUST be indicated.

   The histogram results SHOULD display the cell transfer  delay.   The  x-
   coordinate  SHOULD  be  the  cell transfer delay in us with at least 256
   bins.  The y-coordinate SHOULD be the number of cells observed  in  each
   bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The  VCC  and VPI/VCI values MUST be indicated.  The bearer class of the
   created VCC MUST also be indicated.

3.2.7.3.

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.

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

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

   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.

3.2.7.5.

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.

   The  histogram  results  SHOULD display the cell transfer delay.  The x-
   coordinate SHOULD be the cell transfer delay in us  with  at  least  256
   bins.   The  y-coordinate SHOULD be the number of cells observed in each
   bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.7.6.

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.

   The text results SHOULD display the numerical values of  the  CTD.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   values, total number of cells  transmitted  and  received  on  each  VCC
   during  the  test  in positive integers, maximum and minimum CTD on each
   VCC during the test in us, and mean CTD on each VCC in us.

   The graph results SHOULD display the cell transfer delay values.  The x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The y-coordinate SHOULD be the cell transfer
   delay for each VCC in ms.  There SHOULD be 12 curves on the  graph,  one
   curves  indicated  and  labeled  for  each VCC. The integration time per
   point MUST be indicated.

   The histograms SHOULD display the cell transfer delay. There will be one
   histogram  for  each  VCC.  The x-coordinate SHOULD be the cell transfer
   delay in us with at least 256 bins.   The  y-coordinate  SHOULD  be  the
   number of cells observed in each bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.7.7.

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

3.2.7.5.

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.

   The  histogram  results  SHOULD display the cell transfer delay.  The x-
   coordinate SHOULD be the cell transfer delay in us  with  at  least  256
   bins.   The  y-coordinate SHOULD be the number of cells observed in each
   bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The bearer  class  of  the
   created VCC MUST also be indicated.

3.2.7.6.

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  VPI/VCI
   values,  total  number  of  cells  transmitted  and received on each VCC
   during the test in positive integers, maximum and minimum  CTD  on  each
   VCC during the test in us, and mean CTD on each VCC in us.

   The graph results SHOULD display the cell transfer delay values.  The x-
   coordinate SHOULD be the test run time in  either  seconds,  minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be  the  cell  transfer
   delay  for  each VCC in ms.  There SHOULD be 12 curves on the graph, one
   curves indicated and labeled for each  VCC.  The  integration  time  per
   point MUST be indicated.

   The histograms SHOULD display the cell transfer delay. There will be one
   histogram for each VCC.  The x-coordinate SHOULD be  the  cell  transfer
   delay  in  us  with  at  least 256 bins.  The y-coordinate SHOULD be the
   number of cells observed in each bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The bearer  class  of  the
   created VCC MUST also be indicated.

3.2.7.7.

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.

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

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

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.

   The  histogram  results  SHOULD display the cell transfer delay.  The x-
   coordinate SHOULD be the cell transfer delay in us  with  at  least  256
   bins.   The  y-coordinate SHOULD be the number of cells observed in each
   bin.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class  of  the  created  VCC  MUST  also be
   indicated.

3.2.7.9.

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.

   The text results SHOULD display the numerical values of  the  CTD.   The
   values  given  SHOULD  include:  time  period of test in s, test VPI/VCI
   values, total number of cells  transmitted  and  received  on  each  VCC
   during  the  test  in positive integers, maximum and minimum CTD on each
   VCC during the test in us, and mean CTD on each VCC in us.

   The graph results SHOULD display the cell transfer delay values.  The x-
   coordinate  SHOULD  be  the  test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The y-coordinate SHOULD be the cell transfer
   delay for each VCC in ms.  There SHOULD be 12 curves on the  graph,  one
   curves  indicated  and  labeled  for  each VCC. The integration time per
   point MUST be indicated.

   The histograms SHOULD display the cell transfer delay. There will be one
   histogram  for  each  VCC.  The x-coordinate SHOULD be the cell transfer
   delay in us with at least 256 bins.   The  y-coordinate  SHOULD  be  the
   number of cells observed in each bin.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated.  The  bearer  class  of  the  created  VCC  MUST  also  be
   indicated.

3.2.7.10.

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

   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.

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.

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  reassumbly  timeout  test
   SHOULD be reported in a form of a table. The rows SHOULD be labeled 1365
   cells per 'x' seconds and 1360 cells per 'x' seconds. The columns SHOULD
   be  labeled  packet  loss  and  number of packets lost.  The elements of
   column 1  SHOULD  be  either  True  or  False,  indicating  whether  the
   particular condition was observed for each test.  The elements of column
   2 SHOULD be non-negative integers.

   The table MUST also indicate the packet size in octets and traffic  rate
   in  packets  per  second  as generated by the test device, including the
   value of

3.3.3. AAL5 CRC Error Ratio.

3.3.2.1. Test Setup

   The AAL5 CRC error ratio measurements assume that both  the  transmitter
   and  receiver  payload information is synchronized. Synchronization MUST
   be achieved by supplying a known bit pattern to both the transmitter and
   receiver.   If  this  bit  pattern  is  longer than the packet size, the
   receiver MUST synchronize with the transmitter before tests can be  run.

3.3.2.2. AAL5-CRC-ER/Steady Load/One VCC

Objective:  To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined  in  RFC
2761 "Terminology for ATM Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device  with  one  VCC.   The  VCC  SHOULD
   contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
   UBR connection.  The VPI/VCI  MUST  not  be  one  of  the  reserved  ATM
   signaling channels (e.g. [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a constant rate through the SUT  via  the  defined  test
   VCC.   Since  this test is not a throughput test, the rate should not be
   greater than 90% of line rate.  The IP  PDUs  MUST  be  encapsulated  in
   AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of AAL5 CRC errors at the receiver end of the  test
   device.

Reporting Format:

   The  results  of  the  AAL5-CRC-ER/Steady  Load/One  VCC  test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The  values given SHOULD include: time period of test in s, test VPI/VCI
   value, total number of AAL5 PDU's transmitted and received on the  given
   VPI/VCI  during  the  test in positive integers, and the AAL5-CRC-ER for
   the entire test.

   The graph results SHOULD display the AAL5 CRC error ratio  values.   The
   x-  coordinate SHOULD be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the AAL5-CRC-ER.
   The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be  indicated.  The  bearer  class of the created VCC MUST be indicated.
   The generated bit pattern MUST also be indicated.

3.3.2.3. AAL5-CRC-ER/Steady Load/Twelve VCCs

Objective: To determine the SUT ratio of AAL5  CRC  PDU  errors  on  twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC's MUST be configured as  either  a  CBR,  VBR,  or  UBR
   connection.   The VPI/VCIs MUST not be one of the reserved ATM signaling
   channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  at  a  constant rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.   Since this test is not a throughput test, the rate should not be
   greater than 90% of line rate.  The IP  PDUs  MUST  be  encapsulated  in
   AAL5.

   4)  Count  the IP packets that are transmitted by the SUT on all VCCs to
   verify connectivity and load.  If the count on the test  device  is  the
   same  on  the SUT, continue the test; else lower the test device traffic
   rate until the counts are the same.

   5) Record the number of AAL5 CRC errors at the receiver end of the  test
   device for all VCCs.

Reporting Format:

   The  results  of  the AAL5-CRC-ER/Steady Load/Twelve VCCs test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The  values given SHOULD include: time period of test in s, test VPI/VCI
   value, total number of AAL5 PDU's transmitted and received on the  given
   VPI/VCI  during  the  test in positive integers, and the AAL5-CRC-ER for
   the entire test.

   The graph results SHOULD display the AAL5 CRC error ratio  values.   The
   x-  coordinate SHOULD be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be configurable.  The y-coordinate SHOULD be the AAL5-CRC-ER for
   each VCC.  There should be 12 curves on the graph,  on  curve  indicated
   and  labeled  for  each  VCC.   The  integration  time per point MUST be
   indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.2.4. AAL5-CRC-ER/Steady Load/Maximum VCCs

Objective: To determine the SUT ratio of  AAL5  CRC  PDU  errors  with  the
maximum  number  VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined  in  RFC  2761  "Terminology  for  ATM
Benchmarking".

Procedure:

   1)   Set   up   the   SUT  and  test  device  using  the  bi-directional
   configuration.

   2) Configure the SUT and test device with the  maximum  number  of  VCCs
   supported  on  the  SUT.  For  example,  if  the  maximum number of VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per  VPI.  The
   VCC's  MUST  be configured as either a CBR, VBR, or UBR connection.  The
   VPI/VCIs MUST not be one of the reserved ATM  signaling  channels  (e.g.
   [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.

3.3.2.5. AAL5-CRC-ER/Bursty VBR Load/One VCC

Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC  in
a  transmission  in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device with one VCC.  The VCC SHOULD
   contain one VPI/VCI. The VCC MUST be configured as either a CBR  or  VBR
   connection.   The  VPI/VCI MUST not be one of the reserved ATM signaling
   channels  (e.g.   [0,5],  [0,16]).   The  PCR,  SCR,  and  MBS  must  be
   configured using one of the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific VBR rate through the SUT via the defined test
   VCC.   Since  this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of AAL5 CRC errors at the receiver end of the  test
   device.

Reporting Format:

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

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The  values given SHOULD include: time period of test in s, test VPI/VCI
   value, total number of AAL5 PDU's transmitted and received on the  given
   VPI/VCI  during  the  test in positive integers, and the AAL5-CRC-ER for
   the entire test.

   The graph results SHOULD display the AAL5 CRC error ratio  values.   The
   x-  coordinate SHOULD be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the AAL5-CRC-ER.
   The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.2.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs

Objective: To determine the SUT ratio of AAL5  CRC  PDU  errors  on  twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
   The  VPI/VCIs  MUST  not  be  one of the reserved ATM signaling channels
   (e.g.  [0,5], [0,16]). The PCR, SCR, and MBS must  be  configured  using
   one of the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific VBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than 90% of line rate. The PCR, SCR, and MBS must be indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of AAL5 CRC errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs  test  SHOULD
   be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The values given SHOULD include: time period of test in s, test  VPI/VCI
   value,  total number of AAL5 PDU's transmitted and received on the given
   VPI/VCI during the test in positive integers, and  the  AAL5-CRC-ER  for
   the entire test.

   The  graph  results SHOULD display the AAL5 CRC error ratio values.  The
   x- coordinate SHOULD be the test run time in either seconds, minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the AAL5-CRC-ER  for
   each  VCC.   There  should be 12 curves on the graph, on curve indicated
   and labeled for each VCC.   The  integration  time  per  point  MUST  be
   indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.2.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs

Objective:  To  determine  the  SUT  ratio  of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in  relation  to
the  total  AAL5  PDU's  sent  as  defined in RFC 2761 "Terminology for ATM
Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and test device with the maximum number of VCCs
   supported on the SUT.  For  example,  if  the  maximum  number  of  VCCs
   supported  on  the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
   VCC's MUST be configured as  either  a  CBR  or  VBR  connection.    The
   VPI/VCIs  MUST  not  be one of the reserved ATM signaling channels (e.g.
   [0,5], [0,16]). The PCR, SCR, and MBS must be configured  using  one  of
   the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific VBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than  90%  of  line  rate.  The IP PDUs MUST be encapsulated in
   AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of AAL5 CRC errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs test  SHOULD
   be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The values given SHOULD include: time period of test in s, test  VPI/VCI
   value,  total number of AAL5 PDU's transmitted and received on the given
   VPI/VCI during the test in positive integers, and  the  AAL5-CRC-ER  for
   the entire test.

   The  graph results SHOULD display the AAL5 CRC error ratio values. There
   will be (Max number of VCCs/10) graphs, with 10 VCCs indicated  on  each
   graph.   The x-coordinate SHOULD be the test run time in either seconds,
   minutes or days depending on the  total  length  of  the  test.  The  x-
   coordinate  time SHOULD be configurable.  The y-coordinate SHOULD be the
   AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
   graph,  one  curve  indicated  and labeled for each VCC. The integration
   time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.2.5. AAL5-CRC-ER/Bursty UBR Load/One VCC

Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC  in
a  transmission  in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device with one VCC.  The VCC SHOULD
   contain one VPI/VCI. The VCC MUST be configured  as  a  UBR  connection.
   The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.

   [0,5], [0,16]).  The PCR, SCR, and MBS must be configured using  one  of
   the specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific UBR rate through the SUT via the defined test
   VCC.   Since  this test is not a throughput test, the rate should not be
   greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of AAL5 CRC errors at the receiver end of the  test
   device.

Reporting Format:

   The  results  of  the AAL5-CRC-ER/Bursty UBR Load/One VCC test SHOULD be
   reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The  values given SHOULD include: time period of test in s, test VPI/VCI
   value, total number of AAL5 PDU's transmitted and received on the  given
   VPI/VCI  during  the  test in positive integers, and the AAL5-CRC-ER for
   the entire test.

   The graph results SHOULD display the AAL5 CRC error ratio  values.   The
   x-  coordinate SHOULD be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be  configurable.   The  y-coordinate SHOULD be the AAL5-CRC-ER.
   The integration time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.2.6. AAL5-CRC-ER/Bursty UBR Load/Twelve VCCs

Objective: To determine the SUT ratio of AAL5  CRC  PDU  errors  on  twelve

VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCCs, using 1 VPI and
   12 VCIs. The VCC's MUST be configured as a UBR connection.  The VPI/VCIs
   MUST  not  be  one  of  the reserved ATM signaling channels (e.g. [0,5],
   [0,16]). The PCR, SCR, and MBS must  be  configured  using  one  of  the
   specified traffic descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific UBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than 90% of line rate. The PCR, SCR, and MBS must be indicated.
   The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of AAL5 CRC errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the AAL5-CRC-ER/Bursty UBR Load/Twelve VCCs  test  SHOULD
   be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The values given SHOULD include: time period of test in s, test  VPI/VCI
   value,  total number of AAL5 PDU's transmitted and received on the given
   VPI/VCI during the test in positive integers, and  the  AAL5-CRC-ER  for
   the entire test.

   The  graph  results SHOULD display the AAL5 CRC error ratio values.  The
   x- coordinate SHOULD be the test run time in either seconds, minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the AAL5-CRC-ER  for
   each  VCC.   There  should be 12 curves on the graph, on curve indicated
   and labeled for each VCC.   The  integration  time  per  point  MUST  be
   indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.2.7. AAL5-CRC-ER/Bursty UBR Load/Maximum VCCs

Objective:  To  determine  the  SUT  ratio  of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in  relation  to
the  total  AAL5  PDU's  sent  as  defined in RFC 2761 "Terminology for ATM
Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and test device with the maximum number of VCCs
   supported on the SUT.  For  example,  if  the  maximum  number  of  VCCs
   supported  on  the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
   VCC's MUST be configured as a UBR connection.   The VPI/VCIs MUST not be
   one  of  the  reserved  ATM signaling channels (e.g. [0,5], [0,16]). The
   PCR, SCR, and MBS must be configured using one of the specified  traffic
   descriptors.

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns at a specific UBR rate through the SUT via the defined test
   VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
   rate.  Since this test is not a throughput test, the rate should not  be
   greater  than  90%  of  line  rate.  The IP PDUs MUST be encapsulated in
   AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of AAL5 CRC errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the AAL5-CRC-ER/Bursty UBR Load/Maximum VCCs test  SHOULD
   be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The values given SHOULD include: time period of test in s, test  VPI/VCI
   value,  total number of AAL5 PDU's transmitted and received on the given
   VPI/VCI during the test in positive integers, and  the  AAL5-CRC-ER  for
   the entire test.

   The  graph results SHOULD display the AAL5 CRC error ratio values. There
   will be (Max number of VCCs/10) graphs, with 10 VCCs indicated  on  each
   graph.   The x-coordinate SHOULD be the test run time in either seconds,
   minutes or days depending on the  total  length  of  the  test.  The  x-
   coordinate  time SHOULD be configurable.  The y-coordinate SHOULD be the
   AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
   graph,  one  curve  indicated  and labeled for each VCC. The integration
   time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.1.8. AAL5-CRC-ER/Mixed Load/Three VCC's

Objective: To determine the SUT ratio of AAL5 CRC PDU errors on three VCC's
in  a  transmission  in relation to the total AAL5 PDU's sent as defined in
RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2) Configure the SUT and test device with three VCC's.  Each VCC MUST be
   defined as a different Bearer class; one CBR, one UBR and one VBR.  Each
   VCC  SHOULD  contain  one  VPI/VCI.   The VPI/VCI MUST not be one of the
   reserved ATM signaling channels (e.g. [0,5], [0,16]).

   3) Send a specific number of IP packets containing one of the  specified
   bit  patterns  through the SUT via the defined test VCCs. Each generated
   VCC stream MUST match the corresponding VCC Bearer class.   All  of  the
   VPI/VCI  pairs  will  generate  traffic at the same traffic rate.  Since
   this test is not a throughput test, the rate should not be greater  than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4)  Count  the  IP  packets  that  are  transmitted by the SUT to verify
   connectivity and load.  If the count on the test device is the  same  on
   the  SUT,  continue  the  test;  else lower the test device traffic rate
   until the counts are the same.

   5) Record the number of AAL5 CRC errors at the receiver end of the  test
   device for all VCCs.

Reporting Format:

   The  results of the AAL5-CRC-ER/Bursty Mixed Load/Three VCCs test SHOULD
   be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The  values given SHOULD include: time period of test in s, test VPI/VCI
   value, total number of AAL5 PDU's transmitted and received on the  given
   VPI/VCI  during  the  test in positive integers, and the AAL5-CRC-ER for
   the entire test.

   The graph results SHOULD display the AAL5 CRC error ratio  values.   The
   x-  coordinate SHOULD be the test run time in either seconds, minutes or
   days depending on the total length of the test.  The  x-coordinate  time
   SHOULD  be configurable.  The y-coordinate SHOULD be the AAL5-CRC-ER for
   each VCC.  There should be 12 curves on the graph,  on  curve  indicated
   and  labeled  for  each  VCC.   The  integration  time per point MUST be
   indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.1.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs

Objective: To determine the SUT ratio of AAL5  CRC  PDU  errors  on  twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:
   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the SUT and test device with twelve VCC's.  Each VCC MUST
   be defined as one of the Bearer classes for a total of  four  CBR,  four
   UBR  and  four  VBR  VCC's.   Each  VCC SHOULD contain one VPI/VCI.  The
   VPI/VCI MUST not be one of the reserved  ATM  signaling  channels  (e.g.
   [0,5], [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns through the SUT via the defined test VCCs.  Each  generated
   VCC  stream  MUST  match the corresponding VCC Bearer class.  All of the
   VPI/VCI pairs will generate traffic at the  same  traffic  rate.   Since
   this  test is not a throughput test, the rate should not be greater than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of AAL5 CRC errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of the AAL5-CRC-ER/Bursty Mixed Load/Twelve VCCs test SHOULD
   be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The values given SHOULD include: time period of test in s, test  VPI/VCI
   value,  total number of AAL5 PDU's transmitted and received on the given
   VPI/VCI during the test in positive integers, and  the  AAL5-CRC-ER  for
   the entire test.

   The  graph  results SHOULD display the AAL5 CRC error ratio values.  The
   x- coordinate SHOULD be the test run time in either seconds, minutes  or
   days  depending  on  the total length of the test. The x-coordinate time
   SHOULD be configurable.  The y-coordinate SHOULD be the AAL5-CRC-ER  for
   each  VCC.   There  should be 12 curves on the graph, on curve indicated
   and labeled for each VCC.   The  integration  time  per  point  MUST  be
   indicated.

   The  results  MUST also indicate the packet size in octets, traffic rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.3.1.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs

Objective:  To  determine  the  SUT  ratio  of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in  relation  to
the  total  AAL5  PDU's  sent  as  defined in RFC 2761 "Terminology for ATM
Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Configure  the  SUT  and  test  device  with  maximum number of VCCs
   supported on the SUT.  For  example,  if  the  maximum  number  of  VCCs
   supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI.  Each
   VCC MUST be defined as one of the Bearer classes for  a  total  of  (max
   VCC/3)  CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
   not be one of the reserved ATM signaling channels (e.g. [0,5],  [0,16]).

   3)  Send a specific number of IP packets containing one of the specified
   bit patterns through the SUT via the defined test VCCs.  Each  generated
   VCC  stream  MUST  match the corresponding VCC Bearer class.  All of the
   VPI/VCI pairs will generate traffic at the  same  traffic  rate.   Since
   this  test is not a throughput test, the rate should not be greater than
   90% of line rate.  The IP PDUs MUST be encapsulated in AAL5.

   4) Count the IP packets that are transmitted by the SUT on all  VCCs  to
   verify  connectivity  and  load.  If the count on the test device is the
   same on the SUT, continue the test; else lower the test  device  traffic
   rate until the counts are the same.

   5)  Record the number of AAL5 CRC errors at the receiver end of the test
   device for all VCCs.

Reporting Format:

   The results of  the  AAL5-CRC-ER/Bursty  Mixed  Load/Maximum  VCCs  test
   SHOULD be reported in a form of text and graph.

   The text results SHOULD display the numerical values of the AAL5-CRC-ER.
   The values given SHOULD include: time period of test in s, test  VPI/VCI
   value,  total number of AAL5 PDU's transmitted and received on the given
   VPI/VCI during the test in positive integers, and  the  AAL5-CRC-ER  for
   the entire test.

   The  graph results SHOULD display the AAL5 CRC error ratio values. There
   will be (Max number of VCCs/10) graphs, with 10 VCCs indicated  on  each
   graph.   The x-coordinate SHOULD be the test run time in either seconds,
   minutes or days depending on the  total  length  of  the  test.  The  x-
   coordinate  time SHOULD be configurable.  The y-coordinate SHOULD be the
   AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
   graph,  one  curve  indicated  and labeled for each VCC. The integration
   time per point MUST be indicated.

   The results MUST also indicate the packet size in octets,  traffic  rate
   in packets per second, and bearer class as generated by the test device.
   The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
   be indicated. The bearer class of the created VCC MUST be indicated. The
   generated bit pattern MUST also be indicated.

3.4. ATM Service: Signaling

3.4.1. CAC Denial Time and Connection Establishment Time

Objective: To determine the CAC rejection time and Connection Establishment
Time  on the SUT as defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Create  a  UNI  signaling setup message, as described in Appendix C,
   specifying a PCR which will not allow CAC to reject the call.

   3) Send the UNI signaling setup message. Note the time the setup message
   was  sent.   Verify  that  the  SVC  has  been  setup  with  the correct
   parameters.  Note the time the connect message was received

   4) Create a UNI signaling setup message, as  described  in  Appendix  C,
   specifying a PCR which will allow CAC to reject the call.

   5)  Send  the  UNI  signaling  setup  message.   Note the time the setup
   message was sent.  Verify that  the  SVC  has  been  rejected  with  the
   correct  cause  code.  Note  the  time  the release complete message was
   received.

   6) Compute the rejection time as the difference  between  the  time  the
   release  complete  message  was  received and the time setup message was
   send.

Reporting Format:

   The results of the CAC Denial Time  and  Connection  Establishment  Time
   tests  SHOULD  be  reported  in  a  form  of a table. The rows SHOULD be
   labeled call accepted and call rejected. The columns SHOULD  be  labeled
   time  setup  sent,  time  response  recieved, and correct response.  The
   elements of the columns 1 and 2 SHOULD be in seconds.  The  elements  of
   column  3  SHOULD  be  be  either  True or False, indicating whether the
   particular condition was observed for each test.

   The table MUST also indicate the packet size in octets and traffic  rate
   in packets per second as generated by the test device.

3.4.2. Connection Teardown Time

Objective:  To determine the Connection Teardown Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Create  a  UNI  signaling setup message, as described in Appendix C,
   specifying a PCR which will not allow CAC to reject the call.

   3) Send the UNI signaling setup message. Note the time the setup message
   was  sent.   Verify  that  the  SVC  has  been  setup  with  the correct
   parameters.  Note the time the connect message was received

   4) Create a UNI signaling release message, as described in  Appendix  C,
   specifying a cause code of normal call clearing.

   5)  Send  the  UNI signaling release message.  Note the time the release
   message was sent.  Verify that the SVC  has  been  terminated  with  the
   correct  cause  code.  Note  the  time  the release complete message was
   received.

   6) Compute the release time as  the  difference  between  the  time  the
   release  complete  message was received and the time release message was
   send.

Reporting Format:

   The results of the Connection Teardown Time tests SHOULD be reported  in
   a  form  of  a  table. The rows SHOULD be labeled call accepted and call
   released. The columns SHOULD be labeled time message sent, time response
   received,  and  correct  response.   The elements of the columns 1 and 2
   SHOULD be in seconds.  The elements of column 3 SHOULD be be either True
   or  False,  indicating whether the particular condition was observed for
   each test.

   The table MUST also indicate the packet size in octets and traffic  rate
   in packets per second as generated by the test device.

3.4.3. Crankback Time

Objective:  To  determine  the  Crankback Time on the SUT as defined in RFC
2761 "Terminology for ATM Benchmarking".

Procedure:

   1) Set up the SUT and test device using the uni-directional  passthrough
   configuration.

   2)  Create  a  PNNI signaling setup message, as described in Appendix C,
   specifying a DTL which is not blocked by the far end SUT.

   3) Send the PNNI signaling  setup  message.  Note  the  time  the  setup
   message  was sent.  Verify that the connect message has been received by
   the near- end switch. Note the time the connect message was received

   4) Create a PNNI signaling setup message, as described  in  Appendix  C,
   specifying a DTL which is blocked by the far end SUT.

   5)  Send  the PNNI signaling release message.  Note the time the release
   message was sent.  Note  the  time  the  release  complete  message  was
   received.   Note  the time the near-end switch sends it's own PNNI setup
   message (referred to as the near-end setup message) specifying the  non-
   blocked DTL.

   6)  Compute  the  crankback  time as the difference between the time the
   near- end setup message was received and the time  release  message  was
   send.

Reporting Format:

   The  results of the Crankback Time tests SHOULD be reported in a form of
   a table. The rows SHOULD be labeled DTL call accepted and call released.
   The columns SHOULD be labeled time message sent, time response received,
   and correct response.  The elements of the columns 1 and 2 SHOULD be  in
   seconds.   The  elements  of column 3 SHOULD be be either True or False,
   indicating whether the particular condition was observed for each  test.

   The  table MUST also indicate the packet size in octets and traffic rate
   in packets per second as generated by the test device.

3.4.4. Route Update Response Time

Objective: To determine the Route  Update  Response  Time  on  the  SUT  as
defined in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set up the SUT and test device using the uni-directional passthrough
   configuration.

   2) Create a PNNI PTSE as described in Appendix C, specifying  a  routing
   topology.   Verify  that  the routing tables on the far-end and near-end
   switches are empty.

   3) Send the PTSE message to the far-end switch. Note the time  the  PTSE
   message was sent.  Verify that the PTSE message has been received by the
   far-end switch. Note the time the PTSE message was received.

   4) Create another PNNI PTSE as described in  Appendix  C,  specifying  a
   change  in  the routing topology.  Verify that the routing tables on the
   far-end and near-end switches contain the previous PTSE routes.

   5) Send the PTSE message to the far-end switch. Note the time  the  PTSE
   message was sent.  Verify that the PTSE message has been received by the
   far-end switch. Note the time the PTSE message was received.   Note  the
   time  the  PTSE  was sent to the near-end switch. Note the time the PTSE
   message was received on the near-end switch.

   6) Compute the Route Update Response time as the difference between  the
   time the far-end PTSE message was sent and the time far-end PTSE message
   was received by the near-end.

Reporting Format:

   The results of the Route Update Response Time tests SHOULD  be  reported
   in  a  form  of  a table. The rows SHOULD be labeled PTSE call accepted,
   far-end PTSE message send, and near-end message  received.  The  columns
   SHOULD be labeled time message sent, time response received, and correct
   response.  The elements of the columns 1 and 2  SHOULD  be  in  seconds.
   The  elements  of column 3 SHOULD be be either True or False, indicating
   whether the particular condition was observed for each test.

   The table MUST also indicate the packet size in octets and traffic  rate
   in packets per second as generated by the test device.

3.5. ATM Service: ILMI

3.5.1. MIB Alignment Time

Objective: To determine the MIB Alignment Time on the SUT as defined in RFC
2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2)  Send a Cold Start message to the SUT.  Note the time the message was
   sent to the SUT.  Verify that the Cold Start message has  been  received
   by the SUT. Note the time the message was received.

   3) Send a Get Request message to the SUT.  Note the time the message was
   sent to the SUT. Verify that the Get Request message has  been  received
   by the SUT. Note the time the message was received.

   4)  After  all  MIB  elements  are  exchanged, verify that the final Get
   Request message has been received by the SUT. Note the time the  message
   was send and received by the SUT.

   5) Compute the MIB Alignment Time as the difference between the time the
   Cold Start message was sent and the  time  the  final  Get  Request  was
   received by the SUT.

Reporting Format:

   The results of the MIB Alignment Time tests SHOULD be reported in a form
   of a table. The rows SHOULD be  labeled  Cold  Start  Send,  Cold  Start
   accepted,  Final  Get  Request send, and Final Get Request received. The
   columns SHOULD be labeled time message sent, time response received, and
   correct  response.   The  elements  of  the columns 1 and 2 SHOULD be in
   seconds.  The elements of column 3 SHOULD be be either  True  or  False,
   indicating  whether the particular condition was observed for each test.

   The table MUST also indicate the packet size in octets and traffic  rate
   in packets per second as generated by the test device.

3.5.2. Address Registration Time

Objective: To determine the Address Registration Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

   1)  Set  up  the  SUT  and  test   device   using   the   bi-directional
   configuration.

   2) Send a Set Request message to the SUT.  Note the time the message was
   sent to the SUT.  Verify that the Set Request message has been  received
   by the SUT. Note the time the message was received.

   3) Send a Get Request message to the SUT.  Note the time the message was
   sent to the SUT. Verify that the Get Request message has  been  received
   by the SUT. Note the time the message was received.

   4)  After  all  MIB  elements  are  exchanged, verify that the final Get
   Request message has been received by the SUT. Note the time the  message
   was send and received by the SUT.

   5)  Compute  the Address Registration Time as the difference between the
   time the Set Request message was sent and the time the final Get Request
   was received by the SUT.

Reporting Format:

   The results of the Address Registration Time tests SHOULD be reported in
   a form of a table. The rows SHOULD be  labeled  Set  Request  Send,  Set
   Request  saccepted,  Final  Get  Request  send,  and  Final  Get Request
   received. The columns SHOULD be labeled time message sent, time response
   received,  and  correct  response.   The elements of the columns 1 and 2
   SHOULD be in seconds.  The elements of column 3 SHOULD be be either True
   or  False,  indicating whether the particular condition was observed for
   each test.

   The table MUST also indicate the packet size in octets and traffic  rate
   in packets per second as generated by the test device.

4. Security Considerations.

   As  this document is solely for the purpose of providing methodology and
   describes neither  a  protocol  nor  an  implementation,  there  are  no
   security considerations associated with this document.

5. Notices

   The  IETF  takes  no  position  regarding  the  validity or scope of any
   intellectual property or other rights that might be claimed  to  pertain
   to  the  implementation  or  use  of  the  technology  described in this
   document or the extent to which any license under such rights  might  or
   might  not  be available; neither does it represent that it has made any
   effort to identify any such rights.  Information on the IETFs procedures
   with   respect   to  rights  in  standards-track  and  standards-related
   documentation can be found in BCP-11.  Copies of claims of  rights  made
   available  for  publication  and  any  assurances of licenses to be made
   available, or the result of an attempt made to obtain a general  license
   or  permission for the use of such proprietary rights by implementors or
   users of this specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to  bring  to  its  attention  any
   copyrights,  patents or patent applications, or other proprietary rights
   which may cover  technology  that  may  be  required  to  practice  this
   standard.    Please  address  the  information  to  the  IETF  Executive
   Director.

6. Disclaimer

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

   This document and translations of it may  be  copied  and  furnished  to
   others,  and derivative works that comment on or otherwise explain it or
   assist in its implementation may  be  prepared,  copied,  published  and
   distributed,  in  whole  or  in  part,  without restriction of any kind,
   provided that the above copyright notice and this paragraph are included
   on  all such copies and derivative works.  However, this document itself
   may not be modified in any way, such as by removing the copyright notice
   or  references  to the Internet Society or other Internet organizations,
   except as needed for the purpose of  developing  Internet  standards  in
   which  case  the  procedures  for  copyrights  defined  in  the Internet
   Standards process must be followed, or as required to translate it  into
   languages other than English.

   The  limited  permissions  granted  above  are perpetual and will not be
   revoked by the Internet Society  or  its  successors  or  assigns.  This
   document  and the information contained herein is provided on an "AS IS"
   basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING  TASK  FORCE
   DISCLAIMS  ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

7. References

   [IETF-RFC-2544] IETF RFC  2544  "Benchmarking  Methodology  for  Network
   Interconnect Devices", March, 1999.

   [IETF-RFC-2225]  IETF  RFC  2225 "Classical IP and ARP over ATM", April,
   1998.

   [IETF-RFC-2761] IETF RFC 2761 "Terminology for ATM Benchmarking"  Draft,
   2000.

   [AF-ILMI4.0]  ATM  Forum  Integrated  Local Management Interface Version
   4.0, af-ilmi-0065.000, September 1996.

   [AF-TEST-0022] Introduction to ATM Forum Test  Specifications,  af-test-
   0022.00, December 1994.

   [AF-TM4.1]  ATM Forum, Traffic Management Specification Version 4.1, af-
   tm- 0121.00, April 1996.

   [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1,
   September 1994.

   [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0,
   July 1996.

8. Editor's Addresses

   Jeffrey Dunn
   Advanced Network Consultants, Inc.
   4214 Crest Place, Ellicott City, MD 21043 USA
   Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net
   Cynthia Martin
   Advanced Network Consultants, Inc.
   4214 Crest Place, Ellicott City, MD 21043 USA
   Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net

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

 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

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

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

    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

 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

 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

 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