draft-ietf-bmwg-atm-method-03.txt   rfc3116.txt 
Network Working Group J. H. Dunn Network Working Group J. Dunn
INTERNET-DRAFT C. E. Martin Request for Comments: 3116 C. Martin
Expires: May, 2001 ANC, Inc. Category: Informational ANC, Inc.
June 2001
November, 2000 Methodology for ATM Benchmarking
Methodology for ATM Benchmarking
<draft-ietf-bmwg-atm-method-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This memo provides information for the Internet community. It does
provisions of Section 10 of RFC2026. Internet-Drafts are working not specify an Internet standard of any kind. Distribution of this
documents of the Internet Engineering Task Force (IETF), its areas, and memo is unlimited.
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Test Device Requirements . . . . . . . . . . . . . . . . 2
2.2. Systems Under Test (SUTs). . . . . . . . . . . . . . . . 2
2.3. Test Result Evalutation. . . . . . . . . . . . . . . . . 3
2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2.5. Test Configurations for SONET. . . . . . . . . . . . . . 3
2.6. SUT Configuration. . . . . . . . . . . . . . . . . . . . 5
2.7. Frame Formats. . . . . . . . . . . . . . . . . . . . . . 5
2.8. Frame Sizes. . . . . . . . . . . . . . . . . . . . . . . 6
2.9. Verifying Received IP PDU's. . . . . . . . . . . . . . . 7
2.10. Modifiers . . . . . . . . . . . . . . . . . . . . . . . 7
2.10.1. Management IP PDU's . . . . . . . . . . . . . . . . . 7
2.10.2. Routing Update IP PDU's . . . . . . . . . . . . . . . 8
2.11. Filters . . . . . . . . . . . . . . . . . . . . . . . . 8
2.11.1. Filter Addresses. . . . . . . . . . . . . . . . . . . 9
2.12. Protocol Addresses. . . . . . . . . . . . . . . . . . . 10
2.13. Route Set Up. . . . . . . . . . . . . . . . . . . . . . 10
2.14. Bidirectional Traffic . . . . . . . . . . . . . . . . . 10
2.15. Single Stream Path. . . . . . . . . . . . . . . . . . . 11
2.16. Multi-port. . . . . . . . . . . . . . . . . . . . . . . 11
2.17. Multiple Protocols. . . . . . . . . . . . . . . . . . . 12
2.18. Multiple IP PDU Sizes . . . . . . . . . . . . . . . . . 12
2.19. Testing Beyond a Single SUT . . . . . . . . . . . . . . 12
2.20. Maximum IP PDU Rate . . . . . . . . . . . . . . . . . . 13
2.21. Busty Traffic . . . . . . . . . . . . . . . . . . . . . 14
2.22. Trial Description . . . . . . . . . . . . . . . . . . . 14
2.23. Trial Duration. . . . . . . . . . . . . . . . . . . . . 14
2.24. Address Resolution. . . . . . . . . . . . . . . . . . . 15
2.25. Synchronized Payload Bit Pattern. . . . . . . . . . . . 15
2.26. Burst Traffic Descriptors . . . . . . . . . . . . . . . 15
3. Performance Metrics. . . . . . . . . . . . . . . . . . . . 16
3.1. Physical Layer- SONET. . . . . . . . . . . . . . . . . . 16
3.1.1. Pointer Movements. . . . . . . . . . . . . . . . . . . 16
3.1.1.1. Pointer Movement Propagation . . . . . . . . . . . . 16
3.1.1.2. Cell Loss due to Pointer Movement. . . . . . . . . . 17
3.1.1.3. IP Packet Loss due to Pointer Movement . . . . . . . 19
3.1.2. Transport Overhead (TOH) Error Count . . . . . . . . . 20
3.1.2.1. TOH Error Propagation. . . . . . . . . . . . . . . . 20
3.1.2.2. Cell Loss due to TOH Error . . . . . . . . . . . . . 21
3.1.2.3. IP Packet Loss due to TOH Error. . . . . . . . . . . 22
3.1.3. Path Overhead (POH) Error Count. . . . . . . . . . . . 24
3.1.3.1. POH Error Propagation. . . . . . . . . . . . . . . . 24
3.1.3.2. Cell Loss due to POH Error . . . . . . . . . . . . . 25
3.1.3.3. IP Packet Loss due to POH Error. . . . . . . . . . . 26
3.2. ATM Layer. . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1. Two-Point Cell Delay Variation (CDV) . . . . . . . . . 26
3.2.2. Cell Error Ratio (CER) . . . . . . . . . . . . . . . . 44
3.2.3. Cell Loss Ratio (CLR). . . . . . . . . . . . . . . . . 60
3.2.4. Cell Misinsertion Rate (CMR) . . . . . . . . . . . . . 76
3.2.5. CRC Error Ratio (CRC-ER) . . . . . . . . . . . . . . . 92
3.2.6. Cell Transfer Delay (CTD). . . . . . . . . . . . . . . 108
3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5) . . . . . . . . 125
3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors. . . . . 125
3.3.2. AAL5 Re-assembly Time. . . . . . . . . . . . . . . . . 126
3.3.3. AAL5 CRC Error Ratio . . . . . . . . . . . . . . . . . 127
3.4. ATM Service: Signaling . . . . . . . . . . . . . . . . . 144
3.4.1. CAC Denial Time and Connection Establishment Time. . . 144
3.4.2. Connection Teardown Time . . . . . . . . . . . . . . . 145
3.4.3. Crankback Time . . . . . . . . . . . . . . . . . . . . 146
3.4.4. Route Update Response Time . . . . . . . . . . . . . . 147
3.5. ATM Service: ILMI. . . . . . . . . . . . . . . . . . . . 148
3.5.1. MIB Alignment Time . . . . . . . . . . . . . . . . . . 148
3.5.2. Address Registration Time. . . . . . . . . . . . . . . 149
4. Security Consideration . . . . . . . . . . . . . . . . . . 151
5. Notices. . . . . . . . . . . . . . . . . . . . . . . . . . 151
6. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . 151
7. References . . . . . . . . . . . . . . . . . . . . . . . . 152
8. Author's Address . . . . . . . . . . . . . . . . . . . . . 153
APPENDIX A . . . . . . . . . . . . . . . . . . . . . . . . . 154
APPENDIX B . . . . . . . . . . . . . . . . . . . . . . . . . 154
APPENDIX C . . . . . . . . . . . . . . . . . . . . . . . . . 156
Abstract Abstract
This document discusses and defines a number of tests that may be used This document discusses and defines a number of tests that may be
to describe the performance characteristics of ATM based switching used to describe the performance characteristics of ATM (Asynchronous
devices. In addition to defining the tests this document also describes Transfer Mode) based switching devices. In addition to defining the
specific formats for reporting the results of the tests. tests this document also describes specific formats for reporting the
results of the tests.
This memo is a product of the Benchmarking Methodology Working Group This memo is a product of the Benchmarking Methodology Working Group
(BMWG) of the Internet Engineering Task Force (IETF). (BMWG) of the Internet Engineering Task Force (IETF).
1. Introduction. Table of Contents
This document defines a specific set of tests that vendors can use to 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
measure and report the performance characteristics of ATM network 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
devices. The results of these tests will provide the user comparable 2.1. Test Device Requirements . . . . . . . . . . . . . . . . . . 5
data from different vendors with which to evaluate these devices. The 2.2. Systems Under Test (SUTs). . . . . . . . . . . . . . . . . . 5
methods defined in this memo are based on RFC 2544 "Benchmarking 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
This document defines a specific set of tests that vendors can use to
measure and report the performance characteristics of ATM network
devices. The results of these tests will provide the user comparable
data from different vendors with which to evaluate these devices.
The methods defined in this memo are based on RFC 2544 "Benchmarking
Methodology for Network Interconnect Devices". Methodology for Network Interconnect Devices".
The document "Terminology for ATM Benchmarking" (RFC 2761), defines many The document "Terminology for ATM Benchmarking" (RFC 2761), defines
of the terms that are used in this document. The terminology document many of the terms that are used in this document. The terminology
should be consulted before attempting to make use of this document. document should be consulted before attempting to make use of this
document.
The BMWG produces two major classes of documents: Benchmarking The BMWG produces two major classes of documents: Benchmarking
Terminology documents and Benchmarking Methodology documents. The Terminology documents and Benchmarking Methodology documents. The
Terminology documents present the benchmarks and other related terms. Terminology documents present the benchmarks and other related terms.
The Methodology documents define the procedures required to collect the The Methodology documents define the procedures required to collect
benchmarks cited in the corresponding Terminology documents. the benchmarks cited in the corresponding Terminology documents.
2. Background 2. Background
2.1. Test Device Requirements 2.1. Test Device Requirements
This document is based on the requirement that a test device is This document is based on the requirement that a test device is
available. The test device can either be off the shelf or can be easily available. The test device can either be off the shelf or can be
built with current technologies. The test device must have a easily built with current technologies. The test device must have a
transmitting and receiving port for the interface type under test. The transmitting and receiving port for the interface type under test.
test device must be configured to transmit test PDUs and to analyze The test device must be configured to transmit test PDUs and to
received PDUs. The test device should be able to transmit and analyze analyze received PDUs. The test device should be able to transmit
received data at the same time. and analyze received data at the same time.
2.2. Systems Under Test (SUTs) 2.2. Systems Under Test (SUTs)
There are a number of tests described in this document that do not apply There are a number of tests described in this document that do not
to each SUT. Vendors should perform all of the tests that can be apply to each SUT. Vendors should perform all of the tests that can
supported by a specific product type. It will take some time to perform be supported by a specific product type. It will take some time to
all of the recommended tests under all of the recommended conditions. perform all of the recommended tests under all of the recommended
conditions.
2.3. Test Result Evaluation 2.3. Test Result Evaluation
Performing all of the tests in this document will result in a great deal Performing all of the tests in this document will result in a great
of data. The applicability of this data to the evaluation of a deal of data. The applicability of this data to the evaluation of a
particular SUT will depend on its expected use and the configuration of particular SUT will depend on its expected use and the configuration
the network in which it will be used. For example, the time required by of the network in which it will be used. For example, the time
a switch to provide ILMI services will not be a pertinent measurement in required by a switch to provide ILMI services will not be a pertinent
a network that does not use the ILMI protocol, such as an ATM WAN. measurement in a network that does not use the ILMI protocol, such as
Evaluating data relevant to a particular network installation may an ATM WAN. Evaluating data relevant to a particular network
require considerable experience, which may not be readily available. installation may require considerable experience, which may not be
Finally, test selection and evaluation of test results must be done with readily available. Finally, test selection and evaluation of test
an understanding of generally accepted testing practices regarding results must be done with an understanding of generally accepted
repeatability, variance and the statistical significance of a small testing practices regarding repeatability, variance and the
numbers of trials. statistical significance of a small numbers of trials.
2.4. Requirements 2.4. Requirements
In this document, the words that are used to define the significance of In this document, the words that are used to define the significance
each particular requirement are capitalized. These words are: of each particular requirement are capitalized. These words are:
* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that
item is an absolute requirement of the specification. the item is an absolute requirement of the specification.
* "SHOULD" This word or the adjective "RECOMMENDED" means that there may * "SHOULD" This word or the adjective "RECOMMENDED" means that there
exist valid reasons in particular circumstances to ignore this item, but may exist valid reasons in particular circumstances to ignore this
the full implications should be understood and the case carefully item, but the full implications should be understood and the case
weighed before choosing a different course. carefully weighed before choosing a different course.
* "MAY" This word or the adjective "OPTIONAL" means that this item is * "MAY" This word or the adjective "OPTIONAL" means that this item
truly optional. One vendor may choose to include the item because a is truly optional. One vendor may choose to include the item
particular marketplace requires it or because it enhances the product, because a particular marketplace requires it or because it
for example; another vendor may omit the same item. 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 An implementation is not compliant if it fails to satisfy one or more
the MUST requirements for the protocols it implements. An of the MUST requirements for the protocols it implements. An
implementation that satisfies all the MUST and all the SHOULD implementation that satisfies all the MUST and all the SHOULD
requirements for its protocols is said to be "unconditionally requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST requirements but not all the compliant"; one that satisfies all the MUST requirements but not all
SHOULD requirements for its protocols is said to be "conditionally the SHOULD requirements for its protocols is said to be
compliant". "conditionally compliant".
2.5. Test Configurations for SONET 2.5. Test Configurations for SONET
The test device can be connected to the SUT in a variety of The test device can be connected to the SUT in a variety of
configurations depending on the test point. The following configurations depending on the test point. The following
configurations will be used for the tests described in this document. configurations will be used for the tests described in this document.
1) Uni-directional connection: The test devices transmit port (labeled 1) Uni-directional connection: The test devices transmit port
Tx) is connected to the SUT receive port (labeled Rx). The SUTs (labeled Tx) is connected to the SUT receive port (labeled Rx).
transmit port is connected to the test device receive port (see Figure The SUTs transmit port is connected to the test device receive
1). In this configuration, the test device can verify that all port (see Figure 1). In this configuration, the test device can
transmitted packets are acknowledged correctly. Note that this verify that all transmitted packets are acknowledged correctly.
configuration does not verify internal system functions, but verifies Note that this configuration does not verify internal system
one port on the SUT. functions, but verifies one port on the SUT.
+-------------+ +-------------+ +-------------+ +-------------+
| Tx|-------------->|Rx | | Tx|-------------->|Rx |
| Test Rx|<--------------|Tx SUT | | Test Rx|<--------------|Tx SUT |
| Device | | | | Device | | |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 1 Figure 1
2) Bi-directional connection: The test devices first transmit port is 2) Bi-directional connection: The test devices first transmit port is
connected to the SUTs first receive port. The SUTs first transmit port connected to the SUTs first receive port. The SUTs first transmit
is connected to the test devices first receive port. The test devices port is connected to the test devices first receive port. The
second transmit port is connected to the SUTs second receive port. The test devices second transmit port is connected to the SUTs second
SUTs second transmit port is connected to the test devices second receive port. The SUTs second transmit port is connected to the
receive port (see Figure 2). In this configuration, the test device can test devices second receive port (see Figure 2). In this
determine if all of the transmitted packets were received and forwarded configuration, the test device can determine if all of the
correctly. Note that this configuration does verify internal system transmitted packets were received and forwarded correctly. Note
functions, since it verifies two ports on the SUT. that this configuration does verify internal system functions,
since it verifies two ports on the SUT.
+-------------+ +-------------+ +-------------+ +-------------+
| Test Tx|-------------->|Rx | | Test Tx|-------------->|Rx |
| Device Rx|<--------------|Tx SUT | | Device Rx|<--------------|Tx SUT |
| Tx Rx | | Tx Rx | | Tx Rx | | Tx Rx |
+-------------+ +-------------+ +-------------+ +-------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +------------------------+ | | +------------------------+ |
| | | |
|---------------------------------| |---------------------------------|
Figure 2 Figure 2
2) Uni-directional passthrough connection: The test devices first 3) Uni-directional passthrough connection: The test devices first
transmit port is connected to the SUT1 receive port. The SUT1 transmit transmit port is connected to the SUT1 receive port. The SUT1
port is connected to the test devices first receive port. The test transmit port is connected to the test devices first receive port.
devices second transmit port is connected to the SUT2 receive port. The The test devices second transmit port is connected to the SUT2
SUT2 transmit port is connected to the test devices second receive port receive port. The SUT2 transmit port is connected to the test
(see Figure 3). In this configuration, the test device can determine if devices second receive port (see Figure 3). In this
all of the packets transmitted by SUT1 were correctly acknowledged by configuration, the test device can determine if all of the packets
SUT2. Note that this configuration does not verify internal system transmitted by SUT1 were correctly acknowledged by SUT2. Note
functions, but verifies one port on each SUT. that this configuration does not verify internal system functions,
but verifies one port on each SUT.
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Tx|---------->|Rx Tx|---------->|Rx | | Tx|---------->|Rx Tx|---------->|Rx |
| SUT1 Rx|<----------|Tx Test Rx|<----------|Tx SUT2 | | SUT1 Rx|<----------|Tx Test Rx|<----------|Tx SUT2 |
| | | Device | | | | | | Device | | |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
Figure 3 Figure 3
2.6. SUT Configuration 2.6. SUT Configuration
The SUT MUST be configured as described in the SUT users guide. The SUT MUST be configured as described in the SUT users guide.
Specifically, it is expected that all of the supported protocols will be Specifically, it is expected that all of the supported protocols will
configured and enabled. It is expected that all of the tests will be be configured and enabled. It is expected that all of the tests will
run without changing the configuration or setup of the SUT in any way be run without changing the configuration or setup of the SUT in any
other than that required to do the specific test. For example, it is way other than that required to do the specific test. For example,
not acceptable to disable all but one transport protocol when testing it is not acceptable to disable all but one transport protocol when
the throughput of that protocol. If PNNI or BISUP is used to initiate testing the throughput of that protocol. If PNNI or BISUP is used to
switched virtual connections (SVCs), the SUT configuration SHOULD initiate switched virtual connections (SVCs), the SUT configuration
include the normally recommended routing update intervals and keep alive SHOULD include the normally recommended routing update intervals and
frequency. The specific version of the software and the exact SUT keep alive frequency. The specific version of the software and the
configuration, including what functions are disabled and used during the exact SUT configuration, including what functions are disabled and
tests MUST be included as part of the report of the results. used during the tests MUST be included as part of the report of the
results.
2.7. Frame formats 2.7. Frame formats
The formats of the test IP PDUs to use for TCP/IP and UPC/IP over ATM The formats of the test IP PDUs to use for TCP/IP and UPC/IP over ATM
are shown in Appendix C: Test Frame Formats. Note that these IP PDUs are shown in Appendix C: Test Frame Formats. Note that these IP PDUs
are in accordance with RFC 2225. These exact IP PDU formats SHOULD be are in accordance with RFC 2225. These exact IP PDU formats SHOULD
used in the tests described in this document for this protocol/media be used in the tests described in this document for this
combination. These IP PDUs will be used as a template for testing other protocol/media combination. These IP PDUs will be used as a template
protocol/media combinations. The specific formats that are used to for testing other protocol/media combinations. The specific formats
define the test IP PDUs for a particular test series MUST be included in that are used to define the test IP PDUs for a particular test series
the report of the results. MUST be included in the report of the results.
2.8. Frame sizes 2.8. Frame sizes
All of the described tests SHOULD be performed using a number of IP PDU All of the described tests SHOULD be performed using a number of IP
sizes. Specifically, the sizes SHOULD include the maximum and minimum PDU sizes. Specifically, the sizes SHOULD include the maximum and
legitimate sizes for the protocol under test on the media under test and minimum legitimate sizes for the protocol under test on the media
enough sizes in between to be able to get a full characterization of the under test and enough sizes in between to be able to get a full
SUT performance. Except where noted, at least five IP PDU sizes SHOULD characterization of the SUT performance. Except where noted, at
be tested for each test condition. least five IP PDU sizes SHOULD be tested for each test condition.
Theoretically the minimum size UDP Echo request IP PDU would consist of Theoretically the minimum size UDP Echo request IP PDU would consist
an IP header (minimum length 20 octets), a UDP header (8 octets), AAL5 of an IP header (minimum length 20 octets), a UDP header (8 octets),
trailer (8 octets) and an LLC/SNAP code point header(8 octets); AAL5 trailer (8 octets) and an LLC/SNAP code point header (8 octets);
therefore, the minimum size PDU will fit into one ATM cell. The therefore, the minimum size PDU will fit into one ATM cell. The
theoretical maximum IP PDU size is determined by the size of the length theoretical maximum IP PDU size is determined by the size of the
field in the IP header. In almost all cases the actual maximum and length field in the IP header. In almost all cases the actual
minimum sizes are determined by the limitations of the media. In the maximum and minimum sizes are determined by the limitations of the
case of ATM, the maximum IP PDU size SHOULD be the ATM MTU size, which media. In the case of ATM, the maximum IP PDU size SHOULD be the ATM
is 9180 octets. MTU size, which is 9180 octets.
In theory it would be ideal to distribute the IP PDU sizes in a way that In theory it would be ideal to distribute the IP PDU sizes in a way
would evenly distribute the theoretical IP PDU rates. These that would evenly distribute the theoretical IP PDU rates. These
recommendations incorporate this theory but specify IP PDU sizes, which recommendations incorporate this theory but specify IP PDU sizes,
are easy to understand and remember. In addition, many of the same IP which are easy to understand and remember. In addition, many of the
PDU sizes are specified on each of the media types to allow for easy same IP PDU sizes are specified on each of the media types to allow
performance comparisons. for easy performance comparisons.
Note: The inclusion of an unrealistically small IP PDU size on some of Note: The inclusion of an unrealistically small IP PDU size on some
the media types (i.e. with little or no space for data) is to help of the media types (i.e., with little or no space for data) is to
characterize the per-IP PDU processing overhead of the SUT. help characterize the per-IP PDU processing overhead of the SUT.
The IP PDU sizes that will be used are: The IP PDU sizes that will be used are:
44, 64, 128, 256, 1024, 1518, 2048, 4472, 9180 44, 64, 128, 256, 1024, 1518, 2048, 4472, 9180
The minimum size IP PDU for UDP on ATM is 44 octets, the minimum size of The minimum size IP PDU for UDP on ATM is 44 octets, the minimum size
44 is recommended to allow direct comparison to token ring performance. of 44 is recommended to allow direct comparison to token ring
The IP PDU size of 4472 is recommended instead of the theoretical FDDI performance. The IP PDU size of 4472 is recommended instead of the
maximum size of 4500 octets in order to permit the same type of theoretical FDDI maximum size of 4500 octets in order to permit the
comparison. An IP (i.e. not UDP) IP PDU may be used in addition if a same type of comparison. An IP (i.e., not UDP) IP PDU may be used in
higher data rate is desired, in which case the minimum IP PDU size is 28 addition if a higher data rate is desired, in which case the minimum
octets. IP PDU size is 28 octets.
2.9. Verifying received IP PDUs 2.9. Verifying received IP PDUs
The test equipment SHOULD discard any IP PDUs received during a test run The test equipment SHOULD discard any IP PDUs received during a test
that are not actual forwarded test IP PDUs. For example, keep-alive and run that are not actual forwarded test IP PDUs. For example, keep-
routing update IP PDUs SHOULD NOT be included in the count of received alive and routing update IP PDUs SHOULD NOT be included in the count
IP PDUs. In any case, the test equipment SHOULD verify the length of of received IP PDUs. In any case, the test equipment SHOULD verify
the received IP PDUs and check that they match the expected length. 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 Preferably, the test equipment SHOULD include sequence numbers in the
transmitted IP PDUs and check for these numbers on the received IP PDUs. transmitted IP PDUs and check for these numbers on the received IP
If this is done, the reported results SHOULD include. in addition to the PDUs. If this is done, the reported results SHOULD include, in
number of IP PDUs dropped, the number of IP PDUs that were received out addition to the number of IP PDUs dropped, the number of IP PDUs that
of order, the number of duplicate IP PDUs received and the number of were received out of order, the number of duplicate IP PDUs received
gaps in the received IP PDU numbering sequence. This functionality is and the number of gaps in the received IP PDU numbering sequence.
required for some of the described tests. This functionality is required for some of the described tests.
2.10. Modifiers 2.10. Modifiers
It is useful to characterize the SUTs performance under a number of It is useful to characterize the SUTs performance under a number of
conditions. Some of these conditions are noted below. The reported conditions. Some of these conditions are noted below. The reported
results SHOULD include as many of these conditions as the test equipment results SHOULD include as many of these conditions as the test
is able to generate. The suite of tests SHOULD be run first without any equipment is able to generate. The suite of tests SHOULD be run
modifying conditions, then repeated under each of the modifying first without any modifying conditions, then repeated under each of
conditions separately. To preserve the ability to compare the results the modifying conditions separately. To preserve the ability to
of these tests, any IP PDUs that are required to generate the modifying compare the results of these tests, any IP PDUs that are required to
conditions (excluding management queries) will be included in the same generate the modifying conditions (excluding management queries) will
data stream as that of the normal test IP PDUs and in place of one of be included in the same data stream as that of the normal test IP
the test IP PDUs. They MUST not be supplied to the SUT on a separate PDUs and in place of one of the test IP PDUs. They MUST not be
network port. supplied to the SUT on a separate network port.
2.10.1. Management IP PDUs 2.10.1. Management IP PDUs
Most ATM data networks now make use of ILMI, signaling and OAM. In many Most ATM data networks now make use of ILMI, signaling and OAM. In
environments, there can be a number of management stations sending many environments, there can be a number of management stations
queries to the same SUT at the same time. sending queries to the same SUT at the same time.
Management queries MUST be made in accordance with the applicable Management queries MUST be made in accordance with the applicable
specification, e.g., ILMI sysUpTime getNext requests will be made in specification, e.g., ILMI sysUpTime getNext requests will be made in
accordance with ILMI 4.0. The response to the query MUST be verified by accordance with ILMI 4.0. The response to the query MUST be verified
the test equipment. Note that, for each management protocol in use, this by the test equipment. Note that, for each management protocol in
requires that the test equipment implement the associated protocol state use, this requires that the test equipment implement the associated
machine. One example of the specific query IP PDU (ICMP) that should be protocol state machine. One example of the specific query IP PDU
used is shown in Appendix C. (ICMP) that should be used is shown in Appendix C.
2.10.2. Routing update IP PDUs 2.10.2. Routing update IP PDUs
The processing of PNNI updates could have a significant impact on the The processing of PNNI updates could have a significant impact on the
ability of a switch to forward cells and complete calls. If PNNI is ability of a switch to forward cells and complete calls. If PNNI is
configured on the SUT, one routing update MUST be transmitted before the configured on the SUT, one routing update MUST be transmitted before
first test IP PDU is transmitted during the trial. The test SHOULD the first test IP PDU is transmitted during the trial. The test
verify that the SUT has properly processed the routing update. SHOULD verify that the SUT has properly processed the routing update.
PNNI routing update IP PDUs SHOULD be sent at the rate specified in 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 Appendix B. Appendix C defines one routing update PDU for the TCP/IP
over ATM example. The routing updates are designed to change the over ATM example. The routing updates are designed to change the
routing on a number of networks that are not involved in the forwarding routing on a number of networks that are not involved in the
of the test data. The first IP PDU sets the routing table state to "A", forwarding of the test data. The first IP PDU sets the routing table
the second one changes the state to "B". The IP PDUs MUST be alternated state to "A", the second one changes the state to "B". The IP PDUs
during the trial. The test SHOULD verify that the SUT has properly MUST be alternated during the trial. The test SHOULD verify that the
processed the routing update. SUT has properly processed the routing update.
2.11. Filters 2.11. Filters
Filters are added to switches to selectively inhibit the forwarding of Filters are added to switches to selectively inhibit the forwarding
cells that would normally be forwarded. This is usually done to of cells that would normally be forwarded. This is usually done to
implement security controls on the data that is accepted between one implement security controls on the data that is accepted between one
area and another. Different products have different capabilities to area and another. Different products have different capabilities to
implement filters. Filters are applicable only if the SUT supports the implement filters. Filters are applicable only if the SUT supports
filtering feature. the filtering feature.
The SUT SHOULD be first configured to add one filter condition and the The SUT SHOULD be first configured to add one filter condition and
tests performed. This filter SHOULD permit the forwarding of the test the tests performed. This filter SHOULD permit the forwarding of the
data stream. This filter SHOULD be of the form as described in the SUT test data stream. This filter SHOULD be of the form as described in
Users Guide. the SUT Users Guide.
The SUT SHOULD be then reconfigured to implement a total of 25 filters. The SUT SHOULD be then reconfigured to implement a total of 25
The first 24 of these filters SHOULD be based on 24 separate ATM NSAP filters. The first 24 of these filters SHOULD be based on 24
Network Prefix addresses. separate ATM NSAP Network Prefix addresses.
The 24 ATM NSAP Network Prefix addresses SHOULD not be any that are 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 represented in the test data stream. The last filter SHOULD permit
forwarding of the test data stream. By "first" and "last" we mean to the forwarding of the test data stream. By "first" and "last" we
ensure that in the second case, 25 conditions must be checked before the mean to ensure that in the second case, 25 conditions must be checked
data IP over ATM PDUs will match the conditions that permit the before the data IP over ATM PDUs will match the conditions that
forwarding of the IP PDU. Of course, if the SUT reorders the filters or permit the forwarding of the IP PDU. Of course, if the SUT reorders
does not use a linear scan of the filter rules the effect of the the filters or does not use a linear scan of the filter rules the
sequence in which the filters are input is properly lost. effect of the sequence in which the filters are input is properly
lost.
The exact filters configuration command lines used SHOULD be included The exact filters configuration command lines used SHOULD be included
with the report of the results. with the report of the results.
2.11.1. Filter Addresses 2.11.1. Filter Addresses
Two sets of filter addresses are required, one for the single filter Two sets of filter addresses are required, one for the single filter
case and one for the 25 filter case. case and one for the 25 filter case.
The single filter case should permit traffic from ATM address [Switch The single filter case should permit traffic from ATM address [Switch
Network Prefix] 00 00 00 00 00 01 00 to ATM address [Switch Network 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 Prefix] 00 00 00 00 00 02 00 and deny all other traffic. Note that
13 octet Switch Network Prefix MUST be configured before this test can the 13 octet Switch Network Prefix MUST be configured before this
be run. test can be run.
The 25 filter case should follow the following sequence. The 25 filter case should follow the following sequence.
deny [Switch Network Prefix] 00 00 00 00 00 01 00 deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 03 00 to [Switch Network Prefix] 00 00 00 00 00 03 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00 deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 04 00 to [Switch Network Prefix] 00 00 00 00 00 04 00
deny [Switch Network Prefix] 00 00 00 00 00 01 00 deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 05 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 deny [Switch Network Prefix] 00 00 00 00 00 01 00
to [Switch Network Prefix] 00 00 00 00 00 18 00 to [Switch Network Prefix] 00 00 00 00 00 0C 00
deny all else 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 All previous filter conditions should be cleared from the switch
this sequence is entered. The sequence is selected to test to see if before this sequence is entered. The sequence is selected to test to
the switch sorts the filter conditions or accepts them in the order that see if the switch sorts the filter conditions or accepts them in the
they were entered. Both of these procedures will result in a greater order that they were entered. Both of these procedures will result
impact on performance than will some form of hash coding. in a greater impact on performance than will some form of hash
coding.
2.12. Protocol addresses 2.12. Protocol addresses
It is easier to implement these tests using a single logical stream of It is easier to implement these tests using a single logical stream
data, with one source ATM address and one destination ATM address, and of data, with one source ATM address and one destination ATM address,
for some conditions like the filters described above, a practical and for some conditions like the filters described above, a practical
requirement. Networks in the real world are not limited to single requirement. Networks in the real world are not limited to single
streams of data. The test suite SHOULD be first run with a single ATM streams of data. The test suite SHOULD be first run with a single
source and destination address pair. The tests SHOULD then be repeated ATM source and destination address pair. The tests SHOULD then be
with using a random destination address. In the case of testing single repeated with using a random destination address. In the case of
switches, the addresses SHOULD be random and uniformly distributed over testing single switches, the addresses SHOULD be random and uniformly
a range of 256 seven octet user parts. In the case of testing multiple distributed over a range of 256 seven octet user parts. In the case
interconnected switches, the addresses SHOULD be random and uniformly of testing multiple interconnected switches, the addresses SHOULD be
distributed over the 256 network prefixes, each of which should support random and uniformly distributed over the 256 network prefixes, each
256 seven octet user parts. The specific address ranges to use for ATM of which should support 256 seven octet user parts. The specific
are shown in Appendix A. IP to ATM address mapping MUST be accomplished address ranges to use for ATM are shown in Appendix A. IP to ATM
as described in RFC 2225. address mapping MUST be accomplished as described in RFC 2225.
2.13. Route Set Up 2.13. Route Set Up
It is not reasonable that all of the routing information necessary to It is not reasonable that all of the routing information necessary to
forward the test stream, especially in the multiple address case, will forward the test stream, especially in the multiple address case,
be manually set up. If PNNI and/or ILMI are running, at the start of will be manually set up. If PNNI and/or ILMI are running, at the
each trial a routing update MUST be sent to the SUT. This routing update start of each trial a routing update MUST be sent to the SUT. This
MUST include all of the ATM addresses that will be required for the routing update MUST include all of the ATM addresses that will be
trial. This routing update will have to be repeated at the interval required for the trial. This routing update will have to be repeated
required by PNNI or ILMI. An example of the format and repetition at the interval required by PNNI or ILMI. An example of the format
interval of the update IP PDUs is given in Appendix B (interval and and repetition interval of the update IP PDUs is given in Appendix B
size) and Appendix C (format). (interval and size) and Appendix C (format).
2.14. Bidirectional traffic 2.14. Bidirectional traffic
Bidirectional performance tests SHOULD be run with the same data rate Bidirectional performance tests SHOULD be run with the same data rate
being offered from each direction. The sum of the data rates should not being offered from each direction. The sum of the data rates should
exceed the theoretical limit for the media. not exceed the theoretical limit for the media.
2.15. Single stream path 2.15. Single stream path
The full suite of tests SHOULD be run with the appropriate modifiers for The full suite of tests SHOULD be run with the appropriate modifiers
a single receive and transmit port on the SUT. If the internal design of for a single receive and transmit port on the SUT. If the internal
the SUT has multiple distinct pathways, for example, multiple interface design of the SUT has multiple distinct pathways, for example,
cards each with multiple network ports, then all possible permutations multiple interface cards each with multiple network ports, then all
of pathways SHOULD be tested separately. If multiple interconnected possible permutations of pathways SHOULD be tested separately. If
switches are tested, the test MUST specify routes, which allow only one multiple interconnected switches are tested, the test MUST specify
path between source and destination ATM addresses. routes, which allow only one path between source and destination ATM
addresses.
2.16. Multi-port 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 Many switch products provide several network ports on the same
identical manner. Specifically, half of the ports on each module SHOULD interface module. Each port on an interface module SHOULD be
be receive ports and half SHOULD be transmit ports. For example if a stimulated in an identical manner. Specifically, half of the ports
SUT has two interface module each of which has four ports, two ports on on each module SHOULD be receive ports and half SHOULD be transmit
each interface module be receive ports and two will be transmit ports. ports. For example if a SUT has two interface module each of which
Each receive port MUST be offered the same data rate. The addresses in has four ports, two ports on each interface module be receive ports
the input data streams SHOULD be set so that an IP PDU will be directed and two will be transmit ports. Each receive port MUST be offered
to each of the transmit ports in sequence. That is, all transmit ports the same data rate. The addresses in the input data streams SHOULD
will receive an identical distribution of IP PDUs from a particular be set so that an IP PDU will be directed to each of the transmit
receive port. 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: Consider the following 6 port SUT:
-------------- --------------
---------| Rx A Tx X|-------- ---------| Rx A Tx X|--------
---------| Rx B Tx Y|-------- ---------| Rx B Tx Y|--------
---------| Rx C Tx Z|-------- ---------| Rx C Tx Z|--------
-------------- --------------
The addressing of the data streams for each of the inputs SHOULD be: The addressing of the data streams for each of the inputs SHOULD be:
stream sent to Rx A: stream sent to Rx A:
IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
stream sent to Rx B: stream sent to Rx B:
IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z
stream sent to Rx C stream sent to Rx C
IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z 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 Note: Each stream contains the same sequence of IP destination
addresses; therefore, each transmit port will receive 3 IP PDUs addresses; therefore, each transmit port will receive 3 IP PDUs
simultaneously. This procedure ensures that the SUT will have to process simultaneously. This procedure ensures that the SUT will have to
multiple IP PDUs addressed to the same transmit port simultaneously. process multiple IP PDUs addressed to the same transmit port
simultaneously.
The same configuration MAY be used to perform a bi-directional multi- The same configuration MAY be used to perform a bi-directional
stream test. In this case all of the ports are considered both receive multi-stream test. In this case all of the ports are considered both
and transmit ports. Each data stream MUST consist of IP PDUs whose receive and transmit ports. Each data stream MUST consist of IP PDUs
addresses correspond to the ATM addresses all of the other ports. whose addresses correspond to the ATM addresses all of the other
ports.
2.17. Multiple protocols 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 This document does not address the issue of testing the effects of a
wanted then PDUs SHOULD be distributed between all of the test mixed protocol environment other than to suggest that if such tests
protocols. The distribution MAY approximate the conditions on the 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. network in which the SUT would be used.
2.18. Multiple IP PDU sizes 2.18. Multiple IP PDU sizes
This document does not address the issue of testing the effects of a This document does not address the issue of testing the effects of a
mixed IP PDU size environment other than to suggest that, if such tests mixed IP PDU size environment other than to suggest that, if such
are required, then IP PDU size SHOULD be evenly distributed among all of tests are required, then IP PDU size SHOULD be evenly distributed
the PDU sizes listed in this document. The distribution MAY approximate among all of the PDU sizes listed in this document. The distribution
the conditions on the network in which the SUT would be used. MAY approximate the conditions on the network in which the SUT would
be used.
2.19. Testing beyond a single SUT 2.19. Testing beyond a single SUT
In the performance testing of a single SUT, the paradigm can be In the performance testing of a single SUT, the paradigm can be
described as applying some input to a SUT and monitoring the output. The described as applying some input to a SUT and monitoring the output.
results of which can be used to form a basis of characterization of that The results of which can be used to form a basis of characterization
device under those test conditions. of that device under those test conditions.
This model is useful when the test input and output are homogenous This model is useful when the test input and output are homogeneous
(e.g., 64-byte IP, AAL5 PDUs into the SUT; 64 byte IP, AAL5 PDUs out). (e.g., 64-byte IP, AAL5 PDUs into the SUT; 64 byte IP, AAL5 PDUs
out).
By extending the single SUT test model, reasonable benchmarks regarding By extending the single SUT test model, reasonable benchmarks
multiple SUTs or heterogeneous environments may be collected. In this regarding multiple SUTs or heterogeneous environments may be
extension, the single SUT is replaced by a system of interconnected collected. In this extension, the single SUT is replaced by a system
network SUTs. This test methodology would support the benchmarking of a of interconnected network SUTs. This test methodology would support
variety of device/media/service/protocol combinations. For example, a the benchmarking of a variety of device/media/service/protocol
configuration for a LAN-to-WAN-to-LAN test might be: combinations. For example, a configuration for a LAN-to-WAN-to-LAN
test might be:
(1) ATM UNI -> SUT 1 -> BISUP -> SUT 2 -> ATM UNI (1) ATM UNI -> SUT 1 -> BISUP -> SUT 2 -> ATM UNI
Or an extended LAN configuration might be: Or an extended LAN configuration might be:
(2) ATM UNI -> SUT 1 -> PNNI Network -> SUT 2 -> ATM UNI (2) ATM UNI -> SUT 1 -> PNNI Network -> SUT 2 -> ATM UNI
In both examples 1 and 2, end-to-end benchmarks of each system could be In both examples 1 and 2, end-to-end benchmarks of each system could
empirically ascertained. Other behavior may be characterized through the be empirically ascertained. Other behavior may be characterized
use of intermediate devices. In example 2, the configuration may be used through the use of intermediate devices. In example 2, the
to give an indication of the effect of PNNI routing on IP throughput. configuration may be used to give an indication of the effect of PNNI
routing on IP throughput.
Because multiple SUTs are treated as a single system, there are Because multiple SUTs are treated as a single system, there are
limitations to this methodology. For instance, this methodology may limitations to this methodology. For instance, this methodology may
yield an aggregate benchmark for a tested system. That benchmark alone, yield an aggregate benchmark for a tested system. That benchmark
however, may not necessarily reflect asymmetries in behavior between the alone, however, may not necessarily reflect asymmetries in behavior
SUTs, latencies introduced by other apparatus (e.g., CSUs/DSUs, between the SUTs, latencies introduced by other apparatus (e.g.,
switches), etc. CSUs/DSUs, switches), etc.
Further, care must be used when comparing benchmarks of different Further, care must be used when comparing benchmarks of different
systems by ensuring that the SUTs' features and configuration of the systems by ensuring that the SUTs' features and configuration of the
tested systems have the appropriate common denominators to allow tested systems have the appropriate common denominators to allow
comparison. comparison.
2.20. Maximum IP PDU rate 2.20. Maximum IP PDU rate
The maximum IP PDU rates that should be used when testing LAN The maximum IP PDU rates that should be used when testing LAN
connections SHOULD be the listed theoretical maximum rate for the IP PDU connections SHOULD be the listed theoretical maximum rate for the IP
size on the media. PDU size on the media.
The maximum IP PDU rate that should be used when testing WAN connections The maximum IP PDU rate that should be used when testing WAN
SHOULD be greater than the listed theoretical maximum rate for the IP connections SHOULD be greater than the listed theoretical maximum
PDU size on that speed connection. The higher rate for WAN tests is to rate for the IP PDU size on that speed connection. The higher rate
compensate for the fact that some vendors employ various forms of header for WAN tests is to compensate for the fact that some vendors employ
compression. various forms of header compression.
A list of maximum IP PDU rates for LAN connections is included in A list of maximum IP PDU rates for LAN connections is included in
Appendix B. Appendix B.
2.21. Bursty traffic 2.21. Bursty traffic
It is convenient to measure the SUT performance under steady state load; It is convenient to measure the SUT performance under steady state
however, this is an unrealistic way to gauge the functioning of a SUT. load; however, this is an unrealistic way to gauge the functioning of
Actual network traffic normally consists of bursts of IP PDUs. a SUT. Actual network traffic normally consists of bursts of IP
PDUs.
Some of the tests described below SHOULD be performed with both constant Some of the tests described below SHOULD be performed with both
bit rate, bursty Unspecified Bit Rate (UBR) Best Effort [AF-TM4.1] and constant bit rate, bursty Unspecified Bit Rate (UBR) Best Effort
Variable Bit Rate Non-real Time (VBR-nrt) Best Effort [AF-TM4.1]. The [AF-TM4.1] and Variable Bit Rate Non-real Time (VBR-nrt) Best Effort
IP PDUs within a burst are transmitted with the minimum legitimate [AF-TM4.1]. The IP PDUs within a burst are transmitted with the
inter-IP PDU gap. minimum legitimate inter-IP PDU gap.
The objective of the test is to determine the minimum interval between The objective of the test is to determine the minimum interval
bursts that the SUT can process with no IP PDU loss. Tests SHOULD be between bursts that the SUT can process with no IP PDU loss. Tests
run with burst sizes of 10% of Maximum Burst Size (MBS), 20% of MBS, 50% SHOULD be run with burst sizes of 10% of Maximum Burst Size (MBS),
of MBS and 100% MBS. Note that the number of IP PDUs in each burst will 20% of MBS, 50% of MBS and 100% MBS. Note that the number of IP PDUs
depend on the PDU size. For UBR, the MBS refers to the associated VBR in each burst will depend on the PDU size. For UBR, the MBS refers
traffic parameters. to the associated VBR traffic parameters.
2.22. Trial description 2.22. Trial description
A particular test consists of multiple trials. Each trial returns one A particular test consists of multiple trials. Each trial returns
piece of information, for example the loss rate at a particular input IP one piece of information, for example the loss rate at a particular
PDU rate. Each trial consists of five of phases: input IP PDU rate. Each trial consists of five of phases:
a) If the SUT is a switch supporting PNNI, send the routing update to a) If the SUT is a switch supporting PNNI, send the routing update to
the SUT receive port and wait two seconds to be sure that the routing the SUT receive port and wait two seconds to be sure that the
has settled. routing has settled.
b) Send an ATM ARP PDU to determine the ATM address corresponding to the b) Send an ATM ARP PDU to determine the ATM address corresponding to
destination IP address. The formats of the ATM ARP PDU that should be the destination IP address. The formats of the ATM ARP PDU that
used are shown in the Test Frame Formats document and MUST be in should be used are shown in the Test Frame Formats document and
accordance with RFC 2225. MUST be in accordance with RFC 2225.
c) Stimulate SUT with traffic load. c) Stimulate SUT with traffic load.
d) Wait for two seconds for any residual IP PDUs to be received. d) Wait for two seconds for any residual IP PDUs to be received.
e) Wait for at least five seconds for the SUT to restabilize. e) Wait for at least five seconds for the SUT to restabilize.
2.23. Trial duration 2.23. Trial duration
The objective of the tests defined in this document is to accurately The objective of the tests defined in this document is to accurately
characterize the behavior of a particular piece of network equipment characterize the behavior of a particular piece of network equipment
under varying traffic loads. The choice of test duration must be a under varying traffic loads. The choice of test duration must be a
compromise between this objective and keeping the duration of the compromise between this objective and keeping the duration of the
benchmarking test suite within reasonable bounds. The SUT SHOULD be benchmarking test suite within reasonable bounds. The SUT SHOULD be
stimulated for at least 60 seconds. If this time period results in a stimulated for at least 60 seconds. If this time period results in a
high variance in the test results, the SUT SHOULD be stimulated for at high variance in the test results, the SUT SHOULD be stimulated for
least 300 seconds. at least 300 seconds.
2.24. Address resolution 2.24. Address resolution
The SUT MUST be able to respond to address resolution requests sent by The SUT MUST be able to respond to address resolution requests sent
another SUT, an ATM ARP server or the test equipment in accordance with by another SUT, an ATM ARP server or the test equipment in accordance
RFC 2225. with RFC 2225.
2.25. Synchronized Payload Bit Pattern. 2.25. Synchronized Payload Bit Pattern.
Some measurements assume that both the transmitter and receiver payload Some measurements assume that both the transmitter and receiver
information is synchronized. Synchronization MUST be achieved by payload information is synchronized. Synchronization MUST be
supplying a known bit pattern to both the transmitter and receiver. achieved by supplying a known bit pattern to both the transmitter and
This bit pattern MUST be one of the following: PRBS-15, PRBS-23, 0xFF00, receiver. This bit pattern MUST be one of the following: PRBS-15,
or 0xAA55. PRBS-23, 0xFF00, or 0xAA55.
2.26. Burst Traffic Descriptors. 2.26. Burst Traffic Descriptors.
Some measurements require busty traffic patterns. These patterns MUST Some measurements require busty traffic patterns. These patterns
conform to one of the following traffic descriptors: MUST conform to one of the following traffic descriptors:
1) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=8192 1) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=8192
2) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=4096 2) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=4096
3) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=8192 3) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=8192
4) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=4096 4) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=4096
5) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=8192 5) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=8192
6) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=4096 6) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=4096
7) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=65536 7) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=65536
8) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=32768 8) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=32768
The allotted line rate refers to the total available line rate divided The allotted line rate refers to the total available line rate
by the number of VCCs in use. divided by the number of VCCs in use.
3. Performance Metrics 3. Performance Metrics
3.1. Physical Layer- SONET 3.1. Physical Layer-SONET
3.1.1. Pointer Movements 3.1.1. Pointer Movements
3.1.1.1. Pointer Movement Propagation. 3.1.1.1. Pointer Movement Propagation.
Objective: To determine that the SUT does not propagate pointer movements Objective: To determine that the SUT does not propagate pointer
as defined in RFC 2761 "Terminology for ATM Benchmarking". movements as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of IP PDUs at a specific rate through the SUT. 2) Send a specific number of IP PDUs at a specific rate through the
Since this test is not a throughput test, the rate should not be greater SUT. Since this test is not a throughput test, the rate should
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs. not be greater than 90% of line rate. The cell payload SHOULD
The IP PDUs MUST be encapsulated in AAL5. contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5.
3) Count the IP PDUs that are transmitted by the SUT to verify 3) Count the IP PDUs that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test, else lower the test device traffic rate same on the SUT, continue the test, else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one forward payload pointer movement. Verify that the SUT 4) Inject one forward payload pointer movement. Verify that the SUT
does not change the pointer. does not change the pointer.
5) Inject one forward payload pointer movement every 1 second. Verify 5) Inject one forward payload pointer movement every 1 second.
that the SUT does not change the pointer. Verify that the SUT does not change the pointer.
6) Discontinue the payload pointer movement. 6) Discontinue the payload pointer movement.
7) Inject five forward payload pointer movements every 1 second. Verify 7) Inject five forward payload pointer movements every 1 second.
that the SUT does not change the pointer. Verify that the SUT does not change the pointer.
8) Discontinue the payload pointer movement. 8) Discontinue the payload pointer movement.
9) Inject one backward payload pointer movement. Verify that the SUT 9) Inject one backward payload pointer movement. Verify that the
does not change the pointer. SUT does not change the pointer.
10) Inject one backward payload pointer movement every 1 second. Verify 10) Inject one backward payload pointer movement every 1 second.
that the SUT does not change the pointer. Verify that the SUT does not change the pointer.
11) Discontinue the payload pointer movement. 11) Discontinue the payload pointer movement.
12) Inject five backward payload pointer movements every 1 second. 12) Inject five backward payload pointer movements every 1 second.
Verify that the SUT does not change the pointer. Verify that the SUT does not change the pointer.
13) Discontinue the payload pointer movement. 13) Discontinue the payload pointer movement.
Reporting Format: Reporting Format:
The results of the pointer movement propagation test SHOULD be reported The results of the pointer movement propagation test SHOULD be
in a form of a table. The rows SHOULD be labeled single pointer reported in a form of a table. The rows SHOULD be labeled single
movement, one pointer movement per second, and five pointer movements pointer movement, one pointer movement per second, and five
per second. The columns SHOULD be labeled pointer movement and loss of pointer movements per second. The columns SHOULD be labeled
pointer. The elements of the table SHOULD be either True or False, pointer movement and loss of pointer. The elements of the table
indicating whether the particular condition was observed for each test. 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 The table MUST also indicate the IP PDU size in octets and traffic
in IP PDUs per second as generated by the test device. rate in IP PDUs per second as generated by the test device.
3.1.1.2. Cell Loss due to Pointer Movement. 3.1.1.2. Cell Loss due to Pointer Movement.
Objective: To determine if the SUT will drop cells due to pointer movements Objective: To determine if the SUT will drop cells due to pointer
as defined in RFC 2761 "Terminology for ATM Benchmarking". movements as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of cells at a specific rate through the SUT. 2) Send a specific number of cells at a specific rate through the
Since this test is not a throughput test, the rate should not be greater SUT. Since this test is not a throughput test, the rate should
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs. not be greater than 90% of line rate. The cell payload SHOULD
The IP PDUs MUST be encapsulated in AAL5. contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify 3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one forward payload pointer movement. Verify that the SUT 4) Inject one forward payload pointer movement. Verify that the SUT
does not drop any cells. does not drop any cells.
5) Inject one forward payload pointer movement every 1 second. Verify 5) Inject one forward payload pointer movement every 1 second.
that the SUT does not drop any cells. Verify that the SUT does not drop any cells.
6) Discontinue the payload pointer movement. 6) Discontinue the payload pointer movement.
7) Inject five forward payload pointer movements every 1 second. Verify 7) Inject five forward payload pointer movements every 1 second.
that the SUT does not drop any cells. Verify that the SUT does not drop any cells.
8) Discontinue the payload pointer movement. 8) Discontinue the payload pointer movement.
9) Inject one backward payload pointer movement. Verify that the SUT 9) Inject one backward payload pointer movement. Verify that the
does not drop any cells. SUT does not drop any cells.
10) Inject one backward payload pointer movement every 1 second. Verify 10) Inject one backward payload pointer movement every 1 second.
that the SUT does not drop any cells. Verify that the SUT does not drop any cells.
11) Discontinue the payload pointer movement. 11) Discontinue the payload pointer movement.
12) Inject five backward payload pointer movements every 1 second. 12) Inject five backward payload pointer movements every 1 second.
Verify that the SUT does not drop any cells. Verify that the SUT does not drop any cells.
13) Discontinue the payload pointer movement. 13) Discontinue the payload pointer movement.
Reporting Format: Reporting Format:
The results of the cell loss due to pointer movement test SHOULD be The results of the cell loss due to pointer movement test SHOULD
reported in a form of a table. The rows SHOULD be labeled single pointer be reported in a form of a table. The rows SHOULD be labeled
movement, one pointer movement per second, and five pointer movements single pointer movement, one pointer movement per second, and five
per second. The columns SHOULD be labeled cell loss and number of cells pointer movements per second. The columns SHOULD be labeled cell
lost. The elements of column 1 SHOULD be either True or False, loss and number of cells lost. The elements of column 1 SHOULD be
indicating whether the particular condition was observed for each test. either True or False, indicating whether the particular condition
The elements of column 2 SHOULD be non-negative integers. 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 The table MUST also indicate the traffic rate in IP PDUs per
generated by the test device. second as generated by the test device.
3.1.1.3. IP Packet Loss due to Pointer Movement. 3.1.1.3. IP Packet Loss due to Pointer Movement.
Objective: To determine if the SUT will drop IP packets due to pointer Objective: To determine if the SUT will drop IP packets due to
movements as defined in RFC 2761 "Terminology for ATM Benchmarking". pointer movements as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of IP packets at a specific rate through the 2) Send a specific number of IP packets at a specific rate through
SUT. Since this test is not a throughput test, the rate should not be the SUT. Since this test is not a throughput test, the rate
greater than 90% of line rate. The IP PDUs MUST be encapsulated in should not be greater than 90% of line rate. The IP PDUs MUST be
AAL5. encapsulated in AAL5.
3) Count the IP packets that are transmitted by the SUT to verify 3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one forward payload pointer movement. Verify that the SUT 4) Inject one forward payload pointer movement. Verify that the SUT
does not drop any packets. does not drop any packets.
5) Inject one forward payload pointer movement every 1 second. Verify 5) Inject one forward payload pointer movement every 1 second.
that the SUT does not drop any packets. Verify that the SUT does not drop any packets.
6) Discontinue the payload pointer movement. 6) Discontinue the payload pointer movement.
7) Inject five forward payload pointer movements every 1 second. Verify 7) Inject five forward payload pointer movements every 1 second.
that the SUT does not drop any packets. Verify that the SUT does not drop any packets.
8) Discontinue the payload pointer movement. 8) Discontinue the payload pointer movement.
9) Inject one backward payload pointer movement. Verify that the SUT 9) Inject one backward payload pointer movement. Verify that the
does not drop any packets. SUT does not drop any packets.
10) Inject one backward payload pointer movement every 1 second. Verify 10) Inject one backward payload pointer movement every 1 second.
that the SUT does not drop any packets. Verify that the SUT does not drop any packets.
11) Discontinue the payload pointer movement. 11) Discontinue the payload pointer movement.
12) Inject five backward payload pointer movements every 1 second. 12) Inject five backward payload pointer movements every 1 second.
Verify that the SUT does not drop any packets. Verify that the SUT does not drop any packets.
13) Discontinue the payload pointer movement. 13) Discontinue the payload pointer movement.
Reporting Format: Reporting Format:
The results of the IP packet loss due to pointer movement test SHOULD be The results of the IP packet loss due to pointer movement test
reported in a form of a table. The rows SHOULD be labeled single pointer SHOULD be reported in a form of a table. The rows SHOULD be
movement, one pointer movement per second, and five pointer movements labeled single pointer movement, one pointer movement per second,
per second. The columns SHOULD be labeled packet loss and number of and five pointer movements per second. The columns SHOULD be
packets lost. The elements of column 1 SHOULD be either True or False, labeled packet loss and number of packets lost. The elements of
indicating whether the particular condition was observed for each test. column 1 SHOULD be either True or False, indicating whether the
The elements of column 2 SHOULD be non-negative integers. 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 The table MUST also indicate the packet size in octets and traffic
in packets per second as generated by the test device. rate in packets per second as generated by the test device.
3.1.2. Transport Overhead (TOH) Error Count 3.1.2. Transport Overhead (TOH) Error Count
3.1.2.1. TOH Error Propagation. 3.1.2.1. TOH Error Propagation.
Objective: To determine that the SUT does not propagate TOH errors as Objective: To determine that the SUT does not propagate TOH errors as
defined in RFC 2761 "Terminology for ATM Benchmarking". defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of IP PDUs at a specific rate through the SUT. 2) Send a specific number of IP PDUs at a specific rate through the
Since this test is not a throughput test, the rate should not be greater SUT. Since this test is not a throughput test, the rate should
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs. not be greater than 90% of line rate. The cell payload SHOULD
The IP PDUs MUST be encapsulated in AAL5. contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5.
3) Count the IP PDUs that are transmitted by the SUT to verify 3) Count the IP PDUs that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test, else lower the test device traffic rate same on the SUT, continue the test, else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one error in the first bit of the A1 and A2 Frameword. Verify 4) Inject one error in the first bit of the A1 and A2 Frameword.
that the SUT does not propagate the error. Verify that the SUT does not propagate the error.
5) Inject one error in the first bit of the A1 and A2 Frameword every 1 5) Inject one error in the first bit of the A1 and A2 Frameword
second. Verify that the SUT does not propagate the error. every 1 second. Verify that the SUT does not propagate the
error.
6) Discontinue the Frameword error. 6) Discontinue the Frameword error.
7) Inject one error in the first bit of the A1 and A2 Frameword for 4 7) Inject one error in the first bit of the A1 and A2 Frameword for
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT indicates 4 consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT
Loss of Frame. indicates Loss of Frame.
8) Discontinue the Frameword error. 8) Discontinue the Frameword error.
Reporting Format: Reporting Format:
The results of the TOH error propagation test SHOULD be reported in a The results of the TOH error propagation test SHOULD be reported
form of a table. The rows SHOULD be labeled single error, one error per in a form of a table. The rows SHOULD be labeled single error,
second, and four consecutive errors every 6 IP PDUs. The columns SHOULD one error per second, and four consecutive errors every 6 IP PDUs.
be labeled error propagated and loss of IP PDU. The elements of the The columns SHOULD be labeled error propagated and loss of IP PDU.
table SHOULD be either True or False, indicating whether the particular The elements of the table SHOULD be either True or False,
condition was observed for each test. indicating whether the particular condition was observed for each
test.
The table MUST also indicate the IP PDU size in octets and traffic rate The table MUST also indicate the IP PDU size in octets and traffic
in IP PDUs per second as generated by the test device. rate in IP PDUs per second as generated by the test device.
3.1.2.2. c TOH Error. 3.1.2.2. c TOH Error.
Objective: To determine if the SUT will drop cells due TOH Errors as Objective: To determine if the SUT will drop cells due TOH Errors as
defined in RFC 2761 "Terminology for ATM Benchmarking". defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of cells at a specific rate through the SUT. 2) Send a specific number of cells at a specific rate through the
Since this test is not a throughput test, the rate should not be greater SUT. Since this test is not a throughput test, the rate should
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs. not be greater than 90% of line rate. The cell payload SHOULD
The IP PDUs MUST be encapsulated in AAL5. contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify 3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one error in the first bit of the A1 and A2 Frameword. Verify 4) Inject one error in the first bit of the A1 and A2 Frameword.
that the SUT does not drop any cells. Verify that the SUT does not drop any cells.
5) Inject one error in the first bit of the A1 and A2 Frameword every 1 5) Inject one error in the first bit of the A1 and A2 Frameword
second. Verify that the SUT does not drop any cells. every 1 second. Verify that the SUT does not drop any cells.
6) Discontinue the Frameword error. 6) Discontinue the Frameword error.
7) Inject one error in the first bit of the A1 and A2 Frameword for 4 7) Inject one error in the first bit of the A1 and A2 Frameword for
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does drop 4 consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT
cells. does drop cells.
8) Discontinue the Frameword error. 8) Discontinue the Frameword error.
Reporting Format: Reporting Format:
The results of the Cell Loss due to TOH errors test SHOULD be reported The results of the Cell Loss due to TOH errors test SHOULD be
in a form of a table. The rows SHOULD be labeled single error, one error reported in a form of a table. The rows SHOULD be labeled single
per second, and four consecutive errors every 6 IP PDUs. The columns error, one error per second, and four consecutive errors every 6
SHOULD be labeled cell loss and number of cells lost. The elements of IP PDUs. The columns SHOULD be labeled cell loss and number of
column 1 SHOULD be either True or False, indicating whether the cells lost. The elements of column 1 SHOULD be either True or
particular condition was observed for each test. The elements of column False, indicating whether the particular condition was observed
2 SHOULD be non-negative integers. 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 The table MUST also indicate the traffic rate in IP PDUs per
generated by the test device. second as generated by the test device.
3.1.2.3. IP Packet Loss due to TOH Error. 3.1.2.3. IP Packet Loss due to TOH Error.
Objective: To determine if the SUT will drop IP packets due to TOH errors Objective: To determine if the SUT will drop IP packets due to TOH
as defined in RFC 2761 "Terminology for ATM Benchmarking". errors as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of IP packets at a specific rate through the 2) Send a specific number of IP packets at a specific rate through
SUT. Since this test is not a throughput test, the rate should not be the SUT. Since this test is not a throughput test, the rate
greater than 90% of line rate. The IP PDUs MUST be encapsulated in should not be greater than 90% of line rate. The IP PDUs MUST be
AAL5. encapsulated in AAL5.
3) Count the IP packets that are transmitted by the SUT to verify 3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one error in the first bit of the A1 and A2 Frameword. Verify 4) Inject one error in the first bit of the A1 and A2 Frameword.
that the SUT does not drop any packets. Verify that the SUT does not drop any packets.
5) Inject one error in the first bit of the A1 and A2 Frameword every 1 5) Inject one error in the first bit of the A1 and A2 Frameword
second. Verify that the SUT does not drop any packets. every 1 second. Verify that the SUT does not drop any packets.
6) Discontinue the Frameword error. 6) Discontinue the Frameword error.
7) Inject one error in the first bit of the A1 and A2 Frameword for 4 7) Inject one error in the first bit of the A1 and A2 Frameword for
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does drop 4 consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT
packets. does drop packets.
8) Discontinue the Frameword error. 8) Discontinue the Frameword error.
Reporting Format: Reporting Format:
The results of the IP packet loss due to TOH errors test SHOULD be The results of the IP packet loss due to TOH errors test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single error, reported in a form of a table. The rows SHOULD be labeled single
one error per second, and four consecutive errors every 6 IP PDUs. The error, one error per second, and four consecutive errors every 6
columns SHOULD be labeled packet loss and number of packets lost. The IP PDUs. The columns SHOULD be labeled packet loss and number of
elements of column 1 SHOULD be either True or False, indicating whether packets lost. The elements of column 1 SHOULD be either True or
the particular condition was observed for each test. The elements of False, indicating whether the particular condition was observed
column 2 SHOULD be non-negative integers. 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 The table MUST also indicate the packet size in octets and traffic
in packets per second as generated by the test device. rate in packets per second as generated by the test device.
3.1.3. Path Overhead (POH) Error Count 3.1.3. Path Overhead (POH) Error Count
3.1.3.1. POH Error Propagation. 3.1.3.1. POH Error Propagation.
Objective: To determine that the SUT does not propagate POH errors as Objective: To determine that the SUT does not propagate POH errors as
defined in RFC 2761 "Terminology for ATM Benchmarking". defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of IP PDUs at a specific rate through the SUT. 2) Send a specific number of IP PDUs at a specific rate through the
Since this test is not a throughput test, the rate should not be greater SUT. Since this test is not a throughput test, the rate should
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs. not be greater than 90% of line rate. The cell payload SHOULD
The IP PDUs MUST be encapsulated in AAL5. contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5.
3) Count the IP PDUs that are transmitted by the SUT to verify 3) Count the IP PDUs that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test, else lower the test device traffic rate same on the SUT, continue the test, else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT 4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT
does not propagate the error. does not propagate the error.
5) Inject one error in the B3 byte every 1 second. Verify that the SUT 5) Inject one error in the B3 byte every 1 second. Verify that the
does not propagate the error. SUT does not propagate the error.
6) Discontinue the POH error. 6) Discontinue the POH error.
Reporting Format: Reporting Format:
The results of the POH error propagation test SHOULD be reported in a The results of the POH error propagation test SHOULD be reported
form of a table. The rows SHOULD be labeled single error and one error in a form of a table. The rows SHOULD be labeled single error
per second. The columns SHOULD be labeled error propagated and loss of and one error per second. The columns SHOULD be labeled error
IP PDU. The elements of the table SHOULD be either True or False, propagated and loss of IP PDU. The elements of the table SHOULD
indicating whether the particular condition was observed for each test. 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 The table MUST also indicate the IP PDU size in octets and
in IP PDUs per second as generated by the test device. traffic rate in IP PDUs per second as generated by the test
device.
3.1.3.2. Cell Loss due to POH Error. 3.1.3.2. Cell Loss due to POH Error.
Objective: To determine if the SUT will drop cells due POH Errors as Objective: To determine if the SUT will drop cells due POH Errors as
defined in RFC 2761 "Terminology for ATM Benchmarking". defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of cells at a specific rate through the SUT. 2) Send a specific number of cells at a specific rate through the
Since this test is not a throughput test, the rate should not be greater SUT. Since this test is not a throughput test, the rate should
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs. not be greater than 90% of line rate. The cell payload SHOULD
The IP PDUs MUST be encapsulated in AAL5. contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify 3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT 4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT
does not drop any cells. does not drop any cells.
5) Inject one error in the B3 byte every 1 second. Verify that the SUT 5) Inject one error in the B3 byte every 1 second. Verify that the
does not drop any cells. SUT does not drop any cells.
6) Discontinue the POH error. 6) Discontinue the POH error.
Reporting Format: Reporting Format:
The results of the Cell Loss due to POH errors test SHOULD be reported The results of the Cell Loss due to POH errors test SHOULD be
in a form of a table. The rows SHOULD be labeled single error and one reported in a form of a table. The rows SHOULD be labeled single
error per second. The columns SHOULD be labeled cell loss and number of error and one error per second. The columns SHOULD be labeled
cells lost. The elements of column 1 SHOULD be either True or False, cell loss and number of cells lost. The elements of column 1
indicating whether the particular condition was observed for each test. SHOULD be either True or False, indicating whether the particular
The elements of column 2 SHOULD be non-negative integers. 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 The table MUST also indicate the traffic rate in IP PDUs per
generated by the test device. second as generated by the test device.
3.1.3.3. IP Packet Loss due to POH Error. 3.1.3.3. IP Packet Loss due to POH Error.
Objective: To determine if the SUT will drop IP packets due to POH errors Objective: To determine if the SUT will drop IP packets due to POH
as defined in RFC 2761 "Terminology for ATM Benchmarking". errors as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the uni-directional 1) Set up the SUT and test device using the uni-directional
configuration. configuration.
2) Send a specific number of IP packets at a specific rate through the 2) Send a specific number of IP packets at a specific rate through
SUT. Since this test is not a throughput test, the rate should not be the SUT. Since this test is not a throughput test, the rate
greater than 90% of line rate. The IP PDUs MUST be encapsulated in should not be greater than 90% of line rate. The IP PDUs MUST be
AAL5. encapsulated in AAL5.
3) Count the IP packets that are transmitted by the SUT to verify 3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT 4) Inject one error in the B3 (Path BIP8) byte. Verify that the SUT
does not drop any packets. does not drop any packets.
5) Inject one error in the B3 byte every 1 second. Verify that the SUT 5) Inject one error in the B3 byte every 1 second. Verify that the
does not drop any packets. SUT does not drop any packets.
6) Discontinue the POH error. 6) Discontinue the POH error.
Reporting Format: Reporting Format:
The results of the IP packet loss due to POH errors test SHOULD be 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 reported in a form of a table. The rows SHOULD be labeled single
and one error per second. The columns SHOULD be labeled packet loss and error and one error per second. The columns SHOULD be labeled
number of packets lost. The elements of column 1 SHOULD be either True packet loss and number of packets lost. The elements of column 1
or False, indicating whether the particular condition was observed for SHOULD be either True or False, indicating whether the particular
each test. The elements of column 2 SHOULD be non-negative integers. 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 The table MUST also indicate the packet size in octets and traffic
in packets per second as generated by the test device. rate in packets per second as generated by the test device.
3.2. ATM Layer 3.2. ATM Layer
3.2.1. Two-Point Cell Delay Variation (CDV) 3.2.1. Two-Point Cell Delay Variation (CDV)
3.2.1.1. Test Setup 3.2.1.1. Test Setup
The cell delay measurements assume that both the transmitter and The cell delay measurements assume that both the transmitter and
receiver timestamp information is synchronized. Synchronization SHOULD receiver timestamp information is synchronized. Synchronization
be achieved by supplying a common clock signal (minimum of 100 Mhz or 10 SHOULD be achieved by supplying a common clock signal (minimum of 100
ns resolution) to both the transmitter and receiver. The maximum Mhz or 10 ns resolution) to both the transmitter and receiver. The
timestamp values MUST be recorded to ensure synchronization in the case maximum timestamp values MUST be recorded to ensure synchronization
of counter rollover. The cell delay measurements SHOULD utilize the in the case of counter rollover. The cell delay measurements SHOULD
O.191 cell (ITUT-O.191) encapsulated in a valid IP packet. If the O.191 utilize the O.191 cell (ITUT-O.191) encapsulated in a valid IP
cell is not available, a test cell encapsulated in a valid IP packet MAY packet. If the O.191 cell is not available, a test cell encapsulated
be used. The test cell MUST contain a transmit timestamp which can be in a valid IP packet MAY be used. The test cell MUST contain a
correlated with a receive timestamp. A description of the test cell MUST transmit timestamp which can be correlated with a receive timestamp.
be included in the test results. The description MUST include the A description of the test cell MUST be included in the test results.
timestamp length (in bits), counter rollover value, and the timestamp The description MUST include the timestamp length (in bits), counter
accuracy (in ns). rollover value, and the timestamp accuracy (in ns).
3.2.1.2. Two-point CDV/Steady Load/One VCC 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: Objective: To determine the SUT variation in cell transfer delay with
one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
1) Set up the SUT and test device using the bi-directional Procedure:
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 1) Set up the SUT and test device using the bi-directional
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or configuration.
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a 2) Configure the SUT and test device with one VCC. The VCC SHOULD
specific constant rate through the SUT via the defined test VCC. Since contain one VPI/VCI. The VCC MUST be configured as either a CBR,
this test is not a throughput test, the rate should not be greater than VBR, or UBR connection. The VPI/VCI MUST not be one of the
90% of line rate. The IP PDUs MUST be encapsulated in AAL5. reserved ATM signaling channels (e.g., [0,5], [0,16]).
4) Count the IP packets that are transmitted by the SUT to verify 3) Send a specific number of IP packets containing timestamps at a
connectivity and load. If the count on the test device is the same on specific constant rate through the SUT via the defined test VCC.
the SUT, continue the test; else lower the test device traffic rate Since this test is not a throughput test, the rate should not be
until the counts are the same. greater than 90% of line rate. The IP PDUs MUST be encapsulated
in AAL5.
5) Record the packets timestamps at the transmitter and receiver ends of 4) Count the IP packets that are transmitted by the SUT to verify
the test device. connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device
traffic rate until the counts are the same.
Reporting Format: 5) Record the packets timestamps at the transmitter and receiver
ends of the test device.
The results of the Two-point CDV/Steady Load/One VCC test SHOULD be Reporting Format:
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The The results of the Two-point CDV/Steady Load/One VCC test SHOULD
values given SHOULD include: time period of test in s, test VPI/VCI be reported in a form of text, graph, and histogram.
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- The text results SHOULD display the numerical values of the CDV.
coordinate SHOULD be the test run time in either seconds, minutes or The values given SHOULD include: time period of test in s, test
days depending on the total length of the test. The x-coordinate time VPI/VCI value, total number of cells transmitted and received on
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in the given VPI/VCI during the test in positive integers, maximum
us. The integration time per point MUST be indicated. and minimum CDV during the test in us, and peak-to-peak CDV in us.
The histogram results SHOULD display the peak-to-peak cell delay. The The graph results SHOULD display the cell delay values. The x-
x- coordinate SHOULD be the cell delay in us with at least 256 bins. coordinate SHOULD be the test run time in either seconds, minutes
The y- coordinate SHOULD be the number of cells observed in each bin. 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, traffic rate The histogram results SHOULD display the peak-to-peak cell delay.
in packets per second, and bearer class as generated by the test device. The x-coordinate SHOULD be the cell delay in us with at least 256
The VCC and VPI/VCI values MUST be indicated. The bearer class of the bins. The y-coordinate SHOULD be the number of cells observed in
created VCC MUST also be indicated. each bin.
The results MUST also indicate the packet size in octets, traffic
rate in packets per second, and bearer class as generated by the
test device. The VCC and VPI/VCI values MUST be indicated. The
bearer class of the created VCC MUST also be indicated.
3.2.1.3. Two-point CDV/Steady Load/Twelve VCCs 3.2.1.3. Two-point CDV/Steady Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking". twelve VCCs as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR and 12 VCIs. The VCC's MUST be configured as either a CBR, VBR,
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling or UBR connection. The VPI/VCIs MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a 3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCCs. All specific constant rate through the SUT via the defined test VCCs.
of the VPI/VCI pairs will generate traffic at the same traffic rate. All of the VPI/VCI pairs will generate traffic at the same
Since this test is not a throughput test, the rate should not be greater traffic rate. Since this test is not a throughput test, the rate
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. should not be greater than 90% of line rate. The IP PDUs MUST be
encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 5) Record the packets timestamps at the transmitter and receiver
the test device for all VCCs. ends of the test device for all VCCs.
Reporting Format: Reporting Format:
The results of the Two-point CDV/Steady Load/Twelve VCCs test SHOULD be The results of the Two-point CDV/Steady Load/Twelve VCCs test
reported in a form of text, graph, and histograms. SHOULD be reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The The text results SHOULD display the numerical values of the CDV.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
values, total number of cells transmitted and received on each VCC VPI/VCI values, total number of cells transmitted and received on
during the test in positive integers, maximum and minimum CDV on each each VCC during the test in positive integers, maximum and minimum
VCC during the test in us, and peak-to-peak CDV on each VCC in us. 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- The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or coordinate SHOULD be the test run time in either seconds, minutes
days depending on the total length of the test. The x-coordinate time or days depending on the total length of the test. The x-
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for coordinate time SHOULD be configurable. The y-coordinate SHOULD
each VCC in ms. There SHOULD be 12 curves on the graph, one curves be the cell delay for each VCC in ms. There SHOULD be 12 curves
indicated and labeled for each VCC. The integration time per point MUST on the graph, one curves indicated and labeled for each VCC. The
be indicated. integration time per point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be The histograms SHOULD display the peak-to-peak cell delay. There
one histogram for each VCC. The x-coordinate SHOULD be the cell delay will be one histogram for each VCC. The x-coordinate SHOULD be
in us with at least 256 bins. The y-coordinate SHOULD be the number of the cell delay in us with at least 256 bins. The y-coordinate
cells observed in each bin. SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The bearer class of the test device. The VCC and VPI/VCI values MUST be indicated. The
created VCC MUST also be indicated. bearer class of the created VCC MUST also be indicated.
3.2.1.4. Two-point CDV/Steady Load/Maximum VCCs 3.2.1.4. Two-point CDV/Steady Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the Objective: To determine the SUT variation in cell transfer delay with
maximum number VCCs supported on the SUT as defined in RFC 2761 the maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking". "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with the maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The VPI. The VCC's MUST be configured as either a CBR, VBR, or UBR
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g. connection. The VPI/VCIs MUST not be one of the reserved ATM
[0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a 3) Send a specific number of IP packets containing timestamps at a
specific constant rate through the SUT via the defined test VCCs. All specific constant rate through the SUT via the defined test VCCs.
of the VPI/VCI pairs will generate traffic at the same traffic rate. All of the VPI/VCI pairs will generate traffic at the same
Since this test is not a throughput test, the rate should not be greater traffic rate. Since this test is not a throughput test, the rate
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. should not be greater than 90% of line rate. The IP PDUs MUST be
encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 5) Record the packets timestamps at the transmitter and receiver
the test device for all VCCs. ends of the test device for all VCCs.
Reporting Format: Reporting Format:
The results of the Two-point CDV/Steady Load/Maximum VCCs test SHOULD be The results of the Two-point CDV/Steady Load/Maximum VCCs test
reported in a form of text, graphs, and histograms. SHOULD be reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The The text results SHOULD display the numerical values of the CDV.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
values, total number of cells transmitted and received on each VCC VPI/VCI values, total number of cells transmitted and received on
during the test in positive integers, maximum and minimum CDV on each each VCC during the test in positive integers, maximum and minimum
VCC during the test in us, and peak-to-peak CDV on each VCC in us. CDV on each VCC during the test in us, and peak-to-peak CDV on
each VCC in us.
The graph results SHOULD display the cell delay values. There will be The graph results SHOULD display the cell delay values. There
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
The x-coordinate SHOULD be the test run time in either seconds, minutes each graph. The x-coordinate SHOULD be the test run time in
or days depending on the total length of the test. The x-coordinate time either seconds, minutes or days depending on the total length of
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for the test. The x-coordinate time SHOULD be configurable. The y-
each VCC in us. There SHOULD be no more than 10 curves on each graph, coordinate SHOULD be the cell delay for each VCC in us. There
one curve indicated and labeled for each VCC. The integration time per SHOULD be no more than 10 curves on each graph, one curve
point MUST be indicated. 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 The histograms SHOULD display the peak-to-peak cell delay. There
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in will be one histogram for each VCC. The x-coordinate SHOULD be
us with at least 256 bins. The y-coordinate SHOULD be the number of the cell delay in us with at least 256 bins. The y-coordinate
cells observed in each bin. SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The bearer class of the test device. The VCC and VPI/VCI values MUST be indicated. The
created VCC MUST also be indicated. bearer class of the created VCC MUST also be indicated.
3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC 3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one Objective: To determine the SUT variation in cell transfer delay with
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking". one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR contain one VPI/VCI. The VCC MUST be configured as either a CBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling or VBR connection. The VPI/VCI MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a 3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCC. Since this test specific VBR through the SUT via the defined test VCC. Since
is not a throughput test, the rate should not be greater than 90% of this test is not a throughput test, the rate should not be
line rate. The IP PDUs MUST be encapsulated in AAL5. greater than 90% of line rate. The IP PDUs MUST be encapsulated
in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 5) Record the packets timestamps at the transmitter and receiver
the test device. ends of the test device.
Reporting Format: Reporting Format:
The results of the Two-point CDV/Bursty VBR Load/One VCC test SHOULD be The results of the Two-point CDV/Bursty VBR Load/One VCC test
reported in a form of text, graph, and histogram. SHOULD be reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The The text results SHOULD display the numerical values of the CDV.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, maximum and minimum CDV the given VPI/VCI during the test in positive integers, maximum
during the test in us, and peak-to-peak CDV in us. 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- The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or coordinate SHOULD be the test run time in either seconds, minutes
days depending on the total length of the test. The x-coordinate time or days depending on the total length of the test. The x-
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in coordinate time SHOULD be configurable. The y-coordinate SHOULD
us. The integration time per point MUST be indicated. 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 The histogram results SHOULD display the peak-to-peak cell delay.
x- coordinate SHOULD be the cell delay in us with at least 256 bins. The x-coordinate SHOULD be the cell delay in us with at least 256
The y- coordinate SHOULD be the number of cells observed in each bin. bins. The y-coordinate SHOULD be the number of cells observed in
each bin.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.1.6. Two-point CDV/Bursty VBR Load/Twelve VCCs 3.2.1.6. Two-point CDV/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking". twelve VCCs as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection. and 12 VCIs. The VCC's MUST be configured as either a CBR or VBR
The VPI/VCIs MUST not be one of the reserved ATM signaling channels connection. The VPI/VCIs MUST not be one of the reserved ATM
(e.g. [0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a 3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCCs. All of the specific VBR through the SUT via the defined test VCCs. All of
VPI/VCI pairs will generate traffic at the same traffic rate. Since the VPI/VCI pairs will generate traffic at the same traffic rate.
this test is not a throughput test, the rate should not be greater than Since this test is not a throughput test, the rate should not be
90% of line rate. The IP PDUs MUST be encapsulated in AAL5. greater than 90% of line rate. The IP PDUs MUST be encapsulated
in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 5) Record the packets timestamps at the transmitter and receiver
the test device for all VCCs. ends of the test device for all VCCs.
Reporting Format: Reporting Format:
The results of the Two-point CDV/Bursty VBR Load/Twelve VCCs test SHOULD The results of the Two-point CDV/Bursty VBR Load/Twelve VCCs test
be reported in a form of text, graph, and histograms. SHOULD be reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The The text results SHOULD display the numerical values of the CDV.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
values, total number of cells transmitted and received on each VCC VPI/VCI values, total number of cells transmitted and received on
during the test in positive integers, maximum and minimum CDV on each each VCC during the test in positive integers, maximum and minimum
VCC during the test in us, and peak-to-peak CDV on each VCC in us. 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- The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or coordinate SHOULD be the test run time in either seconds, minutes
days depending on the total length of the test. The x-coordinate time or days depending on the total length of the test. The x-
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for coordinate time SHOULD be configurable. The y-coordinate SHOULD
each VCC in ms. There SHOULD be 12 curves on the graph, one curves be the cell delay for each VCC in ms. There SHOULD be 12 curves
indicated and labeled for each VCC. The integration time per point MUST on the graph, one curves indicated and labeled for each VCC. The
be indicated. integration time per point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be The histograms SHOULD display the peak-to-peak cell delay. There
one histogram for each VCC. The x-coordinate SHOULD be the cell delay will be one histogram for each VCC. The x-coordinate SHOULD be
in us with at least 256 bins. The y-coordinate SHOULD be the number of the cell delay in us with at least 256 bins. The y-coordinate
cells observed in each bin. SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.1.7. Two-point CDV/Bursty VBR Load/Maximum VCCs 3.2.1.7. Two-point CDV/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the Objective: To determine the SUT variation in cell transfer delay with
maximum number VCCs supported on the SUT as defined in RFC 2761 the maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking". "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific VBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Bursty VBR Load/Maximum VCCs test
SHOULD be reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. There will be
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in us. There SHOULD be no more than 10 curves on each graph,
one curve indicated and labeled for each VCC. The integration time per
point MUST be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in
us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.1.5. Two-point CDV/Bursty UBR Load/One VCC
Objective: To determine the SUT variation in cell transfer delay with one
VCC as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCC. Since this test
is not a throughput test, the rate should not be greater than 90% of
line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device.
Reporting Format:
The results of the Two-point CDV/Bursty UBR Load/One VCC test SHOULD be
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, maximum and minimum CDV
during the test in us, and peak-to-peak CDV in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in
us. The integration time per point MUST be indicated.
The histogram results SHOULD display the peak-to-peak cell delay. The
x- coordinate SHOULD be the cell delay in us with at least 256 bins.
The y- coordinate SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.6. Two-point CDV/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]).
3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCCs. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of
the test device for all VCCs.
Reporting Format:
The results of the Two-point CDV/Bursty UBR Load/Twelve VCCs test SHOULD
be reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The
values given SHOULD include: time period of test in s, test VPI/VCI
values, total number of cells transmitted and received on each VCC
during the test in positive integers, maximum and minimum CDV on each
VCC during the test in us, and peak-to-peak CDV on each VCC in us.
The graph results SHOULD display the cell delay values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for
each VCC in ms. There SHOULD be 12 curves on the graph, one curves
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be
one histogram for each VCC. The x-coordinate SHOULD be the cell delay
in us with at least 256 bins. The y-coordinate SHOULD be the number of
cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.1.7. Two-point CDV/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the
maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with the maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be VPI. The VCC's MUST be configured as either a CBR or VBR
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). connection. The VPI/VCIs MUST not be one of the reserved ATM
signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps at a 3) Send a specific number of IP packets containing timestamps at a
specific UBR through the SUT via the defined test VCCs. All of the specific VBR through the SUT via the defined test VCCs. All of
VPI/VCI pairs will generate traffic at the same traffic rate. Since the VPI/VCI pairs will generate traffic at the same traffic rate.
this test is not a throughput test, the rate should not be greater than Since this test is not a throughput test, the rate should not be
90% of line rate. The IP PDUs MUST be encapsulated in AAL5. greater than 90% of line rate. The IP PDUs MUST be encapsulated
in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 5) Record the packets timestamps at the transmitter and receiver
the test device for all VCCs. ends of the test device for all VCCs.
Reporting Format: Reporting Format:
The results of the Two-point CDV/Bursty UBR Load/Maximum VCCs test The results of the Two-point CDV/Bursty VBR Load/Maximum VCCs test
SHOULD be reported in a form of text, graphs, and histograms. SHOULD be reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The The text results SHOULD display the numerical values of the CDV.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
values, total number of cells transmitted and received on each VCC VPI/VCI values, total number of cells transmitted and received on
during the test in positive integers, maximum and minimum CDV on each each VCC during the test in positive integers, maximum and minimum
VCC during the test in us, and peak-to-peak CDV on each VCC in us. CDV on each VCC during the test in us, and peak-to-peak CDV on
each VCC in us.
The graph results SHOULD display the cell delay values. There will be The graph results SHOULD display the cell delay values. There
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
The x-coordinate SHOULD be the test run time in either seconds, minutes each graph. The x-coordinate SHOULD be the test run time in
or days depending on the total length of the test. The x-coordinate time either seconds, minutes or days depending on the total length of
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for the test. The x-coordinate time SHOULD be configurable. The y-
each VCC in us. There SHOULD be no more than 10 curves on each graph, coordinate SHOULD be the cell delay for each VCC in us. There
one curve indicated and labeled for each VCC. The integration time per SHOULD be no more than 10 curves on each graph, one curve
point MUST be indicated. 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 The histograms SHOULD display the peak-to-peak cell delay. There
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in will be one histogram for each VCC. The x-coordinate SHOULD be
us with at least 256 bins. The y-coordinate SHOULD be the number of the cell delay in us with at least 256 bins. The y-coordinate
cells observed in each bin. SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The bearer class of the test device. The VCC and VPI/VCI values MUST be indicated. The
created VCC MUST also be indicated. 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 3.2.1.8. Two-point CDV/Mixed Load/Three VCC's
Objective: To determine the SUT variation in cell transfer delay with three Objective: To determine the SUT variation in cell transfer delay with
VCC's as defined in RFC 2761 "Terminology for ATM Benchmarking". three VCC's as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be 2) Configure the SUT and test device with three VCC's. Each VCC
defined as a different Bearer class: one CBR, one UBR and one VBR. Each MUST be defined as a different Bearer class: one CBR, one UBR and
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the one VBR. Each VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST
reserved ATM signaling channels (e.g. [0,5], [0,16]). not be one of the reserved ATM signaling channels (e.g., [0,5],
[0,16]).
3) Send a specific number of IP packets containing timestamps through 3) Send a specific number of IP packets containing timestamps
the SUT via the defined test VCCs. Each generated VCC stream MUST match through the SUT via the defined test VCCs. Each generated VCC
the corresponding VCC Bearer class. All of the VPI/VCI pairs will stream MUST match the corresponding VCC Bearer class. All of the
generate traffic at the same traffic rate. Since this test is not a VPI/VCI pairs will generate traffic at the same traffic rate.
throughput test, the rate should not be greater than 90% of line rate.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify Since this test is not a throughput test, the rate should not be
connectivity and load. If the count on the test device is the same on greater than 90% of line rate. The IP PDUs MUST be encapsulated
the SUT, continue the test; else lower the test device traffic rate in AAL5.
until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 4) Count the IP packets that are transmitted by the SUT to verify
the test device for all VCC's. connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device
traffic rate until the counts are the same.
Reporting Format: 5) Record the packets timestamps at the transmitter and receiver
ends of the test device for all VCC's.
The results of the Two-point CDV/Mixed Load/Three VCC test SHOULD be Reporting Format:
reported in a form of text, graph, and histogram.
The text results SHOULD display the numerical values of the CDV. The The results of the Two-point CDV/Mixed Load/Three VCC test SHOULD
values given SHOULD include: time period of test in s, test VPI/VCI be reported in a form of text, graph, and histogram.
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- The text results SHOULD display the numerical values of the CDV.
coordinate SHOULD be the test run time in either seconds, minutes or The values given SHOULD include: time period of test in s, test
days depending on the total length of the test. The x-coordinate time VPI/VCI value, total number of cells transmitted and received on
SHOULD be configurable. The y-coordinate SHOULD be the cell delay in the given VPI/VCI during the test in positive integers, maximum
us. The integration time per point MUST be indicated. and minimum CDV during the test in us, and peak-to-peak CDV in us.
The histogram results SHOULD display the peak-to-peak cell delay. The The graph results SHOULD display the cell delay values. The x-
x- coordinate SHOULD be the cell delay in us with at least 256 bins. coordinate SHOULD be the test run time in either seconds, minutes
The y- coordinate SHOULD be the number of cells observed in each bin. 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, traffic rate The histogram results SHOULD display the peak-to-peak cell delay.
in packets per second, and bearer class as generated by the test device. The x-coordinate SHOULD be the cell delay in us with at least 256
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST bins. The y-coordinate SHOULD be the number of cells observed in
be indicated. The bearer class of the created VCC MUST also be each bin.
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.9. Two-point CDV/Mixed Load/Twelve VCCs 3.2.1.9. Two-point CDV/Mixed Load/Twelve VCCs
Objective: To determine the SUT variation in cell transfer delay with Objective: To determine the SUT variation in cell transfer delay with
twelve VCCs as defined in RFC 2761 "Terminology for ATM Benchmarking". twelve VCCs as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST 1) Set up the SUT and test device using the bi-directional
be defined as one of the Bearer classes for a total of four CBR, four configuration.
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through 2) Configure the SUT and test device with twelve VCC's. Each VCC
the SUT via the defined test VCCs. Each generated VCC stream MUST match MUST be defined as one of the Bearer classes for a total of four
the corresponding VCC Bearer class. All of the VPI/VCI pairs will CBR, four UBR and four VBR VCC's. Each VCC SHOULD contain one
generate traffic at the same traffic rate. Since this test is not a VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM
throughput test, the rate should not be greater than 90% of line rate. signaling channels (e.g., [0,5], [0,16]).
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 3) Send a specific number of IP packets containing timestamps
verify connectivity and load. If the count on the test device is the through the SUT via the defined test VCCs. Each generated VCC
same on the SUT, continue the test; else lower the test device traffic stream MUST match the corresponding VCC Bearer class. All of the
rate until the counts are the same. 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.
5) Record the packets timestamps at the transmitter and receiver ends of 4) Count the IP packets that are transmitted by the SUT on all VCCs
the test device for 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.
Reporting Format: 5) Record the packets timestamps at the transmitter and receiver
ends of the test device for all VCCs.
The results of the Two-point CDV/Mixed Load/Twelve VCCs test SHOULD be Reporting Format:
reported in a form of text, graph, and histograms.
The text results SHOULD display the numerical values of the CDV. The The results of the Two-point CDV/Mixed Load/Twelve VCCs test
values given SHOULD include: time period of test in s, test VPI/VCI SHOULD be reported in a form of text, graph, and histograms.
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- The text results SHOULD display the numerical values of the CDV.
coordinate SHOULD be the test run time in either seconds, minutes or The values given SHOULD include: time period of test in s, test
days depending on the total length of the test. The x-coordinate time VPI/VCI values, total number of cells transmitted and received on
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for each VCC during the test in positive integers, maximum and minimum
each VCC in ms. There SHOULD be 12 curves on the graph, one curves CDV on each VCC during the test in us, and peak-to-peak CDV on
indicated and labeled for each VCC. The integration time per point MUST each VCC in us.
be indicated.
The histograms SHOULD display the peak-to-peak cell delay. There will be The graph results SHOULD display the cell delay values. The x-
one histogram for each VCC. The x-coordinate SHOULD be the cell delay coordinate SHOULD be the test run time in either seconds, minutes
in us with at least 256 bins. The y-coordinate SHOULD be the number of or days depending on the total length of the test. The x-
cells observed in each bin. 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 The histograms SHOULD display the peak-to-peak cell delay. There
in packets per second, and bearer class as generated by the test device. will be one histogram for each VCC. The x-coordinate SHOULD be
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST the cell delay in us with at least 256 bins. The y-coordinate
be indicated. The bearer class of the created VCC MUST also be SHOULD be the number of cells observed in each bin.
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 3.2.1.10. Two-point CDV/Mixed Load/Maximum VCCs
Objective: To determine the SUT variation in cell transfer delay with the Objective: To determine the SUT variation in cell transfer delay with
maximum number VCCs supported on the SUT as defined in RFC 2761 the maximum number VCCs supported on the SUT as defined in RFC 2761
"Terminology for ATM Benchmarking". "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with maximum number of VCCs 2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC MUST be defined as one of the Bearer classes for a total of (max VPI. Each VCC MUST be defined as one of the Bearer classes for a
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. If the maximum total of (max VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR
number of VCC's is not divisible by 3, the total for each bearer class VCC's. If the maximum number of VCC's is not divisible by 3, the
MUST be within 3 VCC's of each other. The VPI/VCI MUST not be one of total for each bearer class MUST be within 3 VCC's of each other.
the reserved ATM signaling channels (e.g. [0,5], [0,16]). The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing timestamps through 3) Send a specific number of IP packets containing timestamps
the SUT via the defined test VCCs. Each generated VCC stream MUST match through the SUT via the defined test VCCs. Each generated VCC
the corresponding VCC Bearer class. All of the VPI/VCI pairs will stream MUST match the corresponding VCC Bearer class. All of the
generate traffic at the same traffic rate. Since this test is not a VPI/VCI pairs will generate traffic at the same traffic rate.
throughput test, the rate should not be greater than 90% of line rate. Since this test is not a throughput test, the rate should not be
The IP PDUs MUST be encapsulated in AAL5. greater than 90% of line rate. The IP PDUs MUST be encapsulated
in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the packets timestamps at the transmitter and receiver ends of 5) Record the packets timestamps at the transmitter and receiver
the test device for all VCCs. ends of the test device for all VCCs.
Reporting Format: Reporting Format:
The results of the Two-point CDV/Mixed Load/Maximum VCCs test SHOULD be The results of the Two-point CDV/Mixed Load/Maximum VCCs test
reported in a form of text, graphs, and histograms. SHOULD be reported in a form of text, graphs, and histograms.
The text results SHOULD display the numerical values of the CDV. The The text results SHOULD display the numerical values of the CDV.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
values, total number of cells transmitted and received on each VCC VPI/VCI values, total number of cells transmitted and received on
during the test in positive integers, maximum and minimum CDV on each each VCC during the test in positive integers, maximum and minimum
VCC during the test in us, and peak-to-peak CDV on each VCC in us. CDV on each VCC during the test in us, and peak-to-peak CDV on
each VCC in us.
The graph results SHOULD display the cell delay values. There will be The graph results SHOULD display the cell delay values. There
(Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
The x-coordinate SHOULD be the test run time in either seconds, minutes each graph. The x-coordinate SHOULD be the test run time in
or days depending on the total length of the test. The x-coordinate time either seconds, minutes or days depending on the total length of
SHOULD be configurable. The y-coordinate SHOULD be the cell delay for the test. The x-coordinate time SHOULD be configurable. The y-
each VCC in us. There SHOULD be no more than 10 curves on each graph, coordinate SHOULD be the cell delay for each VCC in us. There
one curve indicated and labeled for each VCC. The integration time per SHOULD be no more than 10 curves on each graph, one curve
point MUST be indicated. 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 The histograms SHOULD display the peak-to-peak cell delay. There
one histogram for each VCC. The x-coordinate SHOULD be the cell delay in will be one histogram for each VCC. The x-coordinate SHOULD be
us with at least 256 bins. The y-coordinate SHOULD be the number of the cell delay in us with at least 256 bins. The y-coordinate
cells observed in each bin. SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.2. Cell Error Ratio (CER) 3.2.2. Cell Error Ratio (CER)
3.2.2.1. Test Setup 3.2.2.1. Test Setup
The cell error ratio measurements assume that both the transmitter and The cell error ratio measurements assume that both the transmitter
receiver payload information is synchronized. Synchronization MUST be and receiver payload information is synchronized. Synchronization
achieved by supplying a known bit pattern to both the transmitter and MUST be achieved by supplying a known bit pattern to both the
receiver. If this bit pattern is longer than the packet size, the transmitter and receiver. If this bit pattern is longer than the
receiver MUST synchronize with the transmitter before tests can be run. packet size, the receiver MUST synchronize with the transmitter
before tests can be run.
3.2.2.2. CER/Steady Load/One VCC 3.2.2.2. CER/Steady Load/One VCC
Objective: To determine the SUT ratio of errored cells on one VCC in a Objective: To determine the SUT ratio of errored cells on one VCC in
transmission in relation to the total cells sent as defined in RFC 2761 a transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or contain one VPI/VCI. The VCC MUST be configured as either a CBR,
UBR connection. The VPI/VCI MUST not be one of the reserved ATM VBR, or UBR connection. The VPI/VCI MUST not be one of the
signaling channels (e.g. [0,5], [0,16]). reserved ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a constant rate through the SUT via the defined test specified bit patterns at a constant rate through the SUT via the
VCC. Since this test is not a throughput test, the rate should not be defined test VCC. Since this test is not a throughput test, the
greater than 90% of line rate. The IP PDUs MUST be encapsulated in rate should not be greater than 90% of line rate. The IP PDUs
AAL5. MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test 5) Record the number of bit errors at the receiver end of the test
device. device.
Reporting Format: Reporting Format:
The results of the CER/Steady Load/One VCC test SHOULD be reported in a The results of the CER/Steady Load/One VCC test SHOULD be reported
form of text and graph. in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The The text results SHOULD display the numerical values of the CER.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CER for the entire the given VPI/VCI during the test in positive integers, and the
test. CER for the entire test.
The graph results SHOULD display the cell error ratio values. The x- The graph results SHOULD display the cell error ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CER. The x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
integration time per point MUST be indicated. be the CER. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST be indicated. PCR, SCR, and MBS MUST be indicated. The bearer class of the
The generated bit pattern MUST also be indicated. created VCC MUST be indicated. The generated bit pattern MUST
also be indicated.
3.2.2.3. CER/Steady Load/Twelve VCCs 3.2.2.3. CER/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells on twelve VCCs in a Objective: To determine the SUT ratio of errored cells on twelve VCCs
transmission in relation to the total cells sent as defined in RFC 2761 in a transmission in relation to the total cells sent as defined in
"Terminology for ATM Benchmarking". RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR and 12 VCIs. The VCC's MUST be configured as either a CBR, VBR,
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling or UBR connection. The VPI/VCIs MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a constant rate through the SUT via the defined test specified bit patterns at a constant rate through the SUT via the
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic defined test VCCs. All of the VPI/VCI pairs will generate
rate. Since this test is not a throughput test, the rate should not be traffic at the same traffic rate. Since this test is not a
greater than 90% of line rate. The IP PDUs MUST be encapsulated in throughput test, the rate should not be greater than 90% of line
AAL5. rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test 5) Record the number of bit errors at the receiver end of the test
device for all VCCs. device for all VCCs.
Reporting Format: Reporting Format:
The results of the CER/Steady Load/Twelve VCCs test SHOULD be reported The results of the CER/Steady Load/Twelve VCCs test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The The text results SHOULD display the numerical values of the CER.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CER for the entire the given VPI/VCI during the test in positive integers, and the
test. CER for the entire test.
The graph results SHOULD display the cell error ratio values. The x- The graph results SHOULD display the cell error ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CER for each x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
VCC. There should be 12 curves on the graph, on curve indicated and be the CER for each VCC. There should be 12 curves on the graph,
labeled for each VCC. The integration time per point MUST be indicated. on curve indicated and labeled for each VCC. The integration time
per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the
generated bit pattern MUST also be indicated. created VCC MUST be indicated. The generated bit pattern MUST
also be indicated.
3.2.2.4. CER/Steady Load/Maximum VCCs 3.2.2.4. CER/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum Objective: To determine the SUT ratio of errored cells with the
number VCCs supported on the SUT in a transmission in relation to the total maximum number VCCs supported on the SUT in a transmission in
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking". relation to the total cells sent as defined in RFC 2761 "Terminology
for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with the maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The VPI. The VCC's MUST be configured as either a CBR, VBR, or UBR
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g. connection. The VPI/VCIs MUST not be one of the reserved ATM
[0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a constant rate through the SUT via the defined test specified bit patterns at a constant rate through the SUT via the
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic defined test VCCs. All of the VPI/VCI pairs will generate
rate. Since this test is not a throughput test, the rate should not be traffic at the same traffic rate. Since this test is not a
greater than 90% of line rate. The IP PDUs MUST be encapsulated in throughput test, the rate should not be greater than 90% of line
AAL5. rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test 5) Record the number of bit errors at the receiver end of the test
device for all VCCs. device for all VCCs.
Reporting Format: Reporting Format:
The results of the CER/Steady Load/Maximum VCCs test SHOULD be reported The results of the CER/Steady Load/Maximum VCCs test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The The text results SHOULD display the numerical values of the CER.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CER for the entire the given VPI/VCI during the test in positive integers, and the
test. CER for the entire test.
The graph results SHOULD display the cell error ratio values. There will The graph results SHOULD display the cell error ratio values.
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. There will be (Max number of VCCs/10) graphs, with 10 VCCs
The x-coordinate SHOULD be the test run time in either seconds, minutes indicated on each graph. The x-coordinate SHOULD be the test run
or days depending on the total length of the test. The x-coordinate time time in either seconds, minutes or days depending on the total
SHOULD be configurable. The y-coordinate SHOULD be the CER for each length of the test. The x-coordinate time SHOULD be configurable.
VCC. There SHOULD be no more than 10 curves on each graph, one curve The y-coordinate SHOULD be the CER for each VCC. There SHOULD be
indicated and labeled for each VCC. The integration time per point MUST no more than 10 curves on each graph, one curve indicated and
be indicated. labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the
generated bit pattern MUST also be indicated. created VCC MUST be indicated. The generated bit pattern MUST
also be indicated.
3.2.2.5. CER/Bursty VBR Load/One VCC 3.2.2.5. CER/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of errored cells on one VCC in a Objective: To determine the SUT ratio of errored cells on one VCC in
transmission in relation to the total cells sent as defined in RFC 2761 a transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR contain one VPI/VCI. The VCC MUST be configured as either a CBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling or VBR connection. The VPI/VCI MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and
configured using one of the specified traffic descriptors. MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a specific VBR rate through the SUT via the defined test specified bit patterns at a specific VBR rate through the SUT via
VCC. Since this test is not a throughput test, the rate should not be the defined test VCC. Since this test is not a throughput test,
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. the rate should not be greater than 90% of line rate. The IP
PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test 5) Record the number of bit errors at the receiver end of the test
device. device.
Reporting Format: Reporting Format:
The results of the CER/Bursty VBR Load/One VCC test SHOULD be reported The results of the CER/Bursty VBR Load/One VCC test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The The text results SHOULD display the numerical values of the CER.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CER for the entire the given VPI/VCI during the test in positive integers, and the
test. CER for the entire test.
The graph results SHOULD display the cell error ratio values. The x- The graph results SHOULD display the cell error ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CER. The x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
integration time per point MUST be indicated. be the CER. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the
generated bit pattern MUST also be indicated. created VCC MUST be indicated. The generated bit pattern MUST
also be indicated.
3.2.2.6. CER/Bursty VBR Load/Twelve VCCs 3.2.2.6. CER/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells on twelve VCCs in a Objective: To determine the SUT ratio of errored cells on twelve VCCs
transmission in relation to the total cells sent as defined in RFC 2761 in a transmission in relation to the total cells sent as defined in
"Terminology for ATM Benchmarking". RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection. and 12 VCIs. The VCC's MUST be configured as either a CBR or VBR
The VPI/VCIs MUST not be one of the reserved ATM signaling channels connection. The VPI/VCIs MUST not be one of the reserved ATM
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS
one of the specified traffic descriptors. must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a specific VBR rate through the SUT via the defined test specified bit patterns at a specific VBR rate through the SUT via
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic the defined test VCCs. All of the VPI/VCI pairs will generate
rate. Since this test is not a throughput test, the rate should not be traffic at the same traffic rate. Since this test is not a
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated. throughput test, the rate should not be greater than 90% of line
The IP PDUs MUST be encapsulated in AAL5. rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST
be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test 5) Record the number of bit errors at the receiver end of the test
device for all VCCs. device for all VCCs.
Reporting Format: Reporting Format:
The results of the CER/Bursty VBR Load/Twelve VCCs test SHOULD be The results of the CER/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The The text results SHOULD display the numerical values of the CER.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CER for the entire the given VPI/VCI during the test in positive integers, and the
test. CER for the entire test.
The graph results SHOULD display the cell error ratio values. The x- The graph results SHOULD display the cell error ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CER for each x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
VCC. There should be 12 curves on the graph, on curve indicated and be the CER for each VCC. There should be 12 curves on the graph,
labeled for each VCC. The integration time per point MUST be indicated. on curve indicated and labeled for each VCC. The integration time
per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the
generated bit pattern MUST also be indicated. created VCC MUST be indicated. The generated bit pattern MUST
also be indicated.
3.2.2.7. CER/Bursty VBR Load/Maximum VCCs 3.2.2.7. CER/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum Objective: To determine the SUT ratio of errored cells with the
number VCCs supported on the SUT in a transmission in relation to the total maximum number VCCs supported on the SUT in a transmission in
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking". relation to the total cells sent as defined in RFC 2761 "Terminology
for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.5. CER/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of errored cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device.
Reporting Format:
The results of the CER/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.6. CER/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.2.7. CER/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The
PCR, SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.1.8. CER/Mixed Load/Three VCC's
Objective: To determine the SUT ratio of errored cells with the three VCCs
supported on the SUT in relation to the total cells sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty Mixed Load/Three VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.1.9. CER/Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the CER/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CER for the entire
test.
The graph results SHOULD display the cell error ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CER for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.2.1.10. CER/Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of errored cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC MUST be defined as one of the Bearer classes for a total of (max VPI. The VCC's MUST be configured as either a CBR or VBR
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST connection. The VPI/VCIs MUST not be one of the reserved ATM
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS
must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns through the SUT via the defined test VCCs. Each generated specified bit patterns at a specific VBR rate through the SUT via
VCC stream MUST match the corresponding VCC Bearer class. All of the the defined test VCCs. All of the VPI/VCI pairs will generate
VPI/VCI pairs will generate traffic at the same traffic rate. Since traffic at the same traffic rate. Since this test is not a
this test is not a throughput test, the rate should not be greater than throughput test, the rate should not be greater than 90% of line
90% of line rate. The IP PDUs MUST be encapsulated in AAL5. rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of bit errors at the receiver end of the test 5) Record the number of bit errors at the receiver end of the test
device for all VCCs. device for all VCCs.
Reporting Format: Reporting Format:
The results of the CER/Bursty Mixed Load/Maximum VCCs test SHOULD be The results of the CER/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CER. The The text results SHOULD display the numerical values of the CER.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CER for the entire the given VPI/VCI during the test in positive integers, and the
test. CER for the entire test.
The graph results SHOULD display the cell error ratio values. There will The graph results SHOULD display the cell error ratio values.
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. There will be (Max number of VCCs/10) graphs, with 10 VCCs
The x-coordinate SHOULD be the test run time in either seconds, minutes indicated on each graph. The x-coordinate SHOULD be the test run
or days depending on the total length of the test. The x-coordinate time time in either seconds, minutes or days depending on the total
SHOULD be configurable. The y-coordinate SHOULD be the CER for each length of the test. The x-coordinate time SHOULD be configurable.
VCC. There SHOULD be no more than 10 curves on each graph, one curve The y-coordinate SHOULD be the CER for each VCC. There SHOULD be
indicated and labeled for each VCC. The integration time per point MUST no more than 10 curves on each graph, one curve indicated and
be indicated. labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST be indicated. The PCR, SCR, and MBS MUST be indicated. The bearer class of the
generated bit pattern MUST also be indicated. created VCC MUST be indicated. The generated bit pattern MUST
also be indicated.
3.2.3. Cell Loss Ratio (CLR) 3.2.3. Cell Loss Ratio (CLR)
3.2.3.1. CLR/Steady Load/One VCC 3.2.3.1. CLR/Steady Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761 transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional Procedure:
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 1) Set up the SUT and test device using the bi-directional
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or configuration.
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 2) Configure the SUT and test device with one VCC. The VCC SHOULD
through the SUT via the defined test VCC. Since this test is not a contain one VPI/VCI. The VCC MUST be configured as either a CBR,
throughput test, the rate should not be greater than 90% of line rate. VBR, or UBR connection. The VPI/VCI MUST not be one of the
The IP PDUs MUST be encapsulated in AAL5. reserved ATM signaling channels (e.g., [0,5], [0,16]).
4) Count the IP packets that are transmitted by the SUT to verify 3) Send a specific number of IP packets at a specific constant rate
connectivity and load. If the count on the test device is the same on through the SUT via the defined test VCC. Since this test is not
the SUT, continue the test; else lower the test device traffic rate a throughput test, the rate should not be greater than 90% of
until the counts are the same. line rate. The IP PDUs MUST be encapsulated in AAL5.
5) Record the number of cells transmitted and received on the test 4) Count the IP packets that are transmitted by the SUT to verify
device. connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device
traffic rate until the counts are the same.
Reporting Format: 5) Record the number of cells transmitted and received on the test
device.
The results of the CLR/Steady Load/One VCC test SHOULD be reported in a Reporting Format:
form of text and graph.
The text results SHOULD display the numerical values of the CLR. The The results of the CLR/Steady Load/One VCC test SHOULD be reported
values given SHOULD include: time period of test in s, test VPI/VCI in a form of text and graph.
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- The text results SHOULD display the numerical values of the CLR.
coordinate SHOULD be the test run time in either seconds, minutes or The values given SHOULD include: time period of test in s, test
days depending on the total length of the test. The x-coordinate time VPI/VCI value, total number of cells transmitted and received on
SHOULD be configurable. The y-coordinate SHOULD be the CLR. The the given VPI/VCI during the test in positive integers, and the
integration time per point MUST be indicated. CLR for the entire test.
The results MUST also indicate the packet size in octets, traffic rate The graph results SHOULD display the Cell Loss ratio values. The
in packets per second, and bearer class as generated by the test device. x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
be the CLR. The integration time per point MUST be indicated.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST The results MUST also indicate the packet size in octets, traffic
be indicated. The bearer class of the created VCC MUST also be rate in packets per second, and bearer class as generated by the
indicated. test device. The VCC and VPI/VCI values MUST be indicated. The
PCR, SCR, and MBS MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.2.3.2. CLR/Steady Load/Twelve VCCs 3.2.3.2. CLR/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a Objective: To determine the SUT ratio of lost cells on twelve VCCs in
transmission in relation to the total cells sent as defined in RFC 2761 a transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR and 12 VCIs. The VCC's MUST be configured as either a CBR, VBR,
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling or UBR connection. The VPI/VCIs MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will through the SUT via the defined test VCCs. All of the VPI/VCI
generate traffic at the same traffic rate. Since this test is not a pairs will generate traffic at the same traffic rate. Since this
throughput test, the rate should not be greater than 90% of line rate. test is not a throughput test, the rate should not be greater
The IP PDUs MUST be encapsulated in AAL5. than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the 5) Record the number of cells transmitted and received per VCC on
test device. the test device.
Reporting Format: Reporting Format:
The results of the CLR/Steady Load/Twelve VCCs test SHOULD be reported The results of the CLR/Steady Load/Twelve VCCs test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The The text results SHOULD display the numerical values of the CLR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CLR for the entire the given VPI/VCI during the test in positive integers, and the
test. CLR for the entire test.
The graph results SHOULD display the Cell Loss ratio values. The x- The graph results SHOULD display the Cell Loss ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each VCC. x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
There should be 12 curves on the graph, on curve indicated and labeled be the CLR for each VCC. There should be 12 curves on the graph,
for each VCC. The integration time per point MUST be indicated. on curve indicated and labeled for each VCC. The integration time
per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.3.3. CLR/Steady Load/Maximum VCCs 3.2.3.3. CLR/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number Objective: To determine the SUT ratio of lost cells with the maximum
VCCs supported on the SUT in a transmission in relation to the total cells number VCCs supported on the SUT in a transmission in relation to the
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". total cells sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with the maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The VPI. The VCC's MUST be configured as either a CBR, VBR, or UBR
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g. connection. The VPI/VCIs MUST not be one of the reserved ATM
[0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will through the SUT via the defined test VCCs. All of the VPI/VCI
generate traffic at the same traffic rate. Since this test is not a pairs will generate traffic at the same traffic rate. Since this
throughput test, the rate should not be greater than 90% of line rate. test is not a throughput test, the rate should not be greater
The IP PDUs MUST be encapsulated in AAL5. than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the 5) Record the number of cells transmitted and received per VCC on
test device. the test device.
Reporting Format: Reporting Format:
The results of the CLR/Steady Load/Maximum VCCs test SHOULD be reported The results of the CLR/Steady Load/Maximum VCCs test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The The text results SHOULD display the numerical values of the CLR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CLR for the entire the given VPI/VCI during the test in positive integers, and the
test. CLR for the entire test.
The graph results SHOULD display the Cell Loss ratio values. There will The graph results SHOULD display the Cell Loss ratio values.
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. There will be (Max number of VCCs/10) graphs, with 10 VCCs
The x-coordinate SHOULD be the test run time in either seconds, minutes indicated on each graph. The x-coordinate SHOULD be the test run
or days depending on the total length of the test. The x-coordinate time time in either seconds, minutes or days depending on the total
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each length of the test. The x-coordinate time SHOULD be configurable.
VCC. There SHOULD be no more than 10 curves on each graph, one curve The y-coordinate SHOULD be the CLR for each VCC. There SHOULD be
indicated and labeled for each VCC. The integration time per point MUST no more than 10 curves on each graph, one curve indicated and
be indicated. labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.3.4. CLR/Bursty VBR Load/One VCC 3.2.3.4. CLR/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761 transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR contain one VPI/VCI. The VCC MUST be configured as either a CBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling or VBR connection. The VPI/VCI MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and
configured using one of the specified traffic descriptors. MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a specific rate through the SUT via the defined test specified bit patterns at a specific rate through the SUT via the
VCC. Since this test is not a throughput test, the rate should not be defined test VCC. Since this test is not a throughput test, the
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. rate should not be greater than 90% of line rate. The IP PDUs
MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the number of cells transmitted and received on the test 5) Record the number of cells transmitted and received on the test
device. device.
Reporting Format: Reporting Format:
The results of the CLR/Bursty VBR Load/One VCC test SHOULD be reported The results of the CLR/Bursty VBR Load/One VCC test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The The text results SHOULD display the numerical values of the CLR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CLR for the entire the given VPI/VCI during the test in positive integers, and the
test. CLR for the entire test.
The graph results SHOULD display the Cell Loss ratio values. The x- The graph results SHOULD display the Cell Loss ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CLR. The x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
integration time per point MUST be indicated. be the CLR. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs 3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a Objective: To determine the SUT ratio of lost cells on twelve VCCs in
transmission in relation to the total cells sent as defined in RFC 2761 a transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC MUST be configured as either a CBR or VBR connection. and 12 VCIs. The VCC MUST be configured as either a CBR or VBR
The VPI/VCIs MUST not be one of the reserved ATM signaling channels connection. The VPI/VCIs MUST not be one of the reserved ATM
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS
one of the specified traffic descriptors. must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a specific rate through the SUT via the defined test specified bit patterns at a specific rate through the SUT via the
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic defined test VCCs. All of the VPI/VCI pairs will generate
rate. Since this test is not a throughput test, the rate should not be traffic at the same traffic rate. Since this test is not a
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated. throughput test, the rate should not be greater than 90% of line
The IP PDUs MUST be encapsulated in AAL5. rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST
be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the 5) Record the number of cells transmitted and received per VCC on
test device. the test device.
Reporting Format: Reporting Format:
The results of the CLR/Bursty VBR Load/Twelve VCCs test SHOULD be The results of the CLR/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The The text results SHOULD display the numerical values of the CLR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CLR for the entire the given VPI/VCI during the test in positive integers, and the
test. CLR for the entire test.
The graph results SHOULD display the Cell Loss ratio values. The x- The graph results SHOULD display the Cell Loss ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
VCC. There should be 12 curves on the graph, on curve indicated and be the CLR for each VCC. There should be 12 curves on the graph,
labeled for each VCC. The integration time per point MUST be indicated. on curve indicated and labeled for each VCC. The integration time
per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs 3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number Objective: To determine the SUT ratio of lost cells with the maximum
VCCs supported on the SUT in a transmission in relation to the total cells number VCCs supported on the SUT in a transmission in relation to the
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". total cells sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as either a CBR or VBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.4. CLR/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cells transmitted and received on the test
device.
Reporting Format:
The results of the CLR/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.5. CLR/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.6. CLR/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC MUST be configured as a UBR connection. The VPI/VCIs MUST not be one
of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR,
SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. There will
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph.
The x-coordinate SHOULD be the test run time in either seconds, minutes
or days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There SHOULD be no more than 10 curves on each graph, one curve
indicated and labeled for each VCC. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.4. CLR/Bursty Mixed Load/Three VCC
Objective: To determine the SUT ratio of lost cells on three VCC's in
relation to the total cells sent as defined in RFC 2761 "Terminology for
ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
MBS must be configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty Mixed Load/Three VCC test SHOULD be
reported in in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.5. CLR/Bursty Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the
test device.
Reporting Format:
The results of the CLR/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CLR for the entire
test.
The graph results SHOULD display the Cell Loss ratio values. The x-
coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.3.6. CLR/Bursty Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of lost cells with the maximum number
VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC MUST be defined as one of the Bearer classes for a total of (max VPI. The VCC MUST be configured as either a CBR or VBR
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST connection. The VPI/VCIs MUST not be one of the reserved ATM
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS
must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns through the SUT via the defined test VCCs. Each generated specified bit patterns at a specific rate through the SUT via the
VCC stream MUST match the corresponding VCC Bearer class. All of the defined test VCCs. All of the VPI/VCI pairs will generate
VPI/VCI pairs will generate traffic at the same traffic rate. Since traffic at the same traffic rate. Since this test is not a
this test is not a throughput test, the rate should not be greater than throughput test, the rate should not be greater than 90% of line
90% of line rate. The IP PDUs MUST be encapsulated in AAL5. rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cells transmitted and received per VCC on the 5) Record the number of cells transmitted and received per VCC on
test device. the test device.
Reporting Format: Reporting Format:
The results of the CLR/Bursty Mixed Load/Maximum VCCs test SHOULD be The results of the CLR/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CLR. The The text results SHOULD display the numerical values of the CLR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CLR for the entire the given VPI/VCI during the test in positive integers, and the
test. CLR for the entire test.
The graph results SHOULD display the Cell Loss ratio values. There will The graph results SHOULD display the Cell Loss ratio values.
be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each graph. There will be (Max number of VCCs/10) graphs, with 10 VCCs
The x-coordinate SHOULD be the test run time in either seconds, minutes indicated on each graph. The x-coordinate SHOULD be the test run
or days depending on the total length of the test. The x-coordinate time time in either seconds, minutes or days depending on the total
SHOULD be configurable. The y-coordinate SHOULD be the CLR for each length of the test. The x-coordinate time SHOULD be configurable.
VCC. There SHOULD be no more than 10 curves on each graph, one curve The y-coordinate SHOULD be the CLR for each VCC. There SHOULD be
indicated and labeled for each VCC. The integration time per point MUST no more than 10 curves on each graph, one curve indicated and
be indicated. labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.4. Cell Misinsertion Rate (CMR) 3.2.4. Cell Misinsertion Rate (CMR)
3.2.4.1. CMR/Steady Load/One VCC 3.2.4.1. CMR/Steady Load/One VCC
Objective: To determine the SUT ratio of cell misinsertion on one VCC in a Objective: To determine the SUT ratio of cell misinsertion on one VCC
transmission in relation to the total cells sent as defined in RFC 2761 in a transmission in relation to the total cells sent as defined in
"Terminology for ATM Benchmarking". RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC MUST be 2) Configure the SUT and test device with one VCC. The VCC MUST be
configured as either a CBR, VBR, or UBR connection. The VCC SHOULD configured as either a CBR, VBR, or UBR connection. The VCC
contain one VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
signaling channels (e.g. [0,5], [0,16]). reserved ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCC. Since this test is not a through the SUT via the defined test VCC. Since this test is not
throughput test, the rate should not be greater than 90% of line rate. a throughput test, the rate should not be greater than 90% of
The IP PDUs MUST be encapsulated in AAL5. line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of 5) Record the number of cell misinsertion errors at the receiver end
the test device. of the test device.
Reporting Format: Reporting Format:
The results of the CMR/Steady Load/One VCC test SHOULD be reported in a The results of the CMR/Steady Load/One VCC test SHOULD be reported
form of text and graph. in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The The text results SHOULD display the numerical values of the CMR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CMR for the entire the given VPI/VCI during the test in positive integers, and the
test. CMR for the entire test.
The graph results SHOULD display the Cell misinsertion rate values. The The graph results SHOULD display the Cell misinsertion rate
x-coordinate SHOULD be the test run time in either seconds, minutes or values. The x-coordinate SHOULD be the test run time in either
days depending on the total length of the test. The x-coordinate time seconds, minutes or days depending on the total length of the
SHOULD be configurable. The y-coordinate SHOULD be the CMR. The test. The x-coordinate time SHOULD be configurable. The y-
integration time per point MUST be indicated. coordinate SHOULD be the CMR. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.4.2. CMR/Steady Load/Twelve VCCs 3.2.4.2. CMR/Steady Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in Objective: To determine the SUT rate of misinserted cells on twelve
a transmission in relation to the total cells sent as defined in RFC 2761 VCCs in a transmission in relation to the total cells sent as defined
"Terminology for ATM Benchmarking". in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR and 12 VCIs. The VCC's MUST be configured as either a CBR, VBR,
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling or UBR connection. The VPI/VCIs MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will through the SUT via the defined test VCCs. All of the VPI/VCI
generate traffic at the same traffic rate. Since this test is not a pairs will generate traffic at the same traffic rate. Since this
throughput test, the rate should not be greater than 90% of line rate. test is not a throughput test, the rate should not be greater
The IP PDUs MUST be encapsulated in AAL5. than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of 5) Record the number of cell misinsertion errors at the receiver end
the test device per VCC. of the test device per VCC.
Reporting Format: Reporting Format:
The results of the CMR/Steady Load/Twelve VCCs test SHOULD be reported The results of the CMR/Steady Load/Twelve VCCs test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The The text results SHOULD display the numerical values of the CMR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CMR for the entire the given VPI/VCI during the test in positive integers, and the
test. CMR for the entire test.
The graph results SHOULD display the Cell misinsertion rate values. The The graph results SHOULD display the Cell misinsertion rate
x-coordinate SHOULD be the test run time in either seconds, minutes or values. The x-coordinate SHOULD be the test run time in either
days depending on the total length of the test. The x-coordinate time seconds, minutes or days depending on the total length of the
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each VCC. test. The x-coordinate time SHOULD be configurable. The y-
There should be 12 curves on the graph, on curve indicated and labeled coordinate SHOULD be the CMR for each VCC. There should be 12
for each VCC. The integration time per point MUST be indicated. curves on the graph, on curve indicated and labeled for each VCC.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.4.3. CMR/Steady Load/Maximum VCCs 3.2.4.3. CMR/Steady Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum Objective: To determine the SUT rate of misinserted cells with the
number VCCs supported on the SUT in a transmission in relation to the total maximum number VCCs supported on the SUT in a transmission in
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking". relation to the total cells sent as defined in RFC 2761 "Terminology
for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with the maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The VPI. The VCC's MUST be configured as either a CBR, VBR, or UBR
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g. connection. The VPI/VCIs MUST not be one of the reserved ATM
[0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will through the SUT via the defined test VCCs. All of the VPI/VCI
generate traffic at the same traffic rate. Since this test is not a pairs will generate traffic at the same traffic rate. Since this
throughput test, the rate should not be greater than 90% of line rate. test is not a throughput test, the rate should not be greater
The IP PDUs MUST be encapsulated in AAL5. than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of 5) Record the number of cell misinsertion errors at the receiver end
the test device per VCC. of the test device per VCC.
Reporting Format: Reporting Format:
The results of the CMR/Steady Load/Maximum VCCs test SHOULD be reported The results of the CMR/Steady Load/Maximum VCCs test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The The text results SHOULD display the numerical values of the CMR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CMR for the entire the given VPI/VCI during the test in positive integers, and the
test. CMR for the entire test.
The graph results SHOULD display the Cell misinsertion rate values. The graph results SHOULD display the Cell misinsertion rate
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on values. There will be (Max number of VCCs/10) graphs, with 10
each graph. The x-coordinate SHOULD be the test run time in either VCCs indicated on each graph. The x-coordinate SHOULD be the test
seconds, minutes or days depending on the total length of the test. The run time in either seconds, minutes or days depending on the total
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be length of the test. The x-coordinate time SHOULD be configurable.
the CMR for each VCC. There SHOULD be no more than 10 curves on each The y-coordinate SHOULD be the CMR for each VCC. There SHOULD be
graph, one curve indicated and labeled for each VCC. The integration no more than 10 curves on each graph, one curve indicated and
time per point MUST be indicated. labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.4.4. CMR/Bursty VBR Load/One VCC 3.2.4.4. CMR/Bursty VBR Load/One VCC
Objective: To determine the SUT rate of misinserted cells on one VCC in a Objective: To determine the SUT rate of misinserted cells on one VCC
transmission in relation to the total cells sent as defined in RFC 2761 in a transmission in relation to the total cells sent as defined in
"Terminology for ATM Benchmarking". RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR contain one VPI/VCI. The VCC MUST be configured as either a CBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling or VBR connection. The VPI/VCI MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and
configured using one of the specified traffic descriptors. MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a specific rate through the SUT via the defined test specified bit patterns at a specific rate through the SUT via the
VCC. Since this test is not a throughput test, the rate should not be defined test VCC. Since this test is not a throughput test, the
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. rate should not be greater than 90% of line rate. The IP PDUs
MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of 5) Record the number of cell misinsertion errors at the receiver end
the test device. of the test device.
Reporting Format: Reporting Format:
The results of the CMR/Bursty VBR Load/One VCC test SHOULD be reported The results of the CMR/Bursty VBR Load/One VCC test SHOULD be
in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The The text results SHOULD display the numerical values of the CMR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CMR for the entire the given VPI/VCI during the test in positive integers, and the
test. CMR for the entire test.
The graph results SHOULD display the Cell misinsertion rate values. The The graph results SHOULD display the Cell misinsertion rate
x-coordinate SHOULD be the test run time in either seconds, minutes or values. The x-coordinate SHOULD be the test run time in either
days depending on the total length of the test. The x-coordinate time seconds, minutes or days depending on the total length of the
SHOULD be configurable. The y-coordinate SHOULD be the CMR. The test. The x-coordinate time SHOULD be configurable. The y-
integration time per point MUST be indicated. coordinate SHOULD be the CMR. The integration time per point MUST
be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs 3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in Objective: To determine the SUT rate of misinserted cells on twelve
a transmission in relation to the total cells sent as defined in RFC 2761 VCCs in a transmission in relation to the total cells sent as defined
"Terminology for ATM Benchmarking". in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection. and 12 VCIs. The VCC's MUST be configured as either a CBR or VBR
The VPI/VCIs MUST not be one of the reserved ATM signaling channels connection. The VPI/VCIs MUST not be one of the reserved ATM
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS
one of the specified traffic descriptors. must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns at a specific rate through the SUT via the defined test specified bit patterns at a specific rate through the SUT via the
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic defined test VCCs. All of the VPI/VCI pairs will generate
rate. Since this test is not a throughput test, the rate should not be traffic at the same traffic rate. Since this test is not a
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated. throughput test, the rate should not be greater than 90% of line
The IP PDUs MUST be encapsulated in AAL5. rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST
be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of 5) Record the number of cell misinsertion errors at the receiver end
the test device per VCC. of the test device per VCC.
Reporting Format: Reporting Format:
The results of the CMR/Bursty VBR Load/Twelve VCCs test SHOULD be The results of the CMR/Bursty VBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The The text results SHOULD display the numerical values of the CMR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CMR for the entire the given VPI/VCI during the test in positive integers, and the
test. CMR for the entire test.
The graph results SHOULD display the Cell misinsertion rate values. The The graph results SHOULD display the Cell misinsertion rate
x-coordinate SHOULD be the test run time in either seconds, minutes or values. The x-coordinate SHOULD be the test run time in either
days depending on the total length of the test. The x-coordinate time seconds, minutes or days depending on the total length of the
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each test. The x-coordinate time SHOULD be configurable. The y-
VCC. There should be 12 curves on the graph, on curve indicated and coordinate SHOULD be the CMR for each VCC. There should be 12
labeled for each VCC. The integration time per point MUST be indicated. curves on the graph, on curve indicated and labeled for each VCC.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs 3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum Objective: To determine the SUT rate of misinserted cells with the
number VCCs supported on the SUT in a transmission in relation to the total maximum number VCCs supported on the SUT in a transmission in
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking". relation to the total cells sent as defined in RFC 2761 "Terminology
for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
each graph. The x-coordinate SHOULD be the test run time in either
seconds, minutes or days depending on the total length of the test. The
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be
the CMR for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.4. CMR/Bursty UBR Load/One VCC
Objective: To determine the SUT rate of misinserted cells on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device.
Reporting Format:
The results of the CMR/Bursty UBR Load/One VCC test SHOULD be reported
in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR. The
integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.5. CMR/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty UBR Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.6. CMR/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The
PCR, SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty UBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on
each graph. The x-coordinate SHOULD be the test run time in either
seconds, minutes or days depending on the total length of the test. The
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be
the CMR for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.4. CMR/Bursty Mixed Load/Three VCC
Objective: To determine the SUT rate of misinserted cells on three VCC's in
relation to the total cells sent as defined in RFC 2761 "Terminology for
ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
MBS must be configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device.
Reporting Format:
The results of the CMR/Bursty Mixed Load/Three VCC test SHOULD be
reported reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.5. CMR/Bursty Mixed Load/Twelve VCCs
Objective: To determine the SUT rate of misinserted cells on twelve VCCs in
a transmission in relation to the total cells sent as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of
the test device per VCC.
Reporting Format:
The results of the CMR/Bursty Mixed Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The
values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of cells transmitted and received on the given
VPI/VCI during the test in positive integers, and the CMR for the entire
test.
The graph results SHOULD display the Cell misinsertion rate values. The
x-coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CMR for each
VCC. There should be 12 curves on the graph, on curve indicated and
labeled for each VCC. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST also be
indicated.
3.2.4.6. CMR/Bursty Mixed Load/Maximum VCCs
Objective: To determine the SUT rate of misinserted cells with the maximum
number VCCs supported on the SUT in a transmission in relation to the total
cells sent as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with maximum number of VCCs 2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each supported on the SUT is 1024, define 256 VPIs with 4 VCIs per
VCC MUST be defined as one of the Bearer classes for a total of (max VPI. The VCC's MUST be configured as either a CBR or VBR
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST connection. The VPI/VCIs MUST not be one of the reserved ATM
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS
must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified 3) Send a specific number of IP packets containing one of the
bit patterns through the SUT via the defined test VCCs. Each generated specified bit patterns at a specific rate through the SUT via the
VCC stream MUST match the corresponding VCC Bearer class. All of the defined test VCCs. All of the VPI/VCI pairs will generate
VPI/VCI pairs will generate traffic at the same traffic rate. Since traffic at the same traffic rate. Since this test is not a
this test is not a throughput test, the rate should not be greater than throughput test, the rate should not be greater than 90% of line
90% of line rate. The IP PDUs MUST be encapsulated in AAL5. rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.
5) Record the number of cell misinsertion errors at the receiver end of 5) Record the number of cell misinsertion errors at the receiver end
the test device per VCC. of the test device per VCC.
Reporting Format: Reporting Format:
The results of the CMR/Bursty Mixed Load/Maximum VCCs test SHOULD be The results of the CMR/Bursty VBR Load/Maximum VCCs test SHOULD be
reported in a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CMR. The The text results SHOULD display the numerical values of the CMR.
values given SHOULD include: time period of test in s, test VPI/VCI The values given SHOULD include: time period of test in s, test
value, total number of cells transmitted and received on the given VPI/VCI value, total number of cells transmitted and received on
VPI/VCI during the test in positive integers, and the CMR for the entire the given VPI/VCI during the test in positive integers, and the
test. CMR for the entire test.
The graph results SHOULD display the Cell misinsertion rate values. The graph results SHOULD display the Cell misinsertion rate
There will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on values. There will be (Max number of VCCs/10) graphs, with 10
each graph. The x-coordinate SHOULD be the test run time in either VCCs indicated on each graph. The x-coordinate SHOULD be the test
seconds, minutes or days depending on the total length of the test. The run time in either seconds, minutes or days depending on the total
x- coordinate time SHOULD be configurable. The y-coordinate SHOULD be length of the test. The x-coordinate time SHOULD be configurable.
the CMR for each VCC. There SHOULD be no more than 10 curves on each The y-coordinate SHOULD be the CMR for each VCC. There SHOULD be
graph, one curve indicated and labeled for each VCC. The integration no more than 10 curves on each graph, one curve indicated and
time per point MUST be indicated. labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.5. CRC Error Ratio (CRC-ER) 3.2.5. CRC Error Ratio (CRC-ER)
3.2.5.1. CRC-ER/Steady Load/One VCC 3.2.5.1. CRC-ER/Steady Load/One VCC
Objective: To determine the SUT ratio of CRC errors on one VCC in a Objective: To determine the SUT ratio of CRC errors on one VCC in a
transmission in relation to the total cells sent as defined in RFC 2761 transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD 2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or contain one VPI/VCI. The VCC MUST be configured as either a CBR,
UBR connection. The VPI/VCI MUST not be one of the reserved ATM VBR, or UBR connection. The VPI/VCI MUST not be one of the
signaling channels (e.g. [0,5], [0,16]). reserved ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCC. Since this test is not a through the SUT via the defined test VCC. Since this test is not
throughput test, the rate should not be greater than 90% of line rate. a throughput test, the rate should not be greater than 90% of
The IP PDUs MUST be encapsulated in AAL5. line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify 4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on connectivity and load. If the count on the test device is the
the SUT, continue the test; else lower the test device traffic rate same on the SUT, continue the test; else lower the test device
until the counts are the same. traffic rate until the counts are the same.
5) Record the number of CRC errored cells received on the test device. 5) Record the number of CRC errored cells received on the test
device.
Reporting Format: Reporting Format:
The results of the CRC-ER/Steady Load/One VCC test SHOULD be reported in The results of the CRC-ER/Steady Load/One VCC test SHOULD be
a form of text and graph. reported in a form of text and graph.
The text results SHOULD display the numerical values of the CRC-ER. The The text results SHOULD display the numerical values of the CRC-
values given SHOULD include: time period of test in s, test VPI/VCI ER. The values given SHOULD include: time period of test in s,
value, total number of cells transmitted and received on the given test VPI/VCI value, total number of cells transmitted and received
VPI/VCI during the test in positive integers, and the CRC-ER for the on the given VPI/VCI during the test in positive integers, and the
entire test. CRC-ER for the entire test.
The graph results SHOULD display the CRC Error ratio values. The x- The graph results SHOULD display the CRC Error ratio values. The
coordinate SHOULD be the test run time in either seconds, minutes or x-coordinate SHOULD be the test run time in either seconds,
days depending on the total length of the test. The x-coordinate time minutes or days depending on the total length of the test. The
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The x-coordinate time SHOULD be configurable. The y-coordinate SHOULD
integration time per point MUST be indicated. be the CRC-ER. The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate The results MUST also indicate the packet size in octets, traffic
in packets per second, and bearer class as generated by the test device. rate in packets per second, and bearer class as generated by the
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST test device. The VCC and VPI/VCI values MUST be indicated. The
be indicated. The bearer class of the created VCC MUST also be PCR, SCR, and MBS MUST be indicated. The bearer class of the
indicated. created VCC MUST also be indicated.
3.2.5.2. CRC-ER/Steady Load/Twelve VCCs 3.2.5.2. CRC-ER/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a Objective: To determine the SUT ratio of lost cells on twelve VCCs in
transmission in relation to the total cells sent as defined in RFC 2761 a transmission in relation to the total cells sent as defined in RFC
"Terminology for ATM Benchmarking". 2761 "Terminology for ATM Benchmarking".
Procedure: Procedure:
1) Set up the SUT and test device using the bi-directional 1) Set up the SUT and test device using the bi-directional
configuration. configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and 2) Configure the SUT and test device with twelve VCCs, using 1 VPI
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR and 12 VCIs. The VCC's MUST be configured as either a CBR, VBR,
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling or UBR connection. The VPI/VCIs MUST not be one of the reserved
channels (e.g. [0,5], [0,16]). ATM signaling channels (e.g., [0,5], [0,16]).
3) Send a specific number of IP packets at a specific constant rate 3) Send a specific number of IP packets at a specific constant rate
through the SUT via the defined test VCCs. All of the VPI/VCI pairs will through the SUT via the defined test VCCs. All of the VPI/VCI
generate traffic at the same traffic rate. Since this test is not a pairs will generate traffic at the same traffic rate. Since this
throughput test, the rate should not be greater than 90% of line rate. test is not a throughput test, the rate should not be greater
The IP PDUs MUST be encapsulated in AAL5. than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to 4) Count the IP packets that are transmitted by the SUT on all VCCs
verify connectivity and load. If the count on the test device is the to verify connectivity and load. If the count on the test device
same on the SUT, continue the test; else lower the test device traffic is the same on the SUT, continue the test; else lower the test
rate until the counts are the same. device traffic rate until the counts are the same.