draft-ietf-bmwg-atm-method-01.txt   draft-ietf-bmwg-atm-method-02.txt 
Network Working Group J. H. Dunn Network Working Group J. H. Dunn
INTERNET-DRAFT C. E. Martin INTERNET-DRAFT C. E. Martin
Expires: September, 2000 ANC, Inc. Expires: January, 2001 ANC, Inc.
March, 2000 July, 2000
Methodology for ATM Benchmarking Methodology for ATM Benchmarking
<draft-ietf-bmwg-atm-method-01.txt> <draft-ietf-bmwg-atm-method-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 8, line 36 skipping to change at page 8, line 36
the second one changes the state to "B". The IP PDUs MUST be alternated the second one changes the state to "B". The IP PDUs MUST be alternated
during the trial. The test SHOULD verify that the SUT has properly during the trial. The test SHOULD verify that the SUT has properly
processed the routing update. processed the routing update.
2.10. Filters 2.10. Filters
Filters are added to switches to selectively inhibit the forwarding of Filters are added to switches to selectively inhibit the forwarding of
cells that would normally be forwarded. This is usually done to 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. implement filters. Filters are applicable only if the SUT supports the
filtering feature.
The SUT SHOULD be first configured to add one filter condition and the The SUT SHOULD be first configured to add one filter condition and the
tests performed. This filter SHOULD permit the forwarding of the test tests performed. This filter SHOULD permit the forwarding of the test
data stream. This filter SHOULD be of the form: data stream. This filter SHOULD be of the form as described in the SUT
Users Guide.
To be determined.
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 filters.
The first 24 of these filters SHOULD be of the form: The first 24 of these filters SHOULD be based on 24 separate ATM NSAP
Network Prefix addresses.
To be determined.
The 24 ATM addresses SHOULD not be any that are represented in the test The 24 ATM NSAP Network Prefix addresses SHOULD not be any that are
data stream. The last filter SHOULD permit the forwarding of the test represented in the test data stream. The last filter SHOULD permit the
data stream. By "first" and "last" we mean to ensure that in the second forwarding of the test data stream. By "first" and "last" we mean to
case, 25 conditions must be checked before the data IP PDUs will match ensure that in the second case, 25 conditions must be checked before the
the conditions that permit the forwarding of the IP PDU. Of course, if data IP over ATM PDUs will match the conditions that permit the
the SUT reorders the filters or does not use a linear scan of the filter forwarding of the IP PDU. Of course, if the SUT reorders the filters or
rules the effect of the sequence in which the filters are input is does not use a linear scan of the filter rules the effect of the
properly lost. 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.10.1. Filter Addresses 2.10.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
skipping to change at page 14, line 12 skipping to change at page 14, line 12
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.20. Bursty traffic 2.20. 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 load;
however, this is an unrealistic way to gauge the functioning of a SUT. however, this is an unrealistic way to gauge the functioning of a SUT.
Actual network traffic normally consists of bursts of IP PDUs. 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 constant
bit rate, bursty Unspecified Bit Rate (UBR) Best Effort [AF-TM4.0] and bit rate, bursty Unspecified Bit Rate (UBR) Best Effort [AF-TM4.1] and
Variable Bit Rate Non-real Time (VBR-nrt) Best Effort [AF-TM4.0]. The Variable Bit Rate Non-real Time (VBR-nrt) Best Effort [AF-TM4.1]. The
IP PDUs within a burst are transmitted with the minimum legitimate IP PDUs within a burst are transmitted with the minimum legitimate
inter-IP PDU gap. 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 between
bursts that the SUT can process with no IP PDU loss. Tests SHOULD be bursts that the SUT can process with no IP PDU loss. Tests SHOULD be
run with burst sizes of 10% of Maximum Burst Size (MBS), 20% of MBS, 50% run with burst sizes of 10% of Maximum Burst Size (MBS), 20% of MBS, 50%
of MBS and 100% MBS. Note that the number of IP PDUs in each burst will of MBS and 100% MBS. Note that the number of IP PDUs in each burst will
depend on the PDU size. For UBR, the MBS refers to the associated VBR depend on the PDU size. For UBR, the MBS refers to the associated VBR
traffic parameters. traffic parameters.
skipping to change at page 21, line 36 skipping to change at page 21, line 36
The results of the TOH error propagation test SHOULD be reported in a The results of the TOH error propagation test SHOULD be reported in a
form of a table. The rows SHOULD be labeled single error, one error per form of a table. The rows SHOULD be labeled single error, one error per
second, and four consecutive errors every 6 IP PDUs. The columns SHOULD second, and four consecutive errors every 6 IP PDUs. The columns SHOULD
be labeled error propagated and loss of IP PDU. The elements of the be labeled error propagated and loss of IP PDU. The elements of the
table SHOULD be either True or False, indicating whether the particular table SHOULD be either True or False, indicating whether the particular
condition was observed for each test. 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 rate
in IP PDUs per second as generated by the test device. in IP PDUs per second as generated by the test device.
3.1.2.2. Cell Loss due to 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 SUT.
skipping to change at page 56, line 16 skipping to change at page 56, line 16
be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated. generated bit pattern MUST also be indicated.
3.2.1.8. CER/Mixed Load/Three VCC's 3.2.1.8. CER/Mixed Load/Three VCC's
Objective: To determine the SUT ratio of errored cells with the maximum Objective: To determine the SUT ratio of errored cells with the three VCCs
number VCCs supported on the SUT in a transmission in relation to the total supported on the SUT in relation to the total cells sent as defined in RFC
cells sent as defined in RFC 2761 "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 three VCC's. Each VCC MUST be 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 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 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]). reserved ATM signaling channels (e.g. [0,5], [0,16]).
skipping to change at page 72, line 16 skipping to change at page 72, line 16
be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.4. CLR/Bursty Mixed Load/Three VCC 3.2.3.4. CLR/Bursty Mixed Load/Three 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 three VCC's in
transmission in relation to the total cells sent as defined in RFC 2761 relation to the total cells sent as defined in RFC 2761 "Terminology for
"Terminology for ATM Benchmarking". 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 MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each 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 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 reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
skipping to change at page 88, line 16 skipping to change at page 88, line 16
time per point MUST be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.4.4. CMR/Bursty Mixed Load/Three VCC 3.2.4.4. CMR/Bursty Mixed Load/Three 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 three VCC's in
transmission in relation to the total cells sent as defined in RFC 2761 relation to the total cells sent as defined in RFC 2761 "Terminology for
"Terminology for ATM Benchmarking". 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 MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each 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 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 reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
skipping to change at page 92, line 17 skipping to change at page 92, line 17
the CMR for each VCC. There SHOULD be no more than 10 curves on each 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 graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.5. Cell Rate Margin (CRM) 3.2.5. CRC Error Ratio (CRC-ER)
To Be Determined
3.2.3. CRC Error Ratio (CRC-ER)
3.2.3.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 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.
skipping to change at page 93, line 33 skipping to change at page 93, line 30
days depending on the total length of the test. The x-coordinate time days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The
integration time per point MUST be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.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 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 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.
skipping to change at page 95, line 5 skipping to change at page 94, line 43
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and 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. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.3. CRC-ER/Steady Load/Maximum VCCs 3.2.5.3. CRC-ER/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 number
VCCs supported on the SUT in a transmission in relation to the total cells VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 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
skipping to change at page 96, line 20 skipping to change at page 96, line 18
VCC. There SHOULD be no more than 10 curves on each graph, one curve 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 indicated and labeled for each VCC. The integration time per point MUST
be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.4. CRC-ER/Bursty VBR Load/One VCC 3.2.5.4. CRC-ER/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a 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 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.
skipping to change at page 97, line 31 skipping to change at page 97, line 29
days depending on the total length of the test. The x-coordinate time days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The
integration time per point MUST be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.5. CRC-ER/Bursty VBR Load/Twelve VCCs 3.2.5.5. CRC-ER/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a 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 transmission in relation to the total cells sent 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.
skipping to change at page 98, line 44 skipping to change at page 98, line 44
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and 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. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.6. CRC-ER/Bursty VBR Load/Maximum VCCs 3.2.5.6. CRC-ER/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 number
VCCs supported on the SUT in a transmission in relation to the total cells VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 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.
skipping to change at page 100, line 20 skipping to change at page 100, line 20
VCC. There SHOULD be no more than 10 curves on each graph, one curve 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 indicated and labeled for each VCC. The integration time per point MUST
be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.4. CRC-ER/Bursty UBR Load/One VCC 3.2.5.7. CRC-ER/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a 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 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.
skipping to change at page 101, line 31 skipping to change at page 101, line 31
days depending on the total length of the test. The x-coordinate time days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER. The
integration time per point MUST be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.5. CRC-ER/Bursty UBR Load/Twelve VCCs 3.2.5.8. CRC-ER/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a 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 transmission in relation to the total cells sent 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.
skipping to change at page 102, line 44 skipping to change at page 102, line 44
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and 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. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.6. CRC-ER/Bursty UBR Load/Maximum VCCs 3.2.5.9. CRC-ER/Bursty UBR 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 number
VCCs supported on the SUT in a transmission in relation to the total cells VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 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.
skipping to change at page 104, line 20 skipping to change at page 104, line 20
VCC. There SHOULD be no more than 10 curves on each graph, one curve 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 indicated and labeled for each VCC. The integration time per point MUST
be indicated. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.4. CRC-ER/Bursty Mixed Load/Three VCC 3.2.5.10. CRC-ER/Bursty Mixed Load/Three VCC
Objective: To determine the SUT ratio of lost cells on one VCC in a Objective: To determine the SUT ratio of lost cells on three VCC's in
transmission in relation to the total cells sent as defined in RFC 2761 relation to the total cells sent as defined in RFC 2761 "Terminology for
"Terminology for ATM Benchmarking". 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 MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each 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 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 reserved ATM signaling channels (e.g. [0,5], [0,16]). The PCR, SCR, and
skipping to change at page 105, line 33 skipping to change at page 105, line 33
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and 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. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.5. CRC-ER/Bursty Mixed Load/Twelve VCCs 3.2.5.11. CRC-ER/Bursty Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of lost cells on twelve VCCs in a 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 transmission in relation to the total cells sent 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.
skipping to change at page 107, line 5 skipping to change at page 107, line 5
SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each SHOULD be configurable. The y-coordinate SHOULD be the CRC-ER for each
VCC. There should be 12 curves on the graph, on curve indicated and 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. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.2.3.6. CRC-ER/Bursty Mixed Load/Maximum VCCs 3.2.5.12. CRC-ER/Bursty Mixed 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 number
VCCs supported on the SUT in a transmission in relation to the total cells VCCs supported on the SUT in a transmission in relation to the total cells
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 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.
skipping to change at page 125, line 31 skipping to change at page 125, line 31
histogram for each VCC. The x-coordinate SHOULD be the cell transfer histogram for each VCC. The x-coordinate SHOULD be the cell transfer
delay in us with at least 256 bins. The y-coordinate SHOULD be the delay in us with at least 256 bins. The y-coordinate SHOULD be the
number of cells observed in each bin. 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 rate
in packets per second, and bearer class as generated by the test device. 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 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 be indicated. The bearer class of the created VCC MUST also be
indicated. indicated.
3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5)
3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors
Objective: To determine if the SUT will drop IP packets due AAL5 Re-
assembly Errors as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of cells at a specific rate through the SUT.
Since this test is not a throughput test, the rate should not be greater
than 90% of line rate. The cell payload SHOULD contain valid IP PDUs.
The IP PDUs MUST be encapsulated in AAL5.
3) Count the cells that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Inject one error in the first bit of the AAL5 payload. Verify that
the SUT does not drop any AAL5 PDU's.
5) Discontinue the AAL5 payload error.
6) Inject one error in the first bit of the AAL5 header for 4
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does drop
the AAL5 PDU's.
7) Discontinue the AAL5 payload error.
Reporting Format:
The results of the AAL5 PDU Loss due to AAL5 PDU errors test SHOULD be
reported in a form of a table. The rows SHOULD be labeled single error,
one error per second, and four consecutive errors every 6 IP PDUs. The
columns SHOULD be labeled AAL5 PDU loss and number of PDU's lost. The
elements of column 1 SHOULD be either True or False, indicating whether
the particular condition was observed for each test. The elements of
column 2 SHOULD be non-negative integers.
The table MUST also indicate the traffic rate in IP PDUs per second as
generated by the test device.
3.3.2. AAL5 Reassembly Time.
Objective: To determine the SUT AAL5 Reassembly Time as defined in RFC 2761
"Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
configuration.
2) Send a specific number of IP packets at a specific rate through the
SUT. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5. The AAL5 PDU size is 65535 octets or 1365 ATM cells.
3) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
4) Given an AAL5 reassembly timer of 'x' seconds, where 'x' is the
actual value of the AAL5 reassembly timer on the SUT, sent traffic at
1365 cells per 'x' seconds. The expected results are that no AAL5 PDU's
will be dropped.
5) Send traffic at 1360 cells per 'x' seconds. The expected results are
that all AAL5 PDU's will be dropped.
Reporting Format:
The results of the IP packet loss due to AAL5 reassumbly timeout test
SHOULD be reported in a form of a table. The rows SHOULD be labeled 1365
cells per 'x' seconds and 1360 cells per 'x' seconds. The columns SHOULD
be labeled packet loss and number of packets lost. The elements of
column 1 SHOULD be either True or False, indicating whether the
particular condition was observed for each test. The elements of column
2 SHOULD be non-negative integers.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device, including the
value of
3.3.3. AAL5 CRC Error Ratio.
3.3.2.1. Test Setup
The AAL5 CRC error ratio measurements assume that both the transmitter
and receiver payload information is synchronized. Synchronization MUST
be achieved by supplying a known bit pattern to both the transmitter and
receiver. If this bit pattern is longer than the packet size, the
receiver MUST synchronize with the transmitter before tests can be run.
3.3.2.2. AAL5-CRC-ER/Steady Load/One VCC
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR, VBR, or
UBR connection. The VPI/VCI MUST not be one of the reserved ATM
signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device.
Reporting Format:
The results of the AAL5-CRC-ER/Steady Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated.
The generated bit pattern MUST also be indicated.
3.3.2.3. AAL5-CRC-ER/Steady Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR, VBR, or UBR
connection. The VPI/VCIs MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Steady Load/Twelve VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.4. AAL5-CRC-ER/Steady Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR, VBR, or UBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns at a constant rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Steady Load/Maximum VCCs test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.5. AAL5-CRC-ER/Bursty VBR Load/One VCC
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as either a CBR or VBR
connection. The VPI/VCI MUST not be one of the reserved ATM signaling
channels (e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be
configured using one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty VBR Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as either a CBR or VBR connection.
The VPI/VCIs MUST not be one of the reserved ATM signaling channels
(e.g. [0,5], [0,16]). The PCR, SCR, and MBS must be configured using
one of the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as either a CBR or VBR connection. The
VPI/VCIs MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific VBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.5. AAL5-CRC-ER/Bursty UBR Load/One VCC
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one VCC in
a transmission in relation to the total AAL5 PDU's sent as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with one VCC. The VCC SHOULD
contain one VPI/VCI. The VCC MUST be configured as a UBR connection.
The VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]). The PCR, SCR, and MBS must be configured using one of
the specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCC. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty UBR Load/One VCC test SHOULD be
reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER.
The integration time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.6. AAL5-CRC-ER/Bursty UBR Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCCs, using 1 VPI and
12 VCIs. The VCC's MUST be configured as a UBR connection. The VPI/VCIs
MUST not be one of the reserved ATM signaling channels (e.g. [0,5],
[0,16]). The PCR, SCR, and MBS must be configured using one of the
specified traffic descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The PCR, SCR, and MBS must be indicated.
The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty UBR Load/Twelve VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.2.7. AAL5-CRC-ER/Bursty UBR Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with the maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. The
VCC's MUST be configured as a UBR connection. The VPI/VCIs MUST not be
one of the reserved ATM signaling channels (e.g. [0,5], [0,16]). The
PCR, SCR, and MBS must be configured using one of the specified traffic
descriptors.
3) Send a specific number of IP packets containing one of the specified
bit patterns at a specific UBR rate through the SUT via the defined test
VCCs. All of the VPI/VCI pairs will generate traffic at the same traffic
rate. Since this test is not a throughput test, the rate should not be
greater than 90% of line rate. The IP PDUs MUST be encapsulated in
AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty UBR Load/Maximum VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.1.8. AAL5-CRC-ER/Mixed Load/Three VCC's
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on three VCC's
in a transmission in relation to the total AAL5 PDU's sent as defined in
RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with three VCC's. Each VCC MUST be
defined as a different Bearer class; one CBR, one UBR and one VBR. Each
VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the
reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT to verify
connectivity and load. If the count on the test device is the same on
the SUT, continue the test; else lower the test device traffic rate
until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty Mixed Load/Three VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.1.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors on twelve
VCC's in a transmission in relation to the total AAL5 PDU's sent as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with twelve VCC's. Each VCC MUST
be defined as one of the Bearer classes for a total of four CBR, four
UBR and four VBR VCC's. Each VCC SHOULD contain one VPI/VCI. The
VPI/VCI MUST not be one of the reserved ATM signaling channels (e.g.
[0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty Mixed Load/Twelve VCCs test SHOULD
be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. The
x- coordinate SHOULD be the test run time in either seconds, minutes or
days depending on the total length of the test. The x-coordinate time
SHOULD be configurable. The y-coordinate SHOULD be the AAL5-CRC-ER for
each VCC. There should be 12 curves on the graph, on curve indicated
and labeled for each VCC. The integration time per point MUST be
indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.3.1.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs
Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the
maximum number VCCs supported on the SUT in a transmission in relation to
the total AAL5 PDU's sent as defined in RFC 2761 "Terminology for ATM
Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Configure the SUT and test device with maximum number of VCCs
supported on the SUT. For example, if the maximum number of VCCs
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per VPI. Each
VCC MUST be defined as one of the Bearer classes for a total of (max
VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR VCC's. The VPI/VCI MUST
not be one of the reserved ATM signaling channels (e.g. [0,5], [0,16]).
3) Send a specific number of IP packets containing one of the specified
bit patterns through the SUT via the defined test VCCs. Each generated
VCC stream MUST match the corresponding VCC Bearer class. All of the
VPI/VCI pairs will generate traffic at the same traffic rate. Since
this test is not a throughput test, the rate should not be greater than
90% of line rate. The IP PDUs MUST be encapsulated in AAL5.
4) Count the IP packets that are transmitted by the SUT on all VCCs to
verify connectivity and load. If the count on the test device is the
same on the SUT, continue the test; else lower the test device traffic
rate until the counts are the same.
5) Record the number of AAL5 CRC errors at the receiver end of the test
device for all VCCs.
Reporting Format:
The results of the AAL5-CRC-ER/Bursty Mixed Load/Maximum VCCs test
SHOULD be reported in a form of text and graph.
The text results SHOULD display the numerical values of the AAL5-CRC-ER.
The values given SHOULD include: time period of test in s, test VPI/VCI
value, total number of AAL5 PDU's transmitted and received on the given
VPI/VCI during the test in positive integers, and the AAL5-CRC-ER for
the entire test.
The graph results SHOULD display the AAL5 CRC error ratio values. There
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on each
graph. The x-coordinate SHOULD be the test run time in either seconds,
minutes or days depending on the total length of the test. The x-
coordinate time SHOULD be configurable. The y-coordinate SHOULD be the
AAL5-CRC-ER for each VCC. There SHOULD be no more than 10 curves on each
graph, one curve indicated and labeled for each VCC. The integration
time per point MUST be indicated.
The results MUST also indicate the packet size in octets, traffic rate
in packets per second, and bearer class as generated by the test device.
The VCC and VPI/VCI values MUST be indicated. The PCR, SCR, and MBS MUST
be indicated. The bearer class of the created VCC MUST be indicated. The
generated bit pattern MUST also be indicated.
3.4. ATM Service: Signaling
3.4.1. CAC Denial Time and Connection Establishment Time
Objective: To determine the CAC rejection time and Connection Establishment
Time on the SUT as defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will not allow CAC to reject the call.
3) Send the UNI signaling setup message. Note the time the setup message
was sent. Verify that the SVC has been setup with the correct
parameters. Note the time the connect message was received
4) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will allow CAC to reject the call.
5) Send the UNI signaling setup message. Note the time the setup
message was sent. Verify that the SVC has been rejected with the
correct cause code. Note the time the release complete message was
received.
6) Compute the rejection time as the difference between the time the
release complete message was received and the time setup message was
send.
Reporting Format:
The results of the CAC Denial Time and Connection Establishment Time
tests SHOULD be reported in a form of a table. The rows SHOULD be
labeled call accepted and call rejected. The columns SHOULD be labeled
time setup sent, time response recieved, and correct response. The
elements of the columns 1 and 2 SHOULD be in seconds. The elements of
column 3 SHOULD be be either True or False, indicating whether the
particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.4.2. Connection Teardown Time
Objective: To determine the Connection Teardown Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will not allow CAC to reject the call.
3) Send the UNI signaling setup message. Note the time the setup message
was sent. Verify that the SVC has been setup with the correct
parameters. Note the time the connect message was received
4) Create a UNI signaling release message, as described in Appendix C,
specifying a cause code of normal call clearing.
5) Send the UNI signaling release message. Note the time the release
message was sent. Verify that the SVC has been terminated with the
correct cause code. Note the time the release complete message was
received.
6) Compute the release time as the difference between the time the
release complete message was received and the time release message was
send.
Reporting Format:
The results of the Connection Teardown Time tests SHOULD be reported in
a form of a table. The rows SHOULD be labeled call accepted and call
released. The columns SHOULD be labeled time message sent, time response
received, and correct response. The elements of the columns 1 and 2
SHOULD be in seconds. The elements of column 3 SHOULD be be either True
or False, indicating whether the particular condition was observed for
each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.4.3. Crankback Time
Objective: To determine the Crankback Time on the SUT as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional passthrough
configuration.
2) Create a PNNI signaling setup message, as described in Appendix C,
specifying a DTL which is not blocked by the far end SUT.
3) Send the PNNI signaling setup message. Note the time the setup
message was sent. Verify that the connect message has been received by
the near- end switch. Note the time the connect message was received
4) Create a PNNI signaling setup message, as described in Appendix C,
specifying a DTL which is blocked by the far end SUT.
5) Send the PNNI signaling release message. Note the time the release
message was sent. Note the time the release complete message was
received. Note the time the near-end switch sends it's own PNNI setup
message (referred to as the near-end setup message) specifying the non-
blocked DTL.
6) Compute the crankback time as the difference between the time the
near- end setup message was received and the time release message was
send.
Reporting Format:
The results of the Crankback Time tests SHOULD be reported in a form of
a table. The rows SHOULD be labeled DTL call accepted and call released.
The columns SHOULD be labeled time message sent, time response received,
and correct response. The elements of the columns 1 and 2 SHOULD be in
seconds. The elements of column 3 SHOULD be be either True or False,
indicating whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.4.4. Route Update Response Time
Objective: To determine the Route Update Response Time on the SUT as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional passthrough
configuration.
2) Create a PNNI PTSE as described in Appendix C, specifying a routing
topology. Verify that the routing tables on the far-end and near-end
switches are empty.
3) Send the PTSE message to the far-end switch. Note the time the PTSE
message was sent. Verify that the PTSE message has been received by the
far-end switch. Note the time the PTSE message was received.
4) Create another PNNI PTSE as described in Appendix C, specifying a
change in the routing topology. Verify that the routing tables on the
far-end and near-end switches contain the previous PTSE routes.
5) Send the PTSE message to the far-end switch. Note the time the PTSE
message was sent. Verify that the PTSE message has been received by the
far-end switch. Note the time the PTSE message was received. Note the
time the PTSE was sent to the near-end switch. Note the time the PTSE
message was received on the near-end switch.
6) Compute the Route Update Response time as the difference between the
time the far-end PTSE message was sent and the time far-end PTSE message
was received by the near-end.
Reporting Format:
The results of the Route Update Response Time tests SHOULD be reported
in a form of a table. The rows SHOULD be labeled PTSE call accepted,
far-end PTSE message send, and near-end message received. The columns
SHOULD be labeled time message sent, time response received, and correct
response. The elements of the columns 1 and 2 SHOULD be in seconds.
The elements of column 3 SHOULD be be either True or False, indicating
whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.5. ATM Service: ILMI
3.5.1. MIB Alignment Time
Objective: To determine the MIB Alignment Time on the SUT as defined in RFC
2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Send a Cold Start message to the SUT. Note the time the message was
sent to the SUT. Verify that the Cold Start message has been received
by the SUT. Note the time the message was received.
3) Send a Get Request message to the SUT. Note the time the message was
sent to the SUT. Verify that the Get Request message has been received
by the SUT. Note the time the message was received.
4) After all MIB elements are exchanged, verify that the final Get
Request message has been received by the SUT. Note the time the message
was send and received by the SUT.
5) Compute the MIB Alignment Time as the difference between the time the
Cold Start message was sent and the time the final Get Request was
received by the SUT.
Reporting Format:
The results of the MIB Alignment Time tests SHOULD be reported in a form
of a table. The rows SHOULD be labeled Cold Start Send, Cold Start
accepted, Final Get Request send, and Final Get Request received. The
columns SHOULD be labeled time message sent, time response received, and
correct response. The elements of the columns 1 and 2 SHOULD be in
seconds. The elements of column 3 SHOULD be be either True or False,
indicating whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
3.5.2. Address Registration Time
Objective: To determine the Address Registration Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Send a Set Request message to the SUT. Note the time the message was
sent to the SUT. Verify that the Set Request message has been received
by the SUT. Note the time the message was received.
3) Send a Get Request message to the SUT. Note the time the message was
sent to the SUT. Verify that the Get Request message has been received
by the SUT. Note the time the message was received.
4) After all MIB elements are exchanged, verify that the final Get
Request message has been received by the SUT. Note the time the message
was send and received by the SUT.
5) Compute the Address Registration Time as the difference between the
time the Set Request message was sent and the time the final Get Request
was received by the SUT.
Reporting Format:
The results of the Address Registration Time tests SHOULD be reported in
a form of a table. The rows SHOULD be labeled Set Request Send, Set
Request saccepted, Final Get Request send, and Final Get Request
received. The columns SHOULD be labeled time message sent, time response
received, and correct response. The elements of the columns 1 and 2
SHOULD be in seconds. The elements of column 3 SHOULD be be either True
or False, indicating whether the particular condition was observed for
each test.
The table MUST also indicate the packet size in octets and traffic rate
in packets per second as generated by the test device.
4. Security Considerations. 4. Security Considerations.
As this document is solely for the purpose of providing methodology and As this document is solely for the purpose of providing methodology and
describes neither a protocol nor an implementation, there are no describes neither a protocol nor an implementation, there are no
security considerations associated with this document. security considerations associated with this document.
5. Notices 5. Notices
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
skipping to change at page 127, line 18 skipping to change at page 152, line 5
[IETF-RFC-2761] IETF RFC 2761 "Terminology for ATM Benchmarking" Draft, [IETF-RFC-2761] IETF RFC 2761 "Terminology for ATM Benchmarking" Draft,
2000. 2000.
[AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version [AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version
4.0, af-ilmi-0065.000, September 1996. 4.0, af-ilmi-0065.000, September 1996.
[AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-test- [AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-test-
0022.00, December 1994. 0022.00, December 1994.
[AF-TM4.0] ATM Forum, Traffic Management Specification Version 4.0, af- [AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1, af-
tm- 0056.00, April 1996. tm- 0121.00, April 1996.
[AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1,
September 1994. September 1994.
[AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0,
July 1996. July 1996.
8. Editor's Addresses 8. Editor's Addresses
Jeffrey Dunn Jeffrey Dunn
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/