us.
The graph results SHOULD display the cell transfer delay values.
There will be (Max number of VCCs/10) graphs, with 10 VCCs
indicated on each graph. The x-coordinate SHOULD be the test run
time in either seconds, minutes or days depending on the total
length of the test. The x-coordinate time SHOULD be configurable.
The y-coordinate SHOULD be the cell transfer delay for each VCC in
us. There SHOULD be no more than 10 curves on each graph, one
curve indicated and labeled for each VCC. The integration time
per point MUST be indicated.
The histograms SHOULD display the cell transfer delay. There will
be one histogram for each VCC. The x-coordinate SHOULD be the
cell transfer delay in us with at least 256 bins. The y-
coordinate SHOULD be the number of cells observed in each bin.
The results MUST also indicate the packet size in octets, traffic
rate in packets per second, and bearer class as generated by the
test device. The VCC and VPI/VCI values MUST be indicated. The
PCR, SCR, and MBS MUST be indicated. The bearer class of the
created VCC MUST also be indicated.
3.3. ATM Adaptation Layer (AAL) Type 5 (AAL5)
3.3.1. IP Packet Loss due to AAL5 Re-assembly Errors
Objective: To determine if the SUT will drop IP packets due AAL5 Re-
assembly Errors as defined in RFC2761 "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
RFC2761 "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 reassembly 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.3.1. Test Setup
The AAL5 CRC error ratio measurements assume that both the
transmitter and receiver payload information is synchronized.
Synchronization MUST be achieved by supplying a known bit pattern to
both the transmitter and receiver. If this bit pattern is longer
than the packet size, the receiver MUST synchronize with the
transmitter before tests can be run.
3.3.3.2. AAL5-CRC-ER/Steady Load/One VCC
Objective: 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 RFC2761 "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.3.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 RFC2761 "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.3.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 RFC2761
"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.3.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 RFC2761 "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.3.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 RFC2761 "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.3.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 RFC2761
"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.3.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 RFC2761 "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.3.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 RFC2761 "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.3.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 RFC2761
"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 RFC2761 "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 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.2. Connection Teardown Time
Objective: To determine the Connection Teardown Time on the SUT as
defined in RFC2761 "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
RFC2761 "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 RFC2761 "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 RFC2761 "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 RFC2761 "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 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.
4. Security Considerations
As this document is solely for the purpose of providing methodology
and describes neither a protocol nor an implementation, there are no
security considerations associated with this document.
5. Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETFs procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. References
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology
for Network Interconnect Devices", RFC2544, March
1999.
[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over
ATM", RFC2225, April 1998.
[RFC2761] Dunn, J. and C. Martin, "Terminology for ATM
Benchmarking", RFC2761, February 2000.
[AF-ILMI4.0] ATM Forum Integrated Local Management Interface
Version 4.0, af-ilmi-0065.000, September 1996.
[AF-TEST-0022] Introduction to ATM Forum Test Specifications, af-
test-0022.00, December 1994.
[AF-TM4.1] ATM Forum, Traffic Management Specification Version
4.1, af-tm-0121.00, April 1996.
[AF-UNI3.1] ATM Forum, User Network Interface Specification
Version 3.1, September 1994.
[AF-UNI4.0] ATM Forum, User Network Interface Specification
Version 4.0, July 1996.
7. Authors' Addresses
Jeffrey Dunn
Advanced Network Consultants, Inc.
4214 Crest Place
Ellicott City, MD 21043, USA
Phone: +1 (410) 750-1700
EMail: Jeffrey.Dunn@worldnet.att.net
Cynthia Martin
Advanced Network Consultants, Inc.
4214 Crest Place
Ellicott City, MD 21043, USA
Phone: +1 (410) 750-1700
EMail: Cynthia.E.Martin@worldnet.att.net
Appendix A: Ranges
ATM NSAP Network Prefix.
39 0000 0000 0000 0000 0000 0000-39 0000 0000 0000 0000 0000 00FF
39 0000 0000 0000 0000 0001 0000-39 0000 0000 0000 0000 0001 00FF
39 0000 0000 0000 0001 0000 0000
39 0000 0000 0000 0002 0020 0000
39 0000 0000 0300 0002 0030 0000
39 0000 0000 4000 0002 0060 0000
39 0000 0006 0060 0002 0030 0000
39 0000 0006 0050 0002 0030 0000
39 0000 0009 0300 0002 0030 0000
39 0000 00A0 0300 0002 0030 0000
39 0000 0B00 0300 0002 0030 0000
39 0000 C000 0300 0002 0030 0000
ATM NSAP End System Identifier.
1111 1111 1111 00-1111 1111 11FF 00
2222 2222 2000 00-2222 2222 2222 00
9999 999A 0000 00-9999 999C 0000 00
Appendix B: Rates
PNNI Routing Update Size.
1) 1 PNNI routing entry update on non-aggregated addresses
2) 2 PNNI routing entry updates on non-aggregated addresses
3) 5 PNNI routing entry updates on non-aggregated addresses
4) 1 % of total available bandwidth or 1 Mb/s, whichever is less on
non- aggregated addresses
5) 1 % of total available bandwidth or 1 Mb/s, whichever is less on
of non-aggregated addresses and of aggregated addresses
6) 1 % of total available bandwidth or 1 Mb/s, whichever is less on
aggregated addresses
7) 2 % of total available bandwidth or 2 Mb/s, whichever is less on
non- aggregated addresses
8) 2 % of total available bandwidth or 2 Mb/s, whichever is less on
of non-aggregated addresses and of aggregated addresses
9) 2 % of total available bandwidth or 2 Mb/s, whichever is less on
aggregated addresses
PNNI Routing Update Repetition Interval.
Repetition Interval begins after initial PNNI routing table
stabilizes.
1) 1 update every 1 hour, for 24 hours
2) 1 update every 30 minutes, for 24 hours
3) 1 update every 5 minutes, for 1 hour
4) 1 update every 1 minute, for 15 minutes
5) 1 update every 30 seconds, for 5 minutes
6) 1 update every 30 seconds, for 1 minute
7) 1 update every 1 second, for 30 seconds
Maximum WAN Connection rates in packets per second (pps):
25.6 OC-3c OC-12c
IP Packet Size
octets/cells
44/2 30188 176603 706412
64/2 30188 176603 706412
128/3 20125 117735 470940
256/6 10062 58867 235468
1024/22 2744 16054 64216
1518/32 1886 11037 44148
2048/43 1404 8214 32856
4472/94 642 3757 15028
9180/192 314 1839 7356
Maximum LAN Connection rates in packets per second (pps):
DS-1 DS-3 E1 E3
IP Packet Size
octets/cells
44/2 1811 52133 2340 40000
64/2 1811 52133 2340 40000
128/3 1207 34755 1560 26666
256/6 603 17377 780 13333
1024/22 164 4739 212 3636
1518/32 113 3258 146 2500
2048/43 84 2424 108 1860
4472/94 38 1109 49 851
9180/192 18 543 24 416
Notes: 1. PDU size in cells is computed based on ceiling( ( PDU size
in octets + 16) / 48). This assumes an 8 octet LLC/SNAP header and
an 8 octet AAL/5 trailer.
2. Due to the number of possible configurations, IMA pps rates are
not listed, but may be derived from the following formula: floor
(IDCR/cells per packet), where cells per packet is computed as in
note 1.
3. The following cell rates were used: DS-1 = 3622 cps (using ATM TC)
E1 = 4681 cps 25.6 Mb/s = 60377 cps E3 = 80000 cps (using ATM TC)
DS-3 = 104266 cps (using ATM TC) OC-3c = 353207 cps OC-12c = 1412828
cps
Appendix C: PDU's
TCP/IP over ATM Example 1.
LLC: DSAP 0xAA (SNAP-SAP)
SSAP 0xAA (SNAP-SAP)
Control 0x03 (Unnumbered Information)
SNAP: OUI 0x00-00-00 (Ethertype)
PID 0x0800 (Internet Protocol)
IP: Version = 4
Header length = 20
Type of service = 0
000. .... Precedence = Routine(0)
...0 .... Delay = Normal (0)
.... 0... Throughput = Normal (0)
.... .0.. Reliability = Normal (0)
Packet length = 40
Id = 0
Fragmentation Info = 0x0000
.0.. .... .... .... Don't Fragment Bit = FALSE
..0. .... .... .... More Fragments Bit = FALSE
...0 0000 0000 0000 Fragment offset = 0
Time to live = 255
Protocol = TCP (6)
Header checksum = F9CF
Source address = 15.19.209.236
Destination address = 15.19.209.237
TCP: Source port = smtp (25)
Destination port = smtp (25)
Sequence number = 1
Ack number = 0
Data offset = 20