RFC 3116

Methodology for ATM Benchmarking

📅 published June 2001, from ietf

Methodology for ATM Benchmarking 🦋

Title block, the tea: this is RFC 3116 from the Network Working Group, written by J. Dunn and C. Martin at ANC, Inc. 💅

Category: Informational 📚
Date: June 2001 🗓️
Obsoletes and updates: the title block doesn't list anything it obsoletes or updates 🌸

Status of this Memo ✨

this memo is giving info for the Internet community 💖 it does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶

Copyright Notice 🎀

Abstract 🔥

okay so this doc talks about and defines a bunch of tests that can be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices 🧚 it also describes specific formats for reporting the results of those tests, so everyone's on the same page 📊

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

Table of Contents 🌈

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1. Test Device Requirements . . . . . . . . . . . . . . . . . .  5
   2.2. Systems Under Test (SUTs). . . . . . . . . . . . . . . . . .  5
   2.3. Test Result Evaluation . . . . . . . . . . . . . . . . . . .  5
   2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.5. Test Configurations for SONET. . . . . . . . . . . . . . . .  6
   2.6. SUT Configuration. . . . . . . . . . . . . . . . . . . . . .  7
   2.7. Frame Formats. . . . . . . . . . . . . . . . . . . . . . . .  8
   2.8. Frame Sizes. . . . . . . . . . . . . . . . . . . . . . . . .  8
   2.9. Verifying Received IP PDU's. . . . . . . . . . . . . . . . .  9
   2.10. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . .  9
   2.10.1. Management IP PDU's . . . . . . . . . . . . . . . . . . .  9
   2.10.2. Routing Update IP PDU's . . . . . . . . . . . . . . . . . 10
   2.11. Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   2.11.1. Filter Addresses. . . . . . . . . . . . . . . . . . . . . 11
   2.12. Protocol Addresses. . . . . . . . . . . . . . . . . . . . . 12
   2.13. Route Set Up. . . . . . . . . . . . . . . . . . . . . . . . 12
   2.14. Bidirectional Traffic . . . . . . . . . . . . . . . . . . . 12
   2.15. Single Stream Path. . . . . . . . . . . . . . . . . . . . . 12
   2.16. Multi-port. . . . . . . . . . . . . . . . . . . . . . . . . 13
   2.17. Multiple Protocols. . . . . . . . . . . . . . . . . . . . . 14
   2.18. Multiple IP PDU Sizes . . . . . . . . . . . . . . . . . . . 14
   2.19. Testing Beyond a Single SUT . . . . . . . . . . . . . . . . 14
   2.20. Maximum IP PDU Rate . . . . . . . . . . . . . . . . . . . . 15
   2.21. Busty Traffic . . . . . . . . . . . . . . . . . . . . . . . 15
   2.22. Trial Description . . . . . . . . . . . . . . . . . . . . . 16
   2.23. Trial Duration. . . . . . . . . . . . . . . . . . . . . . . 16
   2.24. Address Resolution. . . . . . . . . . . . . . . . . . . . . 16
   2.25. Synchronized Payload Bit Pattern. . . . . . . . . . . . . . 16
   2.26. Burst Traffic Descriptors . . . . . . . . . . . . . . . . . 17
   3. Performance Metrics. . . . . . . . . . . . . . . . . . . . . . 17
   3.1. Physical Layer-SONET . . . . . . . . . . . . . . . . . . . . 17
   3.1.1. Pointer Movements. . . . . . . . . . . . . . . . . . . . . 17
   3.1.1.1. Pointer Movement Propagation . . . . . . . . . . . . . . 17
   3.1.1.2. Cell Loss due to Pointer Movement. . . . . . . . . . . . 19
   3.1.1.3. IP Packet Loss due to Pointer Movement . . . . . . . . . 20
   3.1.2. Transport Overhead (TOH) Error Count . . . . . . . . . . . 21
   3.1.2.1. TOH Error Propagation. . . . . . . . . . . . . . . . . . 21
   3.1.2.2. Cell Loss due to TOH Error . . . . . . . . . . . . . . . 22
   3.1.2.3. IP Packet Loss due to TOH Error. . . . . . . . . . . . . 23
   3.1.3. Path Overhead (POH) Error Count. . . . . . . . . . . . . . 24
   3.1.3.1. POH Error Propagation. . . . . . . . . . . . . . . . . . 24
   3.1.3.2. Cell Loss due to POH Error . . . . . . . . . . . . . . . 25
   3.1.3.3. IP Packet Loss due to POH Error. . . . . . . . . . . . . 26
   3.2. ATM Layer. . . . . . . . . . . . . . . . . . . . . . . . . . 27
   3.2.1. Two-Point Cell Delay Variation (CDV) . . . . . . . . . . . 27
   3.2.1.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 27
   3.2.1.2. Two-point CDV/Steady Load/One VCC. . . . . . . . . . . . 27
   3.2.1.3. Two-point CDV/Steady Load/Twelve VCCs. . . . . . . . . . 28
   3.2.1.4. Two-point CDV/Steady Load/Maximum VCCs . . . . . . . . . 30
   3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC. . . . . . . . . . 31
   3.2.1.6. Two-point CDV/Bursty VBR Load/Twelve VCCs. . . . . . . . 32
   3.2.1.7. Two-point CDV/Bursty VBR Load/Maximum VCCs . . . . . . . 34
   3.2.1.8. Two-point CDV/Mixed Load/Three VCC's . . . . . . . . . . 35
   3.2.1.9. Two-point CDV/Mixed Load/Twelve VCCs . . . . . . . . . . 36
   3.2.1.10. Two-point CDV/Mixed Load/Maximum VCCs . . . . . . . . . 38
   3.2.2. Cell Error Ratio (CER) . . . . . . . . . . . . . . . . . . 39
   3.2.2.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 39
   3.2.2.2. CER/Steady Load/One VCC. . . . . . . . . . . . . . . . . 40
   3.2.2.3. CER/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 41
   3.2.2.4. CER/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 42
   3.2.2.5. CER/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 43
   3.2.2.6. CER/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 44
   3.2.2.7. CER/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 46
   3.2.3. Cell Loss Ratio (CLR). . . . . . . . . . . . . . . . . . . 47
   3.2.3.1. CLR/Steady Load/One VCC. . . . . . . . . . . . . . . . . 47
   3.2.3.2. CLR/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 48
   3.2.3.3. CLR/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 49
   3.2.3.4. CLR/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 51
   3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 52
   3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 53
   3.2.4. Cell Misinsertion Rate (CMR) . . . . . . . . . . . . . . . 54
   3.2.4.1. CMR/Steady Load/One VCC. . . . . . . . . . . . . . . . . 54
   3.2.4.2. CMR/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 55
   3.2.4.3. CMR/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 57
   3.2.4.4. CMR/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 58
   3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 59
   3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 60
   3.2.5. CRC Error Ratio (CRC-ER) . . . . . . . . . . . . . . . . . 62
   3.2.5.1. CRC-ER/Steady Load/One VCC . . . . . . . . . . . . . . . 62
   3.2.5.2. CRC-ER/Steady Load/Twelve VCCs . . . . . . . . . . . . . 63
   3.2.5.3. CRC-ER/Steady Load/Maximum VCCs. . . . . . . . . . . . . 64
   3.2.5.4. CRC-ER/Bursty VBR Load/One VCC . . . . . . . . . . . . . 65
   3.2.5.5. CRC-ER/Bursty VBR Load/Twelve VCCs . . . . . . . . . . . 66
   3.2.5.6. CRC-ER/Bursty VBR Load/Maximum VCCs. . . . . . . . . . . 68
   3.2.5.7. CRC-ER/Bursty UBR Load/One VCC . . . . . . . . . . . . . 69
   3.2.5.8. CRC-ER/Bursty UBR Load/Twelve VCCs . . . . . . . . . . . 70
   3.2.5.9. CRC-ER/Bursty UBR Load/Maximum VCCs. . . . . . . . . . . 71
   3.2.5.10. CRC-ER/Bursty Mixed Load/Three VCC. . . . . . . . . . . 73
   3.2.5.11. CRC-ER/Bursty Mixed Load/Twelve VCCs. . . . . . . . . . 74
   3.2.5.12. CRC-ER/Bursty Mixed Load/Maximum VCCs . . . . . . . . . 75
   3.2.6. Cell Transfer Delay (CTD). . . . . . . . . . . . . . . . . 76
   3.2.6.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 76
   3.2.6.2. CTD/Steady Load/One VCC. . . . . . . . . . . . . . . . . 77
   3.2.6.3. CTD/Steady Load/Twelve VCCs. . . . . . . . . . . . . . . 78
   3.2.6.4. CTD/Steady Load/Maximum VCCs . . . . . . . . . . . . . . 79
   3.2.6.5. CTD/Bursty VBR Load/One VCC. . . . . . . . . . . . . . . 81
   3.2.6.6. CTD/Bursty VBR Load/Twelve VCCs. . . . . . . . . . . . . 82
   3.2.6.7. CTD/Bursty VBR Load/Maximum VCCs . . . . . . . . . . . . 83
   3.2.6.8. CTD/Bursty UBR Load/One VCC. . . . . . . . . . . . . . . 85
   3.2.6.9. CTD/Bursty UBR Load/Twelve VCCs. . . . . . . . . . . . . 86
   3.2.6.10. CTD/Bursty UBR Load/Maximum VCCs. . . . . . . . . . . . 87
   3.2.6.11. CTD/Mixed Load/Three VCC's. . . . . . . . . . . . . . . 88
   3.2.6.12. CTD/Mixed Load/Twelve VCCs. . . . . . . . . . . . . . . 90
   3.2.6.13. CTD/Mixed Load/Maximum VCCs . . . . . . . . . . . . . . 91
   3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5) . . . . . . . . . . 93
   3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors. . . . . . . 93
   3.3.2. AAL5 Re-assembly Time. . . . . . . . . . . . . . . . . . . 94
   3.3.3. AAL5 CRC Error Ratio . . . . . . . . . . . . . . . . . . . 95
   3.3.3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 95
   3.3.3.2. AAL5-CRC-ER/Steady Load/One VCC. . . . . . . . . . . . . 95
   3.3.3.3. AAL5-CRC-ER/Steady Load/Twelve VCCs. . . . . . . . . . . 96
   3.3.3.4. AAL5-CRC-ER/Steady Load/Maximum VCCs . . . . . . . . . . 97
   3.3.3.5. AAL5-CRC-ER/Bursty VBR Load/One VCC. . . . . . . . . . . 99
   3.3.3.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs. . . . . . . . .100
   3.3.3.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs . . . . . . . .101
   3.3.3.8. AAL5-CRC-ER/Mixed Load/Three VCC's . . . . . . . . . . .102
   3.3.3.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs . . . . . . . . . . .104
   3.3.3.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs . . . . . . . . . .105
   3.4. ATM Service: Signaling . . . . . . . . . . . . . . . . . . .106
   3.4.1. CAC Denial Time and Connection Establishment Time. . . . .106
   3.4.2. Connection Teardown Time . . . . . . . . . . . . . . . . .107
   3.4.3. Crankback Time . . . . . . . . . . . . . . . . . . . . . .108
   3.4.4. Route Update Response Time . . . . . . . . . . . . . . . .109
   3.5. ATM Service: ILMI. . . . . . . . . . . . . . . . . . . . . .110
   3.5.1. MIB Alignment Time . . . . . . . . . . . . . . . . . . . .110
   3.5.2. Address Registration Time. . . . . . . . . . . . . . . . .111
   4. Security Considerations  . . . . . . . . . . . . . . . . . . .112
   5. Notices. . . . . . . . . . . . . . . . . . . . . . . . . . . .112
   6. References . . . . . . . . . . . . . . . . . . . . . . . . . .113
   7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .113
   APPENDIX A  . . . . . . . . . . . . . . . . . . . . . . . . . . .114
   APPENDIX B  . . . . . . . . . . . . . . . . . . . . . . . . . . .114
   APPENDIX C  . . . . . . . . . . . . . . . . . . . . . . . . . . .116
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . .127

1. Introduction ✨

okay bestie, so this doc defines a specific set of tests that vendors can use to measure and report the performance characteristics of ATM network devices 🧁 the results give users comparable data from different vendors so they can evaluate these devices side by side, which is literally the whole point 💅

the methods 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 used in this document 📖 the terminology document should be consulted before you try to use this doc, so go read that first, no skipping 🙈

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, and the Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents 🫶

2. Background 🌈

2.1. Test Device Requirements 🎀

okay so the whole doc is built on one big assumption: you need a test device 💖 Good news, it can be off the shelf, or you can easily build one with today's tech. It has to have a transmitting and receiving port for the interface type you're testing, and it must be set up to transmit test PDUs and analyze the ones it gets back. It should also be able to transmit and analyze received data at the same time 🫶

2.2. Systems Under Test (SUTs) 💅

not every test in here applies to every SUT, so don't panic 😭 vendors should run every test their product type supports. And ngl, running all the recommended tests under all the recommended conditions takes a minute. Like, some time 🕰️

2.3. Test Result Evaluation 🔥

running everything here gives you a LOT of data 💀 whether it's useful depends on how the SUT is actually going to be used and how the network around it is set up. Example: a switch giving ILMI services doesn't matter in a network that doesn't use the ILMI protocol, like an ATM WAN. Figuring out which data is relevant to a specific install can take real experience, which not everyone has. And finally, picking tests and reading the results has to be done with a good understanding of the usual testing practices around repeatability, variance, and statistical significance when you've only got a small number of trials 🧚

2.4. Requirements 👑

so in this doc, the words that set how strict each requirement is get capitalized. Here they 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 called "unconditionally compliant" 🌟 and one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is called "conditionally compliant" 💜

2.5. Test Configurations for SONET 🦋

the test device can hook up to the SUT in a few different ways, depending on the test point. These are the configurations the tests in this doc use.

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

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

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

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

                          Figure 3

2.6. SUT Configuration 💖

the SUT MUST be configured as described in the SUT users guide 📖 it's expected that all of the supported protocols get configured and enabled, and that every test runs without changing the SUT's configuration or setup in any way other than what that specific test needs. For example, it's not acceptable to disable all but one transport protocol when you're testing the throughput of that protocol 🙅‍♀️ if PNNI or BISUP is used to start switched virtual connections (SVCs), the SUT configuration SHOULD include the normally recommended routing update intervals and keep alive frequency. And the specific software version plus the exact SUT configuration, including which functions are disabled and used during the tests, MUST be included in the report of the results 📝

2.7. Frame formats 🌸

the formats of the test IP PDUs for TCP/IP and UPC/IP over ATM are shown in Appendix C: Test Frame Formats. These IP PDUs follow RFC 2225, btw. These exact IP PDU formats SHOULD be used in the tests in this doc for this protocol and media combo. They also act as a template for testing other protocol and media combinations. The specific formats used to define the test IP PDUs for a particular test series MUST be included in the report of the results 🎀

2.8. Frame sizes 🍓

all of the described tests SHOULD be run using a bunch 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, plus enough sizes in between to fully characterize the SUT's performance. Unless noted otherwise, at least five IP PDU sizes SHOULD be tested for each test condition 🤩

Theoretically, the minimum size UDP Echo request IP PDU would be made of an IP header (minimum length 20 octets), a UDP header (8 octets), an AAL5 trailer (8 octets), and an LLC/SNAP code point header (8 octets). So the minimum size PDU fits into one ATM cell 🦋 The theoretical maximum IP PDU size is set by the size of the length field in the IP header. But honestly, in almost every case the real max and min sizes are decided by the limits of the media. For ATM, the maximum IP PDU size SHOULD be the ATM MTU size, which is 9180 octets 💅

in theory, it'd be ideal to spread the IP PDU sizes so the theoretical IP PDU rates are evenly distributed. These recommendations use that theory, but they specify IP PDU sizes that are easy to understand and remember 🧠 plus, a lot of the same sizes show up on each media type, so comparing performance is easy peasy.

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, and 44 is recommended so you can directly compare it to token ring performance 🔁 the IP PDU size of 4472 is recommended instead of the theoretical FDDI maximum of 4500 octets, for the same comparison reason. An IP (i.e., not UDP) IP PDU may be used too, if you want a higher data rate, in which case the minimum IP PDU size is 28 octets ✨

2.9. Verifying received IP PDUs 🧚

the test equipment SHOULD discard any IP PDUs received during a test run that aren't actual forwarded test IP PDUs. For example, keep-alive and routing update IP PDUs SHOULD NOT be counted in the received IP PDUs total 🙅‍♀️ either way, 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 them on the received IP PDUs 🔢 if it does, the reported results SHOULD include, on top of the number of IP PDUs dropped, the number 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, so don't skip it 😭

2.10. Modifiers 🌈

it's super useful to characterize the SUT's performance under a bunch of different conditions, and some of them are listed 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 modifying condition separately 🔄 to keep the tests comparable, any IP PDUs needed to generate the modifying conditions (excluding management queries) go in the same data stream as the normal test IP PDUs, taking the place of one of the test IP PDUs. They MUST not be supplied to the SUT on a separate network port 🚫

2.10.1. Management IP PDUs ✨

Okay so most ATM data networks are totally using ILMI, signaling and OAM now 🔥. And in lots of setups, there can be a bunch of management stations all sending queries to the same SUT at the same time, like a group chat that never stops 💀.

Management queries MUST be made following the applicable spec 📋. For example, ILMI sysUpTime getNext requests will be made in accordance with ILMI 4.0. The test equipment MUST verify the response to the query 🕵️. Also, for each management protocol in use, the test equipment has to implement the associated protocol state machine, so it's not just vibes, it's the actual state machine 🤓. One example of the specific query IP PDU (ICMP) that should be used is shown in Appendix C 🎀.

2.10.2. Routing update IP PDUs 🛣️

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

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

2.11. Filters 🚫

Filters are added to switches to selectively inhibit the forwarding of cells that would normally be forwarded. This is usually done for security controls on what data gets accepted between one area and another 🔐. Different products have different capabilities when it comes to filters, and filters only apply if the SUT supports the filtering feature.

First up, the SUT SHOULD be configured with one filter condition, and then the tests get performed 💖. This filter SHOULD permit the forwarding of the test data stream. It SHOULD be of the form described in the SUT Users Guide.

Then the SUT SHOULD be reconfigured to implement a total of 25 filters. The first 24 of these filters SHOULD be based on 24 separate ATM NSAP Network Prefix addresses. The 24 ATM NSAP Network Prefix addresses SHOULD not be any that are represented in the test data stream. The last filter SHOULD permit the forwarding of the test data stream.

By "first" and "last," we mean 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 doesn't use a linear scan of the filter rules, the effect of the sequence in which the filters are input is properly lost 🙃.

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

2.11.1. Filter Addresses 🏷️

Two sets of filter addresses are required, one for the single filter case and one for the 25 filter case 👯.

For the single filter case, the filter 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 ⚠️.

For the 25 filter case, the filters should follow this 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 picked to test whether the switch sorts the filter conditions or accepts them in the order they were entered 👀. Both of these procedures will have a bigger performance hit than some form of hash coding would 🐢.

2.12. Protocol addresses 🌍

It's easier to run these tests with a single logical stream of data, with one source ATM address and one destination ATM address, and for some conditions like the filters above, that's a practical requirement 📚. But real-world networks aren't limited to single streams, so the test suite SHOULD be first run with a single ATM source and destination address pair. The tests SHOULD then be repeated using a random destination address 🎲.

When testing single switches, the addresses SHOULD be random and uniformly distributed over a range of 256 seven octet user parts. When testing multiple interconnected switches, the addresses SHOULD be random and uniformly distributed over the 256 network prefixes, and each of those should support 256 seven octet user parts. The specific ATM address ranges to use are shown in Appendix A. IP to ATM address mapping MUST be accomplished as described in RFC 2225 🗺️.

2.13. Route Set Up 🛤️

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

2.14. Bidirectional traffic ↔️

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

2.15. Single stream path 🎯

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

2.16. Multi-port 🔌

Many switch products provide several network ports on the same interface module. Each port on an interface module SHOULD be stimulated in an identical manner. Specifically, half of the ports on each module SHOULD be receive ports and half SHOULD be transmit ports. For example, if a SUT has two interface modules, each of which has four ports, then two ports on each interface module will 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, so each transmit port will receive 3 IP PDUs simultaneously. This procedure makes sure the SUT has to process multiple IP PDUs addressed to the same transmit port at the same time 😤.

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 of all of the other ports 💜.

2.17. Multiple protocols 🧩

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

2.18. Multiple IP PDU sizes 📏

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

2.19. Testing beyond a single SUT 🦋

okay so when you performance test a single SUT, the vibe is basically: throw some input at it, watch what comes out, and use that to describe how the device behaves under those exact test conditions. ✨

this model slaps when the input and output are homogeneous, like 64-byte IP, AAL5 PDUs going in and 64 byte IP, AAL5 PDUs coming out. 💅

but bestie, we can level up! by extending the single SUT model, you can collect reasonable benchmarks for multiple SUTs or heterogeneous environments. the single SUT gets swapped out for a whole system of interconnected network SUTs. this methodology supports benchmarking a bunch of device/media/service/protocol combos. for a LAN-to-WAN-to-LAN test, a configuration could look like this:

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

or an extended LAN setup could look like this:

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

in both examples 1 and 2, you can empirically figure out end-to-end benchmarks of each system 🌈. other behavior can be characterized by using intermediate devices too. in example 2, the configuration can give you an indication of how PNNI routing affects IP throughput. 🧚

ngl there are limits though 💀. since multiple SUTs get treated as one single system, this methodology may give you an aggregate benchmark for the tested system. that benchmark on its own, however, may not necessarily reflect asymmetries in behavior between the SUTs, or latencies introduced by other apparatus (e.g., CSUs/DSUs, switches), etc.

also, be careful when comparing benchmarks of different systems! you need to make sure the SUTs' features and the configuration of the tested systems have the appropriate common denominators so the comparison actually works. 🫶

2.20. Maximum IP PDU rate 🍓

for LAN connections, the maximum IP PDU rates you use when testing SHOULD be the listed theoretical maximum rate for the IP PDU size on the media. ✨

for WAN connections, the maximum IP PDU rate you use when testing SHOULD be greater than the listed theoretical maximum rate for the IP PDU size on that speed connection. why the higher rate for WAN? because some vendors use various forms of header compression, and the extra headroom compensates for that. 🎀

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

2.21. Bursty traffic 🌸

it's convenient to measure SUT performance under steady state load, but honestly? that's an unrealistic way to judge how a SUT is functioning 🙈. real network traffic usually comes in bursts of IP PDUs.

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

the goal here is to find 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. heads up: the number of IP PDUs in each burst depends on the PDU size 👑. for UBR, the MBS refers to the associated VBR traffic parameters.

2.22. Trial description 🎀

a particular test is made up of multiple trials. each trial returns one piece of info, like the loss rate at a particular input IP PDU rate. each trial consists of five of phases:

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.
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. 🧚
Stimulate SUT with traffic load. 💅
Wait for two seconds for any residual IP PDUs to be received.
Wait for at least five seconds for the SUT to restabilize. 😭

2.23. Trial duration ⏱️

the whole point of the tests in this document is to accurately characterize how a particular piece of network equipment behaves under varying traffic loads. picking the test duration is a compromise between that goal and keeping the benchmarking test suite within reasonable bounds. the SUT SHOULD be stimulated for at least 60 seconds. if that time period results in high variance in the test results, the SUT SHOULD be stimulated for at least 300 seconds. 🦋

2.24. Address resolution 💖

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

2.25. Synchronized Payload Bit Pattern. 🌈

some measurements assume that both the transmitter and receiver payload info 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.26. Burst Traffic Descriptors. 💜

some measurements need bursty traffic patterns. these patterns MUST conform to one of the following traffic descriptors:

PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=8192
PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=4096
PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=8192
PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=4096
PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=8192
PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=4096
PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=65536
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:

Set up the SUT and test device using the uni-directional configuration.
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.
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.
Inject one forward payload pointer movement. Verify that the SUT does not change the pointer.
Inject one forward payload pointer movement every 1 second. Verify that the SUT does not change the pointer.
Discontinue the payload pointer movement.
Inject five forward payload pointer movements every 1 second. Verify that the SUT does not change the pointer.
Discontinue the payload pointer movement.
Inject one backward payload pointer movement. Verify that the SUT does not change the pointer.
Inject one backward payload pointer movement every 1 second. Verify that the SUT does not change the pointer.
Discontinue the payload pointer movement.
Inject five backward payload pointer movements every 1 second. Verify that the SUT does not change the pointer.
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:

Set up the SUT and test device using the uni-directional configuration.
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.
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.
Inject one forward payload pointer movement. Verify that the SUT does not drop any cells.
Inject one forward payload pointer movement every 1 second. Verify that the SUT does not drop any cells.
Discontinue the payload pointer movement.
Inject five forward payload pointer movements every 1 second. Verify that the SUT does not drop any cells.
Discontinue the payload pointer movement.
Inject one backward payload pointer movement. Verify that the SUT does not drop any cells.
Inject one backward payload pointer movement every 1 second. Verify that the SUT does not drop any cells.
Discontinue the payload pointer movement.
Inject five backward payload pointer movements every 1 second. Verify that the SUT does not drop any cells.
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 ✨

okay so Objective: we're checking if the SUT drops IP packets when pointer movements happen, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the uni-directional configuration. 🎀
Send a specific number of IP packets at a specific rate through the SUT. Since this isn't a throughput test, keep the rate at or below 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 💅
Count the IP packets the SUT transmits to confirm connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match. 🧮
Inject one forward payload pointer movement. Verify that the SUT does not drop any packets. 👀
Inject one forward payload pointer movement every 1 second. Verify that the SUT does not drop any packets. 🌸
Discontinue the payload pointer movement. ⭐
Inject five forward payload pointer movements every 1 second. Verify that the SUT does not drop any packets. 🔥
Discontinue the payload pointer movement. ⭐
Inject one backward payload pointer movement. Verify that the SUT does not drop any packets. 🦋
Inject one backward payload pointer movement every 1 second. Verify that the SUT does not drop any packets. 💜
Discontinue the payload pointer movement. ⭐
Inject five backward payload pointer movements every 1 second. Verify that the SUT does not drop any packets. 🌈
Discontinue the payload pointer movement. ✨

Reporting Format:

bestie, the results of this IP packet loss due to pointer movement test SHOULD be reported as 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 column 1 elements SHOULD be either True or False, showing whether that condition was observed in each test. The column 2 elements SHOULD be non-negative integers. 🎀

The table MUST also show the packet size in octets and the traffic rate in packets per second that the test device generated. no skipping this part, it's literally the whole point 💅

3.1.2. Transport Overhead (TOH) Error Count 🧚

3.1.2.1. TOH Error Propagation. 🫶

Objective: make sure the SUT doesn't propagate TOH errors, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the uni-directional configuration. 🎀
Send a specific number of IP PDUs at a specific rate through the SUT. Since this isn't a throughput test, keep the rate at or below 90% of line rate. The cell payload SHOULD contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 💖
Count the IP PDUs the SUT transmits to confirm connectivity and load. If the count on the test device matches the count on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match. 🧮
Inject one error in the first bit of the A1 and A2 Frameword. Verify that the SUT does not propagate the error. 👀
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. 🌸
Discontinue the Frameword error. ⭐
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. 😭
Discontinue the Frameword error. ⭐

Reporting Format:

the results of this TOH error propagation test SHOULD be reported as 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, showing whether that condition was observed in each test. 🎀

The table MUST also show the IP PDU size in octets and the traffic rate in IP PDUs per second that the test device generated. 💅

3.1.2.2. c TOH Error. 🌸

Objective: check whether the SUT drops cells because of TOH errors, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the uni-directional configuration. 🎀
Send a specific number of cells at a specific rate through the SUT. Since this isn't a throughput test, keep the rate at or below 90% of line rate. The cell payload SHOULD contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 💖
Count the cells the SUT transmits to confirm connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match. 🧮
Inject one error in the first bit of the A1 and A2 Frameword. Verify that the SUT does not drop any cells. 👀
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. 🌸
Discontinue the Frameword error. ⭐
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. 💀
Discontinue the Frameword error. ⭐

Reporting Format:

the results of this Cell Loss due to TOH errors test SHOULD be reported as 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 column 1 elements SHOULD be either True or False, showing whether that condition was observed in each test. The column 2 elements SHOULD be non-negative integers. 🎀

The table MUST also show the traffic rate in IP PDUs per second that the test device generated. 💅

3.1.2.3. IP Packet Loss due to TOH Error. 🦋

Objective: find out if the SUT drops IP packets because of TOH errors, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🌈

Procedure:

Set up the SUT and test device using the uni-directional configuration. 🎀
Send a specific number of IP packets at a specific rate through the SUT. Since this isn't a throughput test, keep the rate at or below 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 💅
Count the IP packets the SUT transmits to confirm connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match. 🧮
Inject one error in the first bit of the A1 and A2 Frameword. Verify that the SUT does not drop any packets. 👀
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. 🌸
Discontinue the Frameword error. ⭐
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. 💀
Discontinue the Frameword error. ⭐

Reporting Format:

the results of this IP packet loss due to TOH errors test SHOULD be reported as 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 column 1 elements SHOULD be either True or False, showing whether that condition was observed in each test. The column 2 elements SHOULD be non-negative integers. 🎀

The table MUST also show the packet size in octets and the traffic rate in packets per second that the test device generated. 💅

3.1.3. Path Overhead (POH) Error Count 🧚

3.1.3.1. POH Error Propagation. 🫶

Objective: make sure the SUT doesn't propagate POH errors, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the uni-directional configuration. 🎀
Send a specific number of IP PDUs at a specific rate through the SUT. Since this isn't a throughput test, keep the rate at or below 90% of line rate. The cell payload SHOULD contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 💖
Count the IP PDUs the SUT transmits to confirm connectivity and load. If the count on the test device matches the count on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match. 🧮
Inject one error in the B3 (Path BIP8) byte. Verify that the SUT does not propagate the error. 👀
Inject one error in the B3 byte every 1 second. Verify that the SUT does not propagate the error. 🌸
Discontinue the POH error. ⭐

Reporting Format:

the results of this POH error propagation test SHOULD be reported as 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, showing whether that condition was observed in each test. 🎀

The table MUST also show the IP PDU size in octets and the traffic rate in IP PDUs per second that the test device generated. 💅

3.1.3.2. Cell Loss due to POH Error. 🌸

Objective: check whether the SUT drops cells because of POH errors, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the uni-directional configuration. 🎀
Send a specific number of cells at a specific rate through the SUT. Since this isn't a throughput test, keep the rate at or below 90% of line rate. The cell payload SHOULD contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 💖
Count the cells the SUT transmits to confirm connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match. 🧮
Inject one error in the B3 (Path BIP8) byte. Verify that the SUT does not drop any cells. 👀
Inject one error in the B3 byte every 1 second. Verify that the SUT does not drop any cells. 🌸
Discontinue the POH error. ⭐

Reporting Format:

the results of this Cell Loss due to POH errors test SHOULD be reported as 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 column 1 elements SHOULD be either True or False, showing whether that condition was observed in each test. The column 2 elements SHOULD be non-negative integers. 🎀

The table MUST also show the traffic rate in IP PDUs per second that the test device generated. 💅

3.1.3.3. IP Packet Loss due to POH Error 🎀

okay bestie, this test checks whether the SUT drops IP packets when there are POH errors, as defined in RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure: 🌸

Set up the SUT and test device using the uni-directional configuration.
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.
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.
Inject one error in the B3 (Path BIP8) byte. Verify that the SUT does not drop any packets.
Inject one error in the B3 byte every 1 second. Verify that the SUT does not drop any packets.
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 🔧

okay so the cell delay measurements assume that both the transmitter and receiver timestamp information is synchronized, which is super important 🫶 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: 🌸

Set up the SUT and test device using the bi-directional configuration.
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]). 🍓
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.
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.
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. 📊

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

Set up the SUT and test device using the bi-directional configuration.
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]). 🍓
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.
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.
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. 📊

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

Set up the SUT and test device using the bi-directional configuration.
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]). 🍓
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.
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.
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 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. 📈

3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC 🎀

Objective: okay bestie, the goal here is to figure out how much the SUT's cell transfer delay wobbles with one VCC, using the definitions from RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device in the bi-directional configuration 🦋
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]) 🚫
Send a specific number of IP packets with timestamps at a specific VBR through the SUT over the test VCC. This isn't a throughput test, so the rate should not be greater than 90% of line rate 🌸 The IP PDUs MUST be encapsulated in AAL5 🫶
Count the IP packets the SUT transmits to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts line up 🍓
Record the packet 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 as text, a graph, and a histogram 📊

The text results SHOULD display the numerical CDV values. The values given SHOULD include: the time period of the test in s, the test VPI/VCI value, the total number of cells transmitted and received on the given VPI/VCI during the test as positive integers, the maximum and minimum CDV during the test in us, and the 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 seconds, minutes or days, depending on how long the test is. 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 results MUST also indicate the packet size in octets, the traffic rate in packets per second, and the bearer class as generated by the test device. The 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: same energy, bigger squad. This time we want the SUT's CDV across twelve VCCs, still going by RFC 2761 "Terminology for ATM Benchmarking" 💖

Procedure:

Set up the SUT and test device in the bi-directional configuration 🌸
Configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs. The VCCs 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]) 🚫
Send a specific number of IP packets with timestamps at a specific VBR through the SUT over the test VCCs. Every VPI/VCI pair generates traffic at the same rate 🔥 Since this is not a throughput test, the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🫶
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts are the same 🍓
Record the packet 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 as text, a graph, and histograms 📊

The text results SHOULD display the numerical CDV values. The values given SHOULD include: the time period of the test in s, the test VPI/VCI values, the total number of cells transmitted and received on each VCC during the test as positive integers, the maximum and minimum CDV on each VCC during the test in us, and the 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 seconds, 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, with 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, the traffic rate in packets per second, and the bearer class as generated by the test device. The 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: the big boss level 🌟 Here we want the SUT's CDV with the maximum number of VCCs the SUT supports, still per RFC 2761 "Terminology for ATM Benchmarking" 🫶

Procedure:

Set up the SUT and test device in the bi-directional configuration 🦋
Configure the SUT and test device with the maximum number of VCCs the SUT supports. For example, if the SUT supports 1024 VCCs, define 256 VPIs with 4 VCIs per VPI. The VCCs 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]) 🚫
Send a specific number of IP packets with timestamps at a specific VBR through the SUT over the test VCCs. Every VPI/VCI pair generates traffic at the same rate 🔥 Since this is not a throughput test, the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🫶
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts are the same 🍓
Record the packet 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 as text, graphs, and histograms 📊

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 seconds, 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, with 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, the traffic rate in packets per second, and the bearer class as generated by the test device. The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the created VCC MUST also be indicated 👑

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

Objective: a mixed-bag moment 🍬 We're checking the SUT's CDV across three VCCs, each with a different bearer class, per RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device in the bi-directional configuration 🦋
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]) 🚫
Send a specific number of IP packets with timestamps through the SUT over the test VCCs. Each generated VCC stream MUST match its VCC bearer class. Every VPI/VCI pair generates traffic at the same rate 🔥

Since this is not a throughput test, the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🫶

Count the IP packets the SUT transmits to check connectivity and load. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts are the same 🍓
Record the packet 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 as text, a graph, and a histogram 📊

The graph results SHOULD display the cell delay values. The x-coordinate SHOULD be the test run time in seconds, 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 results MUST also indicate the packet size in octets, the traffic rate in packets per second, and the bearer class as generated by the test device. The 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 ✨

okay bestie, this one is the main event 🦋 we're running twelve VCCs at the same time and checking how much the SUT's cell transfer delay wobbles. the goal comes from RFC 2761 "Terminology for ATM Benchmarking" 💅

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

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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]). 🌸
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. 🔥
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. 🧚
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 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 results MUST also indicate the packet size in octets, traffic rate in packets per second, and bearer class as generated by the test device. The 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 ✨

this is the maxed-out version 😭 we go up to the most VCCs the SUT can handle, and it's giving pure chaos in the best way 🌈

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:

Set up the SUT and test device using the bi-directional configuration. 🎀
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]). 🌸
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. 🔥
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. 🧚
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. 🦋

3.2.2. Cell Error Ratio (CER) 🫶

next up is CER, which is basically counting how many cells came back with errors compared to everything that was sent 🙈

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:

Set up the SUT and test device using the bi-directional configuration. 🎀
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]). 🌸
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. 🔥
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. 🧚
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. 📈💜

3.2.2.3. CER/Steady Load/Twelve VCCs 🦋

Objective: okay so the goal here is to figure out the SUT's ratio of errored cells across twelve VCCs during a transmission, compared to the total cells sent. The definitions come from RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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]). 🌸
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. This is not a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. ✨
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load. If the count on the test device is the same on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match. 🧚
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 as text and a graph. Both are super important, bestie 📊

The text results SHOULD display the numerical values of the CER. The values given SHOULD include:

the time period of the test in s
the test VPI/VCI value
the total number of cells transmitted and received on the given VPI/VCI during the test, in positive integers
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 seconds, minutes, or days, depending on how long the test is. 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, with one curve indicated and labeled for each VCC. The integration time per point MUST be indicated. 📈🌈

3.2.2.4. CER/Steady Load/Maximum VCCs 👑

Objective: this one checks the SUT's ratio of errored cells with the maximum number of VCCs the SUT supports, compared to the total cells sent. Same definitions, RFC 2761 "Terminology for ATM Benchmarking" 🫶

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
Configure the SUT and test device with the maximum number of VCCs the SUT supports. For example, if the SUT supports 1024 VCCs, 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]). 🌸
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. This is not a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. ✨
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load. If the count on the test device is the same on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match. 🧚
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 as text and a graph. 🌟

The text results SHOULD display the numerical values of the CER. The values given SHOULD include:

the time period of the test in s
the test VPI/VCI value
the total number of cells transmitted and received on the given VPI/VCI during the test, in positive integers
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 seconds, minutes, or days, depending on how long the test is. 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, with one curve indicated and labeled for each VCC. The integration time per point MUST be indicated. 📊🦋

3.2.2.5. CER/Bursty VBR Load/One VCC 💅

Objective: here we're checking the SUT's ratio of errored cells on one VCC during a transmission, compared to the total cells sent. The definitions are from RFC 2761 "Terminology for ATM Benchmarking" 🎀

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 🌸
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. This is not a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. ✨
Count the IP packets that the SUT transmits to verify connectivity and load. If the count on the test device is the same on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match. 🧚
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 as text and a graph. 🌈

The text results SHOULD display the numerical values of the CER. The values given SHOULD include:

the time period of the test in s
the test VPI/VCI value
the total number of cells transmitted and received on the given VPI/VCI during the test, in positive integers
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 seconds, minutes, or days, depending on how long the test is. The x-coordinate time SHOULD be configurable. The y-coordinate SHOULD be the CER. The integration time per point MUST be indicated. 📈

3.2.2.6. CER/Bursty VBR Load/Twelve VCCs 🌸

Objective: this is the bursty VBR version with twelve VCCs. We're finding the SUT's ratio of errored cells across them, compared to the total cells sent, using RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 🌸
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. This is not a throughput test, so 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. ✨
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load. If the count on the test device is the same on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match. 🧚
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 as text and a graph. 🦋

The text results SHOULD display the numerical values of the CER. The values given SHOULD include:

the time period of the test in s
the test VPI/VCI value
the total number of cells transmitted and received on the given VPI/VCI during the test, in positive integers
the CER for the entire test

3.2.2.7. CER/Bursty VBR Load/Maximum VCCs ✨

Objective: Okay bestie, this one checks the SUT's ratio of errored cells when it's juggling the maximum number of VCCs it supports in a transmission, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 📚💅

Procedure:

Set up the SUT and test device using the bi-directional configuration 🔌
Configure the SUT and test device with the maximum number of VCCs supported on the SUT. For example, if the max 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 🎀
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 🦋
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 🧮
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. Both are giving main character energy 🌸

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

3.2.3. Cell Loss Ratio (CLR) 🦋

3.2.3.1. CLR/Steady Load/One VCC

Objective: This test is about figuring out the SUT's ratio of lost cells on one VCC in a transmission, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 💖

Procedure:

Set up the SUT and test device using the bi-directional configuration 🔌
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]) 🎀
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 🌈
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 🧮
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 📈

3.2.3.2. CLR/Steady Load/Twelve VCCs

Objective: Now we're testing the SUT's ratio of lost cells across twelve VCCs in a transmission, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device using the bi-directional configuration 🔌
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]) 🎀
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 🦋
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 🧮
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 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 📈

3.2.3.3. CLR/Steady Load/Maximum VCCs

Objective: Last but not least, this one checks the SUT's ratio of lost cells with the maximum number of VCCs it supports in a transmission, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 👑

Procedure:

Set up the SUT and test device using the bi-directional configuration 🔌
Configure the SUT and test device with the maximum number of VCCs supported on the SUT. For example, if the max 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]) 🎀
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 🦋
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 🧮
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 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 📈✨

3.2.3.4. CLR/Bursty VBR Load/One VCC 💌

Objective: Okay so this one checks the SUT's ratio of lost cells on one VCC during a transmission, compared to the total cells sent. It's defined in RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. bestie, this setup step is giving full structure ✨
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. 🦋
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. 🫶
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. 🌸

3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs 🦋

Objective: This one checks the SUT's ratio of lost cells across twelve VCCs during a transmission, compared to the total cells sent. It's defined in RFC 2761 "Terminology for ATM Benchmarking" 💖

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. ✨
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. 💅
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. 🫶
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 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. 📈

3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs 👑

Objective: This one checks the SUT's ratio of lost cells with the maximum number of VCCs the SUT supports during a transmission, compared to the total cells sent. It's defined in RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. the 1024 example is so satisfying 🍓
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. 🦋
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. 🫶
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. 🌸

3.2.4. Cell Misinsertion Rate (CMR) 🌷

3.2.4.1. CMR/Steady Load/One VCC 🎀

Objective: This one checks the SUT's ratio of cell misinsertion on one VCC during a transmission, compared to the total cells sent. It's defined in RFC 2761 "Terminology for ATM Benchmarking" 💜

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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]). ✨
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. 🦋
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. 🫶
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. 📈

3.2.4.2. CMR/Steady Load/Twelve VCCs

Okay bestie, this is the twelve-circuit version of the steady-load misinsertion test 💅

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:

Set up the SUT and test device using the bi-directional configuration. 🎀
Configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs. The VCCs 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]). 🌸
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. ✨
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. 🧚
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 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, one curve indicated and labeled for each VCC. The integration time per point MUST be indicated. 📈🌈

3.2.4.3. CMR/Steady Load/Maximum VCCs

Now we go big: the maximum number of VCCs the SUT supports 😭🔥

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:

Set up the SUT and test device using the bi-directional configuration. 🎀
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 VCCs 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]). 🌸
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. ✨
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. 🧚
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 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. 📈🌈

3.2.4.4. CMR/Bursty VBR Load/One VCC

Bursty traffic now, so the vibes get a little chaotic 🙈

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:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 🌸
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. ✨
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. 🧚
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. 🍓

3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs

Twelve bursty circuits at once, bestie, we are so back 🧚✨

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:

Set up the SUT and test device using the bi-directional configuration. 🎀
Configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs. The VCCs 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. 🌸
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. ✨
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. 🧚
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 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, one curve indicated and labeled for each VCC. The integration time per point MUST be indicated. 📈🌈

3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs ✨

Objective: okay so the goal here is to find the SUT's rate of misinserted cells when it's running the maximum number of VCCs it supports 💖. We measure that against the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🎀.
Configure the SUT and test device with the maximum number of VCCs the SUT supports 👑. For example, if the SUT's max is 1024, define 256 VPIs with 4 VCIs per VPI 🧚. The VCCs 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 🦋.
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 💜.
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load 🔍. If the count on the test device is the same as on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match 🫶.
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 as text and a graph 📊.

The text results SHOULD display the numerical values of the CMR. The values given SHOULD include the time period of the test in s, the test VPI/VCI value, the 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 seconds, minutes or days, depending on how long the test is 🕰️. 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, with 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, the traffic rate in packets per second, and the bearer class as generated by the test device 💅. The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the created VCC MUST also be indicated 👑.

3.2.5. CRC Error Ratio (CRC-ER) 🦋

3.2.5.1. CRC-ER/Steady Load/One VCC 💖

Objective: this one is about finding the SUT's ratio of CRC errors on one VCC during a transmission, measured against the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🎀.
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]) 🙈.
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 💜.
Count the IP packets that the SUT transmits to verify connectivity and load 🔍. If the count on the test device is the same as on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match 🫶.
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 as text and a graph 📊.

The text results SHOULD display the numerical values of the CRC-ER. The values given SHOULD include the time period of the test in s, the test VPI/VCI value, the 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 seconds, minutes or days, depending on how long the test is 🕰️. The x-coordinate time SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The integration time per point MUST be indicated ⭐.

3.2.5.2. CRC-ER/Steady Load/Twelve VCCs 🌸

Objective: this one checks the SUT's ratio of lost cells on twelve VCCs during a transmission, measured against the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🎀.
Configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs 🧚. The VCCs 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]) 🙈.
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 💜.
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load 🔍. If the count on the test device is the same as on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match 🫶.
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 as text and a graph 📊.

The graph results SHOULD display the CRC Error ratio values. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is 🕰️. 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, with one curve indicated and labeled for each VCC 🌈. The integration time per point MUST be indicated ⭐.

3.2.5.3. CRC-ER/Steady Load/Maximum VCCs 👑

Objective: this is the big one: the SUT's ratio of lost cells with the maximum number of VCCs it supports during a transmission, measured against the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🎀.
Configure the SUT and test device with the maximum number of VCCs the SUT supports 👑. For example, if the SUT's max is 1024, define 256 VPIs with 4 VCIs per VPI 🧚. The VCCs 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]) 🙈.
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 💜.
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load 🔍. If the count on the test device is the same as on the SUT, keep going. Otherwise, lower the test device traffic rate until the counts match 🫶.
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 as text and a graph 📊.

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 seconds, minutes or days, depending on how long the test is 🕰️. 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, with one curve indicated and labeled for each VCC 🌈. The integration time per point MUST be indicated ⭐.

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

Objective: okay so the goal here is to figure out the SUT's ratio of lost cells on one VCC, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 📚✨

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 💅
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. 🦋
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. 🧚
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. 📈

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

Objective: bestie, this one checks the SUT's ratio of lost cells across twelve VCCs, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 💖
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. 💅
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. 🧚
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 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. 🌈

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

Objective: this is the big one, babe 😭 It checks the SUT's ratio of lost cells with the maximum number of VCCs the SUT supports, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 💖
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. 🦋
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. 🧚
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 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. 📈

3.2.5.7. CRC-ER/Bursty UBR Load/One VCC

Objective: same vibe as the first one, but this time it's UBR 🌸 The goal is the SUT's ratio of lost cells on one VCC, compared to the total cells sent, as defined in RFC 2761 "Terminology for ATM Benchmarking" ✨

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
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. 💅
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. 🦋
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. 🧚
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. 🌸

3.2.5.8. CRC-ER/Bursty UBR Load/Twelve VCCs ✨

Objective: okay bestie, this one is all about figuring out what percentage of cells the SUT loses across twelve VCCs during a transmission, compared to the total cells sent 🎀. The terms come from RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🦋.
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, like [0,5] or [0,16] 🙈. The PCR, SCR, and MBS must be configured using one of the specified traffic descriptors 💅.
Send a specific number of IP packets containing one of the specified bit patterns at a specific rate through the SUT over the test VCCs 🚀. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so 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 ✨.
Count the IP packets the SUT transmits on all VCCs to check connectivity and load 🔍. If the count on the test device matches the SUT, keep going. If not, lower the test device rate until the counts line up 📉.
Record the number of CRC errored cells received on each VCC at the test device, for every VCC 🧾.

Reporting Format:

The CRC-ER/Bursty UBR Load/Twelve VCCs results SHOULD be reported as text and a graph 📊.

The text results SHOULD show the numerical CRC-ER values. They SHOULD include the time period of the test in s, the test VPI/VCI value, the total number of cells transmitted and received on that VPI/VCI during the test (as positive integers), and the CRC-ER for the whole test 🔢.

The graph SHOULD display the CRC Error ratio values. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is 🕰️. 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, with each VCC having its own labeled curve 🌈. The integration time per point MUST be indicated ⏱️.

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

3.2.5.9. CRC-ER/Bursty UBR Load/Maximum VCCs 👑

Objective: this is the big-boss version 😤. It finds the SUT's lost-cell ratio when it's running the maximum number of VCCs it supports, compared to the total cells sent. The terms come from RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🦋.
Configure the SUT and test device with the maximum number of VCCs the SUT supports 💖. For example, if the SUT supports 1024 VCCs, 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, like [0,5] or [0,16] 🙈. The PCR, SCR, and MBS must be configured using one of the specified traffic descriptors 💅.
Send a specific number of IP packets containing one of the specified bit patterns at a specific rate through the SUT over the test VCCs 🚀. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate 🌸. The IP PDUs MUST be encapsulated in AAL5 ✨.
Count the IP packets the SUT transmits on all VCCs to check connectivity and load 🔍. If the count on the test device matches the SUT, keep going. If not, lower the test device rate until the counts line up 📉.
Record the number of CRC errored cells received on each VCC at the test device, for every VCC 🧾.

Reporting Format:

The CRC-ER/Bursty UBR Load/Maximum VCCs results SHOULD be reported as text and a graph 📊.

The graph SHOULD display the CRC Error ratio values. There will be (Max number of VCCs/10) graphs, with 10 VCCs on each one 🖼️. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is 🕰️. 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, with each VCC having its own labeled curve 🌈. The integration time per point MUST be indicated ⏱️.

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

Objective: this one checks the lost-cell ratio on three VCCs against the total cells sent, with a mix of bearer classes 🌈. The terms come from RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🦋.
Configure the SUT and test device with three VCCs 💖. 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, like [0,5] or [0,16] 🙈. The PCR, SCR, and MBS must be configured using one of the specified traffic descriptors 💅.
Send a specific number of IP packets containing one of the specified bit patterns through the SUT over the test VCCs 🚀. Each generated VCC stream MUST match its corresponding VCC bearer class. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate 🌸. The IP PDUs MUST be encapsulated in AAL5 ✨.
Count the IP packets the SUT transmits to check connectivity and load 🔍. If the count on the test device matches the SUT, keep going. If not, lower the test device rate until the counts line up 📉.
Record the number of CRC errored cells received on each VCC at the test device 🧾.

Reporting Format:

The CRC-ER/Bursty Mixed Load/Three VCC results SHOULD be reported as text and a graph 📊.

3.2.5.11. CRC-ER/Bursty Mixed Load/Twelve VCCs 🌸

Objective: same vibe as the three-VCC version, but scaled up to twelve VCCs with a mix of bearer classes 💅. It measures the lost-cell ratio against the total cells sent. The terms come from RFC 2761 "Terminology for ATM Benchmarking" 📚.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🦋.
Configure the SUT and test device with twelve VCCs 💖. Each VCC MUST be defined as one of the bearer classes, for a total of four CBR, four UBR and four VBR VCCs 🎀. Each VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM signaling channels, like [0,5] or [0,16] 🙈.
Send a specific number of IP packets containing one of the specified bit patterns through the SUT over the test VCCs 🚀. Each generated VCC stream MUST match its corresponding VCC bearer class. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate 🌸. The IP PDUs MUST be encapsulated in AAL5 ✨.
Count the IP packets the SUT transmits on all VCCs to check connectivity and load 🔍. If the count on the test device matches the SUT, keep going. If not, lower the test device rate until the counts line up 📉.
Record the number of CRC errored cells received on each VCC at the test device, for every VCC 🧾.

Reporting Format:

The CRC-ER/Bursty Mixed Load/Twelve VCCs results SHOULD be reported as text and a graph 📊.

The graph SHOULD display the CRC Error ratio values. The x-coordinate SHOULD be the test run time in seconds, 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, with each VCC having its own labeled curve 🌈. The integration time per point MUST be indicated ⏱️.

3.2.5.12. CRC-ER/Bursty Mixed Load/Maximum VCCs ✨

Objective: Figure out the SUT's ratio of lost cells when it's running the maximum number of VCCs it supports, compared with the total cells sent, using the definition in RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device in the bi-directional configuration 🎀
Configure the SUT and test device with the maximum number of VCCs the SUT supports 🌈 For example, if the SUT supports 1024 VCCs, 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 VCCs. The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g., [0,5], [0,16]) 🙈
Send a specific number of IP packets containing one of the specified bit patterns through the SUT over the defined test VCCs 🦋 Each generated VCC stream MUST match its corresponding VCC Bearer class. Every VPI/VCI pair generates traffic at the same traffic rate. This test isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 ✨
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 💖
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 as text and a graph 📝

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

The graph results SHOULD show the CRC Error ratio values. There will be (Max number of VCCs/10) graphs, with 10 VCCs shown on each graph. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is. 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, with one curve shown and labeled for each VCC. The integration time per point MUST be indicated 📊

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

3.2.6. Cell Transfer Delay (CTD) 🦋

3.2.6.1. Test Setup 🌸

The cell transfer delay measurements assume that the transmitter and receiver timestamp information is synchronized. Synchronization SHOULD be achieved by supplying a common clock signal (a minimum of 100 Mhz, or 10 ns resolution) to both the transmitter and receiver. The maximum timestamp values MUST be recorded so synchronization holds up if the counter rolls over. The cell transfer delay measurements SHOULD use the O.191 cell (ITUT-O.191) encapsulated in a valid IP packet. If the O.191 cell isn't available, a test cell encapsulated in a valid IP packet MAY be used. The test cell MUST contain a transmit timestamp that can be matched 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), the counter rollover value, and the timestamp accuracy (in ns) ⏱️

3.2.6.2. CTD/Steady Load/One VCC 💖

Objective: Figure out the SUT's variation in cell transfer delay with one VCC, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🎀

Procedure:

Set up the SUT and test device in the bi-directional configuration 🌷
Configure the SUT and test device with one VCC. The VCC SHOULD contain one VPI/VCI. The VCC MUST be configured as 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]) 🙈
Send a specific number of IP packets containing timestamps at a specific constant rate through the SUT over the defined test VCC. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🦋
Count the IP packets the SUT transmits to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 💅
Record the packet 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 as text, a graph, and a histogram 📝

The text results SHOULD show the numerical values of the CTD. The values SHOULD include the time period of the test in s, the test VPI/VCI value, the total number of cells transmitted and received on the given VPI/VCI during the test (as positive integers), and the minimum, maximum, and mean CTD during the test in us 🍓

The graph results SHOULD show the cell transfer delay values. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is. 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 show 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, the traffic rate in packets per second, and the bearer class as generated by the test device. The VCC and VPI/VCI values MUST be indicated. The bearer class of the created VCC MUST also be indicated 👑

3.2.6.3. CTD/Steady Load/Twelve VCCs 🌸

Objective: Figure out the SUT's variation in cell transfer delay with twelve VCCs, as defined in RFC 2761 "Terminology for ATM Benchmarking" 💜

Procedure:

Set up the SUT and test device in the bi-directional configuration 🎀
Configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs. The VCCs MUST be configured as 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]) 🙈
Send a specific number of IP packets containing timestamps at a specific constant rate through the SUT over the defined test VCCs. Every VPI/VCI pair generates traffic at the same traffic rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🦋
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 💖
Record the packet 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 as text, a graph, and histograms 📝

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

The graph results SHOULD show the cell transfer delay values. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is. 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, with one curve shown and labeled for each VCC. The integration time per point MUST be indicated 📊

The histograms SHOULD show 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, the traffic rate in packets per second, and the bearer class as generated by the test device. The VCC and VPI/VCI values MUST be indicated. The bearer class of the created VCC MUST also be indicated 👑

3.2.6.4. CTD/Steady Load/Maximum VCCs ✨

Objective: Okay bestie, this is the big-boss version of the steady load test 💅 We're checking how much the SUT's cell transfer delay wobbles when it's running the maximum number of VCCs it supports, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device using the bi-directional configuration.
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]) 🙈
Send a specific number of IP packets containing timestamps at a specific constant rate through the SUT via the defined test VCCs. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 📦
Count the IP packets that the SUT transmits on all VCCs to check connectivity and load. If the count on the test device is the same as on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🔁
Record the packet 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. Three glow-ups in one report, periodt 🌈

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, with 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 📈

3.2.6.5. CTD/Bursty VBR Load/One VCC 🦋

Objective: Time to see how cell transfer delay behaves when there's just one VCC, but the traffic is bursty VBR 💜 This is still the RFC 2761 "Terminology for ATM Benchmarking" vibe.

Procedure:

Set up the SUT and test device using the bi-directional configuration.
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]) 🙈
Send a specific number of IP packets containing timestamps at a specific VBR through the SUT via the defined test VCC. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 📦
Count the IP packets that the SUT transmits to check connectivity and load. If the count on the test device is the same as on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🔁
Record the packet 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 📈

3.2.6.6. CTD/Bursty VBR Load/Twelve VCCs 🌸

Objective: Now we're doing twelve VCCs with bursty VBR traffic, so you can see how the delay holds up when a few connections share the load 👑 The terms still come from RFC 2761 "Terminology for ATM Benchmarking".

Procedure:

Set up the SUT and test device using the bi-directional configuration.
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]) 🙈
Send a specific number of IP packets containing timestamps at a specific VBR through the SUT via the defined test VCCs. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 📦
Count the IP packets that the SUT transmits on all VCCs to check connectivity and load. If the count on the test device is the same as on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🔁
Record the packet 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, graphs, and histograms.

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, with one curve indicated and labeled for each VCC. The integration time per point MUST be indicated 📊

3.2.6.7. CTD/Bursty VBR Load/Maximum VCCs 🌟

Objective: The final boss of the bursty VBR set 🔥 We're checking the SUT's cell transfer delay variation with the maximum number of VCCs it supports, as defined in RFC 2761 "Terminology for ATM Benchmarking". It's giving everything, bestie 💖

Procedure:

Set up the SUT and test device using the bi-directional configuration.
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]) 🙈
Send a specific number of IP packets containing timestamps at a specific VBR through the SUT via the defined test VCCs. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 📦
Count the IP packets that the SUT transmits on all VCCs to check connectivity and load. If the count on the test device is the same as on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🔁
Record the packet 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.

3.2.6.8. CTD/Bursty UBR Load/One VCC 🦋

okay so the objective here is to see how much the SUT's cell transfer delay wiggles around with one VCC, using the terminology from RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

bestie, first set up the SUT and test device in the bi-directional configuration 🎀
next, 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]) 🙈
send a specific number of IP packets with timestamps in them, at a specific UBR, through the SUT over the test VCC. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🧚
count the IP packets the SUT transmits to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🫶
record the packet 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 as text, a graph, and a histogram. It's giving organized data, periodt 💜

The text results SHOULD show the numerical values of the CTD. The values 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 minimum, maximum, and mean CTD during the test in us ✨

The histogram results SHOULD show 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 🌈

3.2.6.9. CTD/Bursty UBR Load/Twelve VCCs 🌸

this one is giving twelve VCCs energy, and the objective is to see the SUT's cell transfer delay variation with all of them running, again per RFC 2761 "Terminology for ATM Benchmarking" 👑

Procedure:

set up the SUT and test device in the bi-directional configuration 💖
configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs. The VCCs MUST be configured as UBR connections. The VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g., [0,5], [0,16]) 🦋
send a specific number of IP packets with timestamps in them, at a specific UBR, through the SUT over the test VCCs. Every VPI/VCI pair generates traffic at the same rate. Since this isn't a throughput test, the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🧚‍♀️
count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, continue. If not, lower the test device traffic rate until the counts match 🫶
record the packet 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 as text, graphs, and histograms 🎀

The text results SHOULD show the numerical values of the CTD. The values 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 show the cell transfer delay values. The x-coordinate SHOULD be the test run time in seconds, 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 curve indicated and labeled for each VCC. The integration time per point MUST be indicated 📈

The histograms SHOULD show 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 🌈

3.2.6.10. CTD/Bursty UBR Load/Maximum VCCs 👑

main character energy alert 🚨 this test checks the SUT's cell transfer delay variation with the maximum number of VCCs it supports, as defined in RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

set up the SUT and test device in the bi-directional configuration 🌸
configure the SUT and test device with the maximum number of VCCs the SUT supports. For example, if the SUT supports 1024 VCCs, 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]) 🙈
send a specific number of IP packets with timestamps in them, at a specific UBR, through the SUT over the test VCCs. Every VPI/VCI pair generates traffic at the same rate. Since this isn't a throughput test, the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🧚
count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, continue. If not, lower the test device traffic rate until the counts match 🫶
record the packet 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 as text, graphs, and histograms 💖

The graph results SHOULD show 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 seconds, 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 📈

3.2.6.11. CTD/Mixed Load/Three VCC's 🧚

this one is a mixed load moment 🔥 the objective is to see the SUT's cell transfer delay variation with three VCC's, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

set up the SUT and test device in the bi-directional configuration 🎀
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]) 💅
send a specific number of IP packets with timestamps in them through the SUT over the test VCCs. Each generated VCC stream MUST match its corresponding VCC Bearer class. Every VPI/VCI pair generates traffic at the same rate. Since this isn't a throughput test, the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🧚‍♀️
count the IP packets the SUT transmits to check connectivity and load. If the count on the test device matches the count on the SUT, continue. If not, lower the test device traffic rate until the counts match 🫶
record the packet 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 as text, a graph, and a histogram 🌸

The graph results SHOULD show the cell transfer delay values. The x-coordinate SHOULD be the test run time in seconds, 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 📈

3.2.6.12. CTD/Mixed Load/Twelve VCCs ✨

Objective: Okay bestie, the goal here is to figure out how much the SUT's cell transfer delay wiggles around with twelve VCCs 🦋. The terms come from RFC 2761 "Terminology for ATM Benchmarking" 💅.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🎀.
Configure the SUT and test device with twelve VCC's 🌸. Each VCC MUST be defined as one of the Bearer classes, so you end up with 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, like [0,5] or [0,16] 🙈.
Send a specific number of IP packets with timestamps through the SUT over the test VCCs 🚀. Each generated VCC stream MUST match its VCC Bearer class. Every VPI/VCI pair sends traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate 🍓. The IP PDUs MUST be encapsulated in AAL5.
Count the IP packets the SUT transmits on all VCCs to check connectivity and load 🧚. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts match.
Record the packet timestamps at the transmitter and receiver ends of the test device for every VCC ⭐.

Reporting Format:

The results of the CTD/Mixed Load/Twelve VCCs test SHOULD be reported as text, graphs, and histograms 💖.

The text results SHOULD display the numerical values of the CTD. The values SHOULD include the time period of the test in s, the test VPI/VCI values, the total number of cells transmitted and received on each VCC during the test as positive integers, the maximum and minimum CTD on each VCC in us, and the 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 seconds, minutes or days, depending on how long the test is. 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, the traffic rate in packets per second, and the bearer class as generated by the test device 👑. The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the created VCC MUST also be indicated.

3.2.6.13. CTD/Mixed Load/Maximum VCCs ✨

Objective: Now we go big 👑. The goal is to see how much the SUT's cell transfer delay varies when it's running the maximum number of VCCs it supports, using the terms from RFC 2761 "Terminology for ATM Benchmarking" 💅.

Procedure:

Set up the SUT and test device using the bi-directional configuration 🎀.
Configure the SUT and test device with the maximum number of VCCs the SUT supports 🌸. For example, if the SUT supports 1024 maximum VCCs, 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 doesn't divide 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, like [0,5] or [0,16] 🙈.
Send a specific number of IP packets with timestamps through the SUT over the test VCCs 🚀. Each generated VCC stream MUST match its VCC Bearer class. Every VPI/VCI pair sends traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate 🍓. The IP PDUs MUST be encapsulated in AAL5.
Count the IP packets the SUT transmits on all VCCs to check connectivity and load 🧚. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts match.
Record the packet timestamps at the transmitter and receiver ends of the test device for every VCC ⭐.

Reporting Format:

The results of the CTD/Mixed Load/Maximum VCCs test SHOULD be reported as text, graphs, and histograms 💖.

The graph results SHOULD display the cell transfer delay values 📈. There will be (Max number of VCCs/10) graphs, with 10 VCCs shown on each graph. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is. 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.

3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5) 🦋

3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors 💀

Objective: We're checking whether the SUT drops IP packets because of AAL5 re-assembly errors, using the terms from RFC 2761 "Terminology for ATM Benchmarking" 🧐.

Procedure:

Set up the SUT and test device using the uni-directional configuration 🎀.
Send a specific number of cells at a specific rate through the SUT. This isn't a throughput test, so 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.
Count the cells the SUT transmits to check connectivity and load 🧚. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts match.
Inject one error in the first bit of the AAL5 payload. Check that the SUT does not drop any AAL5 PDU's 🙌.
Stop the AAL5 payload error.
Inject one error in the first bit of the AAL5 header for 4 consecutive IP PDUs in every 6 IP PDUs. Check that the SUT does drop the AAL5 PDU's 😭.
Stop the AAL5 payload error.

Reporting Format:

The results of the AAL5 PDU Loss due to AAL5 PDU errors test SHOULD be reported as 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, showing whether that condition was observed in 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: Here we figure out the SUT's AAL5 Reassembly Time, using the definitions from RFC 2761 "Terminology for ATM Benchmarking" 💅.

Procedure:

Set up the SUT and test device using the uni-directional configuration 🎀.
Send a specific number of IP packets at a specific rate through the SUT. This isn't a throughput test, so 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 🧩.
Count the IP packets the SUT transmits to check connectivity and load 🧚. If the count on the test device matches the SUT, keep going. If not, lower the test device traffic rate until the counts match.
Given an AAL5 reassembly timer of 'x' seconds, where 'x' is the actual value of the AAL5 reassembly timer on the SUT, send traffic at 1365 cells per 'x' seconds. The expected result is that no AAL5 PDU's will be dropped 🤞.
Send traffic at 1360 cells per 'x' seconds. The expected result is that all AAL5 PDU's will be dropped 💀.

Reporting Format:

The results of the IP packet loss due to AAL5 reassembly timeout test SHOULD be reported as 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, showing whether that condition was observed in each test. The elements of column 2 SHOULD be non-negative integers.

The table MUST also indicate the packet size in octets and the 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.3.1. Test Setup 🧪

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

3.3.3.2. AAL5-CRC-ER/Steady Load/One VCC ✨

Objective: okay bestie, this one is about finding the ratio of AAL5 CRC PDU errors on one VCC in a transmission, compared against the total AAL5 PDUs sent. The definition comes from RFC 2761 "Terminology for ATM Benchmarking" 🎀

Procedure:

Set up the SUT and test device using the bi-directional configuration. 💖
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]). 🦋
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. This test is not a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 🌸
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. Otherwise, lower the test device traffic rate until the counts are the same. ✨
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. 📈

3.3.3.3. AAL5-CRC-ER/Steady Load/Twelve VCCs 🧚

Objective: this one is the same vibe, but now we're looking at twelve VCC's instead of one. We're still finding the AAL5 CRC PDU error ratio in a transmission, compared to the total AAL5 PDU's sent, as defined in RFC 2761 "Terminology for ATM Benchmarking". 🌈

Procedure:

Set up the SUT and test device using the bi-directional configuration. 💖
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]). 🦋
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.

This test is not a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 🌸

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. Otherwise, lower the test device traffic rate until the counts are the same. ✨
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 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, one curve indicated and labeled for each VCC. The integration time per point MUST be indicated. 📈

3.3.3.4. AAL5-CRC-ER/Steady Load/Maximum VCCs 🌸

Objective: now we go big 🔥 This test finds the AAL5 CRC PDU error ratio with the maximum number of VCCs supported on the SUT in a transmission, compared to the total AAL5 PDU's sent, as defined in RFC 2761 "Terminology for ATM Benchmarking". Main character energy ✨

Procedure:

Set up the SUT and test device using the bi-directional configuration. 💖
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]). 🦋
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. 🌸
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. Otherwise, lower the test device traffic rate until the counts are the same. ✨
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 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. 📈

3.3.3.5. AAL5-CRC-ER/Bursty VBR Load/One VCC 💜

Objective: this one is the bursty version 🫶 It's still about the ratio of AAL5 CRC PDU errors on one VCC in a transmission, compared to the total AAL5 PDUs sent, as defined in RFC 2761 "Terminology for ATM Benchmarking". Iconic 🎀

Procedure:

Set up the SUT and test device using the bi-directional configuration. 💖
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. 🦋
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. 🌸
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. Otherwise, lower the test device traffic rate until the counts are the same. ✨
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. 💅

3.3.3.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs 🌸

Objective: okay bestie, this test figures out the SUT's ratio of AAL5 CRC PDU errors across twelve VCCs during a transmission, compared to the total AAL5 PDUs sent. The terms come from RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device in the bi-directional configuration 🦋
Configure the SUT and test device with twelve VCCs, using 1 VPI and 12 VCIs. The VCCs 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 ✨
Send a specific number of IP packets containing one of the specified bit patterns at a specific VBR rate through the SUT, using the defined test VCCs. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so 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 🔥
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🫶
Record the number of AAL5 CRC errors at the receiver end of the test device for all VCCs 💖

Reporting Format:

The AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs results SHOULD be reported as text and as a graph 🎀

For the text results, the numerical AAL5-CRC-ER values SHOULD be displayed. Those values SHOULD include the time period of the test in s, the test VPI/VCI value, the total number of AAL5 PDUs transmitted and received on the given VPI/VCI during the test as positive integers, and the AAL5-CRC-ER for the entire test 📊

For the graph, the AAL5 CRC error ratio values SHOULD be displayed. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is. 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, with one curve for each VCC, and each one indicated and labeled 🌈 The integration time per point MUST be indicated ⏱️

3.3.3.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs 🦋

Objective: this one checks the SUT's AAL5 CRC PDU error ratio using the maximum number of VCCs the SUT supports, compared to the total AAL5 PDUs sent. Same reference as before: RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device in the bi-directional configuration 💅
Configure the SUT and test device with the maximum number of VCCs the SUT supports. For example, if the SUT supports 1024 VCCs, define 256 VPIs with 4 VCIs per VPI. The VCCs 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 🌸
Send a specific number of IP packets containing one of the specified bit patterns at a specific VBR rate through the SUT, using the defined test VCCs. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 ✨
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🫶
Record the number of AAL5 CRC errors at the receiver end of the test device for all VCCs 🔥

Reporting Format:

The AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs results SHOULD be reported as text and as a graph 🎀

For the graph, the AAL5 CRC error ratio values SHOULD be displayed. 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 seconds, minutes or days, depending on how long the test is. 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, with one curve indicated and labeled for each VCC 🌈 The integration time per point MUST be indicated ⏱️

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

Objective: this test finds the SUT's AAL5 CRC PDU error ratio on three VCCs during a transmission, compared to the total AAL5 PDUs sent. Referenced as in RFC 2761 "Terminology for ATM Benchmarking" 🌈

Procedure:

Set up the SUT and test device in the bi-directional configuration 🦋
Configure the SUT and test device with three VCCs. 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]) 💅
Send a specific number of IP packets containing one of the specified bit patterns through the SUT, using the defined test VCCs. Each generated VCC stream MUST match its corresponding VCC bearer class. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🔥
Count the IP packets the SUT transmits to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🫶
Record the number of AAL5 CRC errors at the receiver end of the test device for all VCCs 💖

Reporting Format:

The AAL5-CRC-ER/Bursty Mixed Load/Three VCCs results SHOULD be reported as text and as a graph 🎀

For the graph, the AAL5 CRC error ratio values SHOULD be displayed. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on how long the test is. 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, with one curve for each VCC, and each one indicated and labeled 🌸 The integration time per point MUST be indicated ⏱️

3.3.3.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs 👑

Objective: this one is the big mixed-load test. It finds the SUT's AAL5 CRC PDU error ratio on twelve VCCs during a transmission, compared to the total AAL5 PDUs sent. Terms are from RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device in the bi-directional configuration ✨
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]) 🦋
Send a specific number of IP packets containing one of the specified bit patterns through the SUT, using the defined test VCCs. Each generated VCC stream MUST match its corresponding VCC bearer class. Every VPI/VCI pair generates traffic at the same rate. This isn't a throughput test, so the rate should not be greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5 🔥
Count the IP packets the SUT transmits on all VCCs to check connectivity and load. If the count on the test device matches the count on the SUT, keep going. If not, lower the test device traffic rate until the counts match 🫶
Record the number of AAL5 CRC errors at the receiver end of the test device for all VCCs 💖

Reporting Format:

The AAL5-CRC-ER/Bursty Mixed Load/Twelve VCCs results SHOULD be reported as text and as a graph 🎀

3.3.3.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs ✨

Objective: okay bestie, this test finds the SUT's ratio of AAL5 CRC PDU errors when it's running the maximum number of VCCs it supports, compared to the total AAL5 PDUs sent 🎀 The definition comes from RFC 2761 "Terminology for ATM Benchmarking" 💅

Procedure:

Set up the SUT and test device using the bi-directional configuration 🧚
Configure the SUT and test device with the maximum number of VCCs the SUT supports. For example, if the SUT supports 1024 VCCs, 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]). ⭐
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 generate traffic at the same traffic rate. This test is not a throughput test, so the rate should not be greater than 90% of line rate 🌸 The IP PDUs MUST be encapsulated in AAL5. 🫶
Count the IP packets that the SUT transmits on all VCCs to verify connectivity and load. If the count on the test device is the same as on the SUT, continue the test. Otherwise, lower the test device traffic rate until the counts match 🍓
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 as text and a graph 💜

The text results SHOULD display the numerical values of the AAL5-CRC-ER. The values SHOULD include the time period of the test in s, the test VPI/VCI value, the total number of AAL5 PDU's transmitted and received on the given VPI/VCI during the test as 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 shown on each graph. The x-coordinate SHOULD be the test run time in seconds, minutes or days, depending on the total length of the test, and 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, with one curve indicated and labeled for each VCC. The integration time per point MUST be indicated. 📊

3.4. ATM Service: Signaling 🦋

3.4.1. CAC Denial Time and Connection Establishment Time

Objective: this one measures the CAC rejection time and the Connection Establishment Time on the SUT, using the definitions in RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
Create a UNI signaling setup message, as described in Appendix C, specifying a PCR that will not allow CAC to reject the call. 💖
Send the UNI signaling setup message. Note the time the setup message was sent. Verify that the SVC has been set up with the correct parameters. Note the time the connect message was received. ⏱️
Create a UNI signaling setup message, as described in Appendix C, specifying a PCR that will allow CAC to reject the call. 💅
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. 😭
Compute the rejection time as the difference between the time the release complete message was received and the time the setup message was sent. ✨

Reporting Format:

The results of the CAC Denial Time and Connection Establishment Time tests SHOULD be reported as a table. The rows SHOULD be labeled call accepted and call rejected. The columns SHOULD be labeled time setup sent, time response received, and correct response. The elements of columns 1 and 2 SHOULD be in seconds. The elements of column 3 SHOULD 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 the traffic rate in packets per second as generated by the test device. 💜

3.4.2. Connection Teardown Time

Objective: this test finds the Connection Teardown Time on the SUT, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🌸

Procedure:

Set up the SUT and test device using the bi-directional configuration. 🎀
Create a UNI signaling setup message, as described in Appendix C, specifying a PCR that will not allow CAC to reject the call. 💖
Send the UNI signaling setup message. Note the time the setup message was sent. Verify that the SVC has been set up with the correct parameters. Note the time the connect message was received. ⏱️
Create a UNI signaling release message, as described in Appendix C, specifying a cause code of normal call clearing. 🫶
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. 🔥
Compute the release time as the difference between the time the release complete message was received and the time the release message was sent. 👑

Reporting Format:

The results of the Connection Teardown Time tests SHOULD be reported as 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 columns 1 and 2 SHOULD be in seconds. The elements of column 3 SHOULD 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 the traffic rate in packets per second as generated by the test device. 💅

3.4.3. Crankback Time

Objective: this one measures the Crankback Time on the SUT, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🧚

Procedure:

Set up the SUT and test device using the uni-directional passthrough configuration. 🎀
Create a PNNI signaling setup message, as described in Appendix C, specifying a DTL that is not blocked by the far end SUT. 💖
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. ⏱️
Create a PNNI signaling setup message, as described in Appendix C, specifying a DTL that is blocked by the far end SUT. 🙈
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 its own PNNI setup message (referred to as the near-end setup message) specifying the non-blocked DTL. 😭
Compute the crankback time as the difference between the time the near-end setup message was received and the time the release message was sent. ✨

Reporting Format:

The results of the Crankback Time tests SHOULD be reported as 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 columns 1 and 2 SHOULD be in seconds. The elements of column 3 SHOULD 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 the traffic rate in packets per second as generated by the test device. 💜

3.4.4. Route Update Response Time

Objective: this test finds the Route Update Response Time on the SUT, as defined in RFC 2761 "Terminology for ATM Benchmarking" 🦋

Procedure:

Set up the SUT and test device using the uni-directional passthrough configuration. 🎀
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. 🧚
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. ⏱️
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. 💅
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. 🔥
Compute the Route Update Response time as the difference between the time the far-end PTSE message was sent and the time the far-end PTSE message was received by the near-end. 👑

Reporting Format:

The results of the Route Update Response Time tests SHOULD be reported as 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 columns 1 and 2 SHOULD be in seconds. The elements of column 3 SHOULD 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 the traffic rate in packets per second as generated by the test device. 💖

3.5. ATM Service: ILMI 🌈

3.5.1. MIB Alignment Time 💖

Objective: 🎀 We're finding out the MIB Alignment Time on the SUT, using the definition from RFC 2761 "Terminology for ATM Benchmarking" ✨.

Procedure: 🦋

Set up the SUT and test device using the bi-directional configuration. 🔌
Send a Cold Start message to the SUT. Note the time the message was sent to the SUT. Then verify that the Cold Start message has been received by the SUT, and note the time it was received. 🚀
Send a Get Request message to the SUT. Note the time the message was sent to the SUT. Then verify that the Get Request message has been received by the SUT, and note the time it was received. 📬
After all MIB elements are exchanged, verify that the final Get Request message has been received by the SUT. Note the time it was sent and the time it was received by the SUT. ⏱️
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: 💅

Okay, bestie, the results of the MIB Alignment Time tests SHOULD be reported as 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 values in columns 1 and 2 SHOULD be in seconds ⏳. The values in column 3 SHOULD be either True or False, showing whether that particular condition was observed for each test ✅.

The table MUST also show the packet size in octets and the traffic rate in packets per second generated by the test device. No skipping this part, it's giving "non-negotiable" 🙈.

3.5.2. Address Registration Time 🦋

Objective: 🌈 We're finding out the Address Registration Time on the SUT, using the definition from RFC 2761 "Terminology for ATM Benchmarking" ✨.

Procedure: 🎀

Set up the SUT and test device using the bi-directional configuration. 🔌
Send a Set Request message to the SUT. Note the time the message was sent to the SUT. Then verify that the Set Request message has been received by the SUT, and note the time it was received. 🧚
Send a Get Request message to the SUT. Note the time the message was sent to the SUT. Then verify that the Get Request message has been received by the SUT, and note the time it was received. 📬
After all MIB elements are exchanged, verify that the final Get Request message has been received by the SUT. Note the time it was sent and the time it was received by the SUT. ⏱️
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 as a table 📊. The rows SHOULD be labeled Set Request Send, Set Request accepted, Final Get Request send, and Final Get Request received 🌷. The columns SHOULD be labeled time message sent, time response received, and correct response 💜. The values in columns 1 and 2 SHOULD be in seconds ⏳. The values in column 3 SHOULD be either True or False, showing whether that particular condition was observed for each test ✅.

The table MUST also show the packet size in octets and the traffic rate in packets per second generated by the test device. Literally a must-have, no exceptions 💅.

4. Security Considerations ✨

Okay, so this document is only about methodology. It doesn't describe a protocol or an implementation, so there are no security considerations associated with it 🔒🫶. Not every spec has drama, and this one is giving calm.

5. Notices 📜

The IETF takes no position on whether any intellectual property or other rights that might be claimed to apply to the technology described in this document are valid or in scope. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have made any effort to find out about such rights 🤷‍♀️. Info about the IETF's procedures for rights in standards-track and standards-related documents is in BCP-11 📚. Copies of claims of rights that were made available for publication, any assurances of licenses that will be made available, and the outcome of any attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can all be obtained from the IETF Secretariat 📬.

The IETF invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology required to practice this standard 🦋. Please send that info to the IETF Executive Director 💌.

6. References 📚

[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. 🌸
[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998. 🌷
[RFC2761] Dunn, J. and C. Martin, "Terminology for ATM Benchmarking", RFC 2761, February 2000. 💜
[AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version 4.0, af-ilmi-0065.000, September 1996. 🧚
[AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-test-0022.00, December 1994. 🎀
[AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1, af-tm-0121.00, April 1996. ⭐
[AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, September 1994. 🌈
[AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, July 1996. 👑

7. Authors' Addresses 💌

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

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


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

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

Appendix A: Ranges 🧭

ATM NSAP Network Prefix.

39 0000 0000 0000 0000 0000 0000-39 0000 0000 0000 0000 0000 00FF
39 0000 0000 0000 0000 0001 0000-39 0000 0000 0000 0000 0001 00FF
39 0000 0000 0000 0001 0000 0000
39 0000 0000 0000 0002 0020 0000
39 0000 0000 0300 0002 0030 0000
39 0000 0000 4000 0002 0060 0000
39 0000 0006 0060 0002 0030 0000
39 0000 0006 0050 0002 0030 0000
39 0000 0009 0300 0002 0030 0000
39 0000 00A0 0300 0002 0030 0000
39 0000 0B00 0300 0002 0030 0000
39 0000 C000 0300 0002 0030 0000

ATM NSAP End System Identifier.

1111 1111 1111 00-1111 1111 11FF 00
2222 2222 2000 00-2222 2222 2222 00
9999 999A 0000 00-9999 999C 0000 00

Appendix B: Rates 🍓

PNNI Routing Update Size.

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

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

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

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

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

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

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

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

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

PNNI Routing Update Repetition Interval.

Repetition Interval begins after initial PNNI routing table stabilizes. ⏰

1) 1 update every 1 hour, for 24 hours

2) 1 update every 30 minutes, for 24 hours

3) 1 update every 5 minutes, for 1 hour

4) 1 update every 1 minute, for 15 minutes

5) 1 update every 30 seconds, for 5 minutes

6) 1 update every 30 seconds, for 1 minute

7) 1 update every 1 second, for 30 seconds

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

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

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

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

Notes: 🧠

PDU size in cells is computed based on ceiling( ( PDU size in octets + 16) / 48). This assumes an 8 octet LLC/SNAP header and an 8 octet AAL/5 trailer. 💫
Due to the number of possible configurations, IMA pps rates are not listed, but may be derived from the following formula: floor (IDCR/cells per packet), where cells per packet is computed as in note 1. 🧮
The following cell rates were used:

DS-1 = 3622 cps (using ATM TC)
E1 = 4681 cps
25.6 Mb/s = 60377 cps
E3 = 80000 cps (using ATM TC)
DS-3 = 104266 cps (using ATM TC)
OC-3c = 353207 cps
OC-12c = 1412828 cps

Appendix C: PDU's 🎀

TCP/IP over ATM Example 1. 🎀 this one's a whole vibe, bestie 💅

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

TCP/IP over ATM Example 2. ✨ same packet energy, different port drama 🦋

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

UDP/IP over ATM Example. 🌸 ICMP echo request, let's gooo 🧚

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

RIP Routing Update over ATM. 🍓 this one's a whole packet map, so get comfy 🫶

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

          -- IP HEADER
          14     45                    IP version - 4, header length (4
         byte units) - 5
          15     00                    service field
          16     00 EE                 total length
          18     00 00                 ID
          20     40 00                 flags (3 bits) 4 (do not
         fragment),
                                       fragment offset-0
          22     0A                    TTL
          23     11                    protocol - 17 (UDP)
          24     C4 8D                 header checksum
          26     xx xx xx xx           source IP address
          30     xx xx xx              destination IP address
          33     FF                    host part = FF for broadcast

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

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

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

          -- net 2

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

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

          -- net 4
          106    00 02               family = IP
          108    00 00               0
          110    xx xx xx            net 4 IP address
          113    00                  net not node
          114    00 00 00 00         0
          118    00 00 00 00         0
          122    00 00 00 07         metric 7

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

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

UNI 3.1 Signaling Setup Message Example. PCR will not allow CAC to reject the call. 💜 signaling era, bestie, it's giving ATM drama 🌈

    Protocol Discriminator    : Q.93B UNI call control
    Call Reference Length     : 3
    Call Reference Flag       : orig
    Call Reference Value      : 0
    Message Type              : SETUP
    Ext                       : last octet
    Action Indicator          : clear call
    Message Length            : 50
    Information Element ID    : ATM Traffic Descriptor
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 9
    Cell Rate Subfield ID     : forward peak CR(CLP=0+1)
    Forward Peak Cell Rate    : 1
    Cell Rate Subfield ID     : backward peak CR(CLP=0+1)
    Backward Peak Cell Rate   : 1
    Cell Rate Subfield ID     : best effort indicator
    Information Element ID    : Broadband Bearer Capability
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 2
    Ext                       : last octet
    Bearer Class              : BCOB-X
    Ext                       : last octet
    Clipping Susceptibility   : not susceptible to clipping
    User Plane Connection CFG : point-to-point
    Information Element ID    : Called Party Number
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 21
    Ext                       : last octet
    Addressing/Numbering Plan : ISO NSAP addressing
    ISO NSAP Address Octets   : 3900000000000000000000000011111111111100
    Information Element ID    : Quality of Service Parameter
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 2
    QoS Class Forward         : QoS class 0 - unspecified
    QoS Class Backward        : QoS class 0 - unspecified

UNI 3.1 Signaling Setup Message Reject Example. PCR will allow CAC to reject the call. 🥹 the plot twist, and the last one for this part 👑

    Protocol Discriminator    : Q.93B UNI call control
    Call Reference Length     : 3
    Call Reference Flag       : orig
    Call Reference Value      : 0
    Message Type              : SETUP
    Ext                       : last octet
    Action Indicator          : clear call
    Message Length            : 50
    Information Element ID    : ATM Traffic Descriptor
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 8
    Cell Rate Subfield ID     : forward peak CR(CLP=0+1)
    Forward Peak Cell Rate    : 300000
    Cell Rate Subfield ID     : backward peak CR(CLP=0+1)
    Backward Peak Cell Rate   : 300000
    Information Element ID    : Broadband Bearer Capability
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Flag                      : not significant
    Action Indicator          : clear call
    IE Length                 : 3
    Ext                       : another octet
    Bearer Class              : BCOB-X
    Ext                       : last octet
    Traffic Type              : constant bit rate
    Timing Requirements       : end-to-end timing required
    Ext                       : last octet
    Clipping Susceptibility   : not susceptible to clipping
    User Plane Connection CFG : point-to-point
    Information Element ID    : Called Party Number
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 21
    Ext                       : last octet
    Addressing/Numbering Plan : ISO NSAP addressing
    ISO NSAP Address Octets   : 3900000000000000000000000011111111111100
    Information Element ID    : Quality of Service Parameter
    Ext                       : last octet
    Coding Standard           : ITU-T standard
    Action Indicator          : clear call
    IE Length                 : 2
    QoS Class Forward         : QoS class 0 - unspecified
    QoS Class Backward        : QoS class 0 - unspecified

Okay so this is the big UNI SETUP message, and it's giving full traffic-descriptor glow-up 🎀✨ It asks for peak cell rates of 300000 both ways, constant bit rate with end-to-end timing, and a called party address in ISO NSAP format. The QoS class is set to unspecified on both sides, which is very chill 🧚

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

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

And this is the RELEASE, which is the polite goodbye 👋 It just says "normal call clearing" and nobody's crying about it 🥹

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

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

Now the PNNI SETUP, where the DTL (Designated Transit List) is good to go because the far end isn't blocking it 🦋 Everything is in its happy place, and the called party is an ATM endsystem address, so it's giving very neat little routing vibes 💜

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

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

This one's the plot twist 😭 Same kind of SETUP, but this time the DTL is blocked by the far end SUT, so this is the reject story. Honestly the drama is real, but it's still a super clear example of what a rejected setup looks like 💀

PNNI Far End Request Message. 🧚

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

Next up is the far end request, which is a PTSE REQUEST packet asking for one PTSE with identifier 0 🎀 It's basically a polite "hey, can you send me that one?" with a very specific originating node ID 🫶

PNNI PTSE, specifying a routing topology. 🌈

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

This is the DATABASE SUMMARY, the routing topology gossip session 🗣️✨ The I, M and MS bits are all set to 1, so both nodes are in the database sync groove together, and it summarises a single nodal PTSE with everything at zero. Very minimal, very iconic 👑

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

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

And last but absolutely not least, the PTSE UPDATE 🦋 This PTSP packet is where the routing topology actually changes, so it's the main character moment of the whole example. It advertises a reachable ATM address prefix of length 13 with VPCs supported, and the PTSE remaining lifetime is 3600. Iconic, no cap 🔥

Full Copyright Statement ✨

Legal bits are kept word for word, bestie 💅 Nothing gets softened here.

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

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

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

📦 where this page comes from

ietf: rfc3116 2001-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms