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

                                                           March,

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

Status of this Memo

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

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

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

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

Copyright Notice

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

Abstract

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

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

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

   The  SUT  MUST  be  configured  as  described  in  the  SUT users guide.
   Specifically, it is expected that all of the supported protocols will be
   configured and enabled (See Appendix A).  It is expected that all of the
   tests will be run without changing the configuration or setup of the SUT
   in  any  way  other  than  that  required  to do the specific test.  For
   example, it is not acceptable to disable all but one transport  protocol
   when  testing the throughput of that protocol.  If PNNI or BISUP is used
   to initiate switched virtual connections (SVCs), the  SUT  configuration
   SHOULD  include  the  normally  recommended routing update intervals and
   keep alive frequency.  The specific version  of  the  software  and  the
   exact  SUT configuration, including what functions are disabled and used
   during the tests MUST be included as part of the report of the  results.

2.6. Frame formats

   The  formats of the test IP PDUs to use for TCP/IP over ATM are shown in
   Appendix C: Test  Frame  Formats.   Note  that  these  IP  PDUs  are  in
   accordance  with RFC 2225.  These exact IP PDU formats SHOULD be used in
   the  tests  described  in  this   document   for   this   protocol/media
   combination.  These IP PDUs will be used as a template for testing other
   protocol/media combinations.  The specific  formats  that  are  used  to
   define the test IP PDUs for a particular test series MUST be included in
   the report of the results.

2.7. Frame sizes

   All of the described tests SHOULD be performed using a number of IP  PDU
   sizes.  Specifically,  the  sizes SHOULD include the maximum and minimum
   legitimate sizes for the protocol under test on the media under test and
   enough sizes in between to be able to get a full characterization of the
   SUT performance.  Except where noted, at least five IP PDU sizes  SHOULD
   be tested for each test condition.

   Theoretically  the minimum size UDP Echo request IP PDU would consist of
   an IP header (minimum length 20 octets), a UDP header (8  octets),  AAL5
   trailer  (8  octets)  and  an  LLC/SNAP  code  point  header(8  octets);
   therefore, the minimum size  PDU  will  fit  into  one  ATM  cell.   The
   theoretical  maximum IP PDU size is determined by the size of the length
   field in the IP header.  In almost all  cases  the  actual  maximum  and
   minimum  sizes  are  determined by the limitations of the media.  In the
   case of ATM, the maximum IP PDU size SHOULD be the ATM MTU  size,  which
   is 9180 octets.

   In theory it would be ideal to distribute the IP PDU sizes in a way that
   would  evenly  distribute  the  theoretical   IP   PDU   rates.    These
   recommendations  incorporate this theory but specify IP PDU sizes, which
   are easy to understand and remember.  In addition, many of the  same  IP
   PDU  sizes  are  specified  on each of the media types to allow for easy
   performance comparisons.

   Note: The inclusion of an unrealistically small IP PDU size on  some  of
   the  media  types  (i.e.  with  little  or no space for data) is to help
   characterize the per-IP PDU processing overhead of the SUT.

   The IP PDU sizes that will be used are:

   44, 64, 128, 256, 1024, 1518, 2048, 4472, 9180

   The minimum size IP PDU for UDP on ATM is 44 octets, the minimum size of
   44  is recommended to allow direct comparison to token ring performance.
   The IP PDU size of 4472 is recommended instead of the  theoretical  FDDI
   maximum  size  of  4500  octets  in  order  to  permit  the same type of
   comparison. An IP (i.e. not UDP) IP PDU may be used  in  addition  if  a
   higher data rate is desired, in which case the minimum IP PDU size is 28
   octets.

2.8. Verifying received IP PDUs

   The test equipment SHOULD discard any IP PDUs received during a test run
   that are not actual forwarded test IP PDUs.  For example, keep-alive and
   routing update IP PDUs SHOULD NOT be included in the count  of  received
   IP  PDUs.   In  any case, the test equipment SHOULD verify the length of
   the received IP PDUs and check that they match the expected length.

   Preferably, the test equipment SHOULD include sequence  numbers  in  the
   transmitted IP PDUs and check for these numbers on the received IP PDUs.
   If this is done, the reported results SHOULD include. in addition to the
   number  of IP PDUs dropped, the number of IP PDUs that were received out
   of order, the number of duplicate IP PDUs received  and  the  number  of
   gaps  in  the received IP PDU numbering sequence.  This functionality is
   required for some of the described tests.

2.9. Modifiers

   It is useful to characterize the SUTs  performance  under  a  number  of
   conditions.  Some  of  these  conditions  are noted below.  The reported
   results SHOULD include as many of these conditions as the test equipment
   is able to generate.  The suite of tests SHOULD be run first without any
   modifying  conditions,  then  repeated  under  each  of  the   modifying
   conditions  separately.   To preserve the ability to compare the results
   of these tests, any IP PDUs that are required to generate the  modifying
   conditions  (excluding  management queries) will be included in the same
   data stream as that of the normal test IP PDUs and in place  of  one  of
   the  test  IP  PDUs.  They MUST not be supplied to the SUT on a separate
   network port.

2.9.1. Management IP PDUs

   Most ATM data networks now make use of ILMI, signaling and OAM. In  many
   environments,  there  can  be  a  number  of management stations sending
   queries to the same SUT at the same time.

   Management queries MUST  be  made  in  accordance  with  the  applicable
   specification,  e.g.,  ILMI  sysUpTime  getNext requests will be made in
   accordance with ILMI 4.0. The response to the query MUST be verified  by
   the test equipment. Note that, for each management protocol in use, this
   requires that the test equipment implement the associated protocol state
   machine.   One  example of the specific query IP PDU that should be used
   is shown in Appendix B.

2.9.2. Routing update IP PDUs

   The processing of PNNI updates could have a significant  impact  on  the
   ability  of  a  switch  to forward cells and complete calls.  If PNNI is
   configured on the SUT, one routing update MUST be transmitted before the
   first  test  IP  PDU  is  transmitted during the trial.  The test SHOULD
   verify that the SUT has properly processed the routing update.

   PNNI routing update IP PDUs SHOULD be sent  at  the  rate  specified  in
   Appendix  B.  Appendix  C defines two routing update PDUs for the TCP/IP
   over ATM example.  The  routing  updates  are  designed  to  change  the
   routing  on a number of networks that are not involved in the forwarding
   of the test data.  The first IP PDU sets the routing table state to "A",
   the second one changes the state to "B".  The IP PDUs MUST be alternated
   during the trial. The test SHOULD  verify  that  the  SUT  has  properly
   processed the routing update.

2.10. Filters

   Filters  are  added to switches to selectively inhibit the forwarding of
   cells that would  normally  be  forwarded.   This  is  usually  done  to
   implement  security  controls  on  the data that is accepted between one
   area and another. Different  products  have  different  capabilities  to
   implement  filters.  Filters are applicable only if the SUT supports the
   filtering feature.

   The SUT SHOULD be first configured to add one filter condition  and  the
   tests  performed.   This filter SHOULD permit the forwarding of the test
   data stream. This filter SHOULD be of the form:

        To be determined. 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 of the form:

        To be determined. 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. 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. Protocol addresses

   It is easier to implement these tests using a single logical  stream  of
   data,  with  one source ATM address and one destination ATM address, and
   for some conditions  like  the  filters  described  above,  a  practical
   requirement.   Networks  in  the  real  world  are not limited to single
   streams of data. The test suite SHOULD be first run with  a  single  ATM
   source  and destination address pair.  The tests SHOULD then be repeated
   with using a random destination address.  In the case of testing  single
   switches,  the addresses SHOULD be random and uniformly distributed over
   a range of 256 seven octet user parts.  In the case of testing  multiple
   interconnected  switches,  the  addresses SHOULD be random and uniformly
   distributed over the 256 network prefixes, each of which should  support
   256  seven octet user parts.  The specific address ranges to use for ATM
   are shown in Appendix B.  IP to ATM address mapping MUST be accomplished
   as described in RFC 2225.

2.12. Route Set Up

   It  is  not  reasonable that all of the routing information necessary to
   forward the test stream, especially in the multiple address  case,  will
   be  manually  set  up.  If PNNI and/or ILMI are running, at the start of
   each trial a routing update MUST be sent to the SUT. This routing update
   MUST  include  all  of  the  ATM addresses that will be required for the
   trial. This routing update will have to  be  repeated  at  the  interval
   required  by  PNNI  or  ILMI.   An  example of the format and repetition
   interval of the update IP PDUs is given in Appendix B.

2.13. Bidirectional traffic

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

2.14. Single stream path

   The full suite of tests SHOULD be run with the appropriate modifiers for
   a single receive and transmit port on the SUT. If the internal design of
   the SUT has multiple distinct pathways, for example, multiple  interface
   cards  each  with multiple network ports, then all possible permutations
   of pathways SHOULD be tested  separately.   If  multiple  interconnected
   switches  are tested, the test MUST specify routes, which allow only one
   path between source and destination ATM addresses.

2.15. Multi-port

   Many switch products provide several network ports on the same interface
   module.  Each  port  on  an  interface module SHOULD be stimulated in an
   identical manner.  Specifically, half of the ports on each module SHOULD
   be  receive  ports  and half SHOULD be transmit ports.  For example if a
   SUT has two interface module each of which has four ports, two ports  on
   each  interface  module be receive ports and two will be transmit ports.
   Each receive port MUST be offered the same data rate.  The addresses  in
   the  input data streams SHOULD be set so that an IP PDU will be directed
   to each of the transmit ports in sequence.  That is, all transmit  ports
   will  receive  an  identical  distribution  of IP PDUs from a particular
   receive port.

   Consider the following 6 port SUT:

             --------------
    ---------| Rx A   Tx X|--------
    ---------| Rx B   Tx Y|--------
    ---------| Rx C   Tx Z|--------
             --------------

   The addressing of the data streams for each of the inputs SHOULD be:

     stream sent to Rx A:
       IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
     stream sent to Rx B:
       IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
     stream sent to Rx C
       IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z

   Note:  Each  stream  contains  the  same  sequence  of  IP   destination
   addresses;  therefore,  each  transmit  port  will  receive  3  IP  PDUs
   simultaneously. This procedure ensures that the SUT will have to process
   multiple IP PDUs addressed to the same transmit port simultaneously.

   The  same  configuration  MAY be used to perform a bi-directional multi-
   stream test.  In this case all of the ports are considered both  receive
   and  transmit  ports.   Each  data  stream MUST consist of IP PDUs whose
   addresses correspond to the ATM addresses all of the other ports.

2.16. Multiple protocols

   This document does not address the issue of testing  the  effects  of  a
   mixed  protocol environment other than to suggest that if such tests are
   wanted  then  PDUs  SHOULD  be  distributed  between  all  of  the  test
   protocols.   The  distribution  MAY  approximate  the  conditions on the
   network in which the SUT would be used.

2.17. Multiple IP PDU sizes

   This document does not address the issue of testing  the  effects  of  a
   mixed  IP PDU size environment other than to suggest that, if such tests
   are required, then IP PDU size SHOULD be evenly distributed among all of
   the PDU sizes listed in this document.  The distribution MAY approximate
   the conditions on the network in which the SUT would be used.

2.18. Testing beyond a single SUT

   In the performance  testing  of  a  single  SUT,  the  paradigm  can  be
   described as applying some input to a SUT and monitoring the output. The
   results of which can be used to form a basis of characterization of that
   device under those test conditions.

   This  model  is  useful  when  the  test input and output are homogenous
   (e.g., 64-byte IP, AAL5 PDUs into the SUT; 64 byte IP, AAL5 PDUs out).

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

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

   Or an extended LAN configuration might be:

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

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

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

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

2.19. Maximum IP PDU rate

   The  maximum  IP  PDU  rates  that  should  be  used  when  testing  LAN
   connections SHOULD be the listed theoretical maximum rate for the IP PDU
   size on the media.

   The maximum IP PDU rate that should be used when testing WAN connections
   SHOULD  be  greater  than the listed theoretical maximum rate for the IP
   PDU size on that speed connection.  The higher rate for WAN tests is  to
   compensate for the fact that some vendors employ various forms of header
   compression.

   A list of maximum IP PDU  rates  for  LAN  connections  is  included  in
   Appendix B.

2.20. Bursty traffic

   It is convenient to measure the SUT performance under steady state load;
   however, this is an unrealistic way to gauge the functioning of  a  SUT.
   Actual network traffic normally consists of bursts of IP PDUs.

   Some of the tests described below SHOULD be performed with both constant
   bit rate, bursty Unspecified Bit Rate (UBR) Best Effort [AF-TM4.0]  [AF-TM4.1]  and
   Variable  Bit  Rate Non-real Time (VBR-nrt) Best Effort  [AF-TM4.0]. [AF-TM4.1].  The
   IP PDUs within a burst  are  transmitted  with  the  minimum  legitimate
   inter-IP PDU gap.

   The  objective  of the test is to determine the minimum interval between
   bursts that the SUT can process with no IP PDU loss.   Tests  SHOULD  be
   run with burst sizes of 10% of Maximum Burst Size (MBS), 20% of MBS, 50%
   of MBS and 100% MBS.  Note that the number of IP PDUs in each burst will
   depend  on  the  PDU size. For UBR, the MBS refers to the associated VBR
   traffic parameters.

2.21. Trial description

   A particular test consists of multiple trials.  Each trial  returns  one
   piece of information, for example the loss rate at a particular input IP
   PDU rate.  Each trial consists of five of phases:

   a) If the SUT is a switch supporting PNNI, send the  routing  update  to
   the  SUT  receive  port and wait two seconds to be sure that the routing
   has settled.

   b) Send an ATM ARP PDU to determine the ATM address corresponding to the
   destination  IP  address.  The formats of the ATM ARP PDU that should be
   used are shown in the  Test  Frame  Formats  document  and  MUST  be  in
   accordance with RFC 2225.

   c) Stimulate SUT with traffic load.

   d) Wait for two seconds for any residual IP PDUs to be received.

   e) Wait for at least five seconds for the SUT to restabilize.

2.22. Trial duration
   The  objective  of  the  tests defined in this document is to accurately
   characterize the behavior of a particular  piece  of  network  equipment
   under  varying  traffic  loads.   The  choice of test duration must be a
   compromise between this  objective  and  keeping  the  duration  of  the
   benchmarking  test  suite  within  reasonable bounds.  The SUT SHOULD be
   stimulated for at least 60 seconds.  If this time period  results  in  a
   high  variance  in the test results, the SUT SHOULD be stimulated for at
   least 300 seconds.

2.23. Address resolution

   The SUT MUST be able to respond to address resolution requests  sent  by
   another  SUT, an ATM ARP server or the test equipment in accordance with
   RFC 2225.

2.24. Synchronized Payload Bit Pattern.

   Some measurements assume that both the transmitter and receiver  payload
   information   is  synchronized.  Synchronization  MUST  be  achieved  by
   supplying a known bit pattern to  both  the  transmitter  and  receiver.
   This bit pattern MUST be one of the following: PRBS-15, PRBS-23, 0xFF00,
   or 0xAA55.

2.25. Burst Traffic Descriptors.

   Some measurements require busty traffic patterns.  These  patterns  MUST
   conform to one of the following traffic descriptors:

   1) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=8192

   2) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=4096

   3) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=8192

   4) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=4096

   5) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=8192

   6) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=4096

   7) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=65536
   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. Cell Loss due to 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 maximum
number three  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 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  one  VCC  in  a
transmission 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 one VCC  in  a
transmission 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. Cell Rate Margin (CRM)

   To Be Determined

3.2.3. CRC Error Ratio (CRC-ER)

3.2.3.1.

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

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

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

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

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

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

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

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

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

3.2.5.10. CRC-ER/Bursty Mixed Load/Three VCC

Objective:  To  determine  the  SUT  ratio  of lost cells on  one  VCC  in  a
transmission 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.3.5.

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

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

   3.2.7.1. Test Setup

   The  cell  transfer  delay measurements assume that both the transmitter
   and receiver  timestamp  information  is  synchronized.  Synchronization
   SHOULD  be  achieved  by supplying a common clock signal (minimum of 100
   Mhz or 10 ns resolution) to both  the  transmitter  and  receiver.   The
   maximum  timestamp  values MUST be recorded to ensure synchronization in
   the case of counter rollover.   The  cell  transfer  delay  measurements
   SHOULD  utilize  the  O.191 cell (ITUT-O.191) encapsulated in a valid IP
   packet.  If the O.191 cell is not available, a test cell encapsulated in
   a  valid  IP  packet MAY be used.  The test cell MUST contain a transmit
   timestamp  which  can  be  correlated  with  a  receive   timestamp.   A
   description  of the test cell MUST be included in the test results.  The
   description  MUST  include  the  timestamp  length  (in  bits),  counter
   rollover value, and the timestamp accuracy (in ns).

3.2.7.2. CTD/Steady Load/One VCC

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

Procedure:

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

4. Security Considerations.

   As this document is solely

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 purpose of providing methodology  SUT  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  test  device  using  the implementation  or  use  uni-directional
   configuration.

   2) Send a specific number of cells at a specific rate through  the  technology  described  in  SUT.
   Since this
   document  or test is not a throughput test, the extent to which any license under such rights might or
   might rate should not be available; neither does it represent 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 it has  made  any
   effort to identify any such rights.  Information on  are  transmitted  by  the IETFs procedures
   with  respect  SUT  to  rights  in  standards-track  verify
   connectivity and   standards-related
   documentation  can  be found load.  If the count on the 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 BCP-11.  Copies of claims the first bit of rights made
   available for publication and the AAL5 payload.   Verify  that
   the SUT does not drop any assurances  of  licenses  to  be  made
   available,  or AAL5 PDU's.

   5) Discontinue the result of an attempt made to obtain a general license
   or permission for AAL5 payload error.

   6)  Inject  one  error  in  the use of such proprietary rights by implementors  or
   users  first  bit  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  AAL5  header for 4
   consecutive IP PDUs in every 6 IP PDUs.  Verify that  may  be  required  to practice this
   standard.   Please  address the  information  to SUT  does  drop
   the  IETF   Executive
   Director.

6. Disclaimer

   Copyright (C) AAL5 PDU's.

   7) Discontinue the AAL5 payload error.

Reporting Format:

   The Internet Society (1999). All Rights Reserved.

   This  document  and  translations  results  of  it may be copied and furnished the AAL5 PDU Loss due to
   others, and derivative works that comment on or otherwise explain it  or
   assist  in  its  implementation  may AAL5 PDU errors test SHOULD be prepared, copied, published and
   distributed, in whole or
   reported in  part,  without  restriction a form of  any  kind,
   provided 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.0]

   [AF-TM4.1]  ATM Forum, Traffic Management Specification Version 4.0, 4.1, af-
   tm- 0056.00, 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