| draft-bidulock-sigtran-m2pa-test-06Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-m2pa-test-06.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
October 16, 2005
Expires in April 2006
SS7 MTP2-User Peer-to-Peer Adaptation Layer
Test Specifications
M2PA-TEST
<draft-bidulock-sigtran-m2pa-test-06.txt>
Status of this Memo
"By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79."
This document may not be modified, and derivative works of it may
not be created, except to publish it as an RFC and to translate it
into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in April 2006.
Copyright
Copyright (C) The Internet Society (2005).
Abstract
This Internet Draft provides information for the Internet community
on test cases for testing the SS7 MTP2-User Peer-to-Peer Adaptation
Layer [M2PA] based on the conformance test specifications for SS7 MTP
Level 2 [Q.781].
B. Bidulock Version 0.6 Page 1
Internet Draft M2PA-TEST October 16, 2005
This memo describes the test environment and a detailed description
of test cases for validation, compatibility and interoperability
testing of the M2PA protocol implemented on the foundation of ITU SS7
MTP Signalling Links [Q.703].
Contents
A complete table of contents, list of illustrations, list of tables
and change history for this document appears at the end of the
document.
1. Introduction
This draft provides a set of detailed tests of the SS7 MTP2-User
Peer-to-Peer Adaptation Layer [M2PA] based on the test specifications
for SS7 MTP Level 2 [Q.781]. These tests are intended to validate the
SS7 MTP2-User Peer-to-Peer Adaptation Layer (M2PA) protocol [M2PA].
These tests attempt to completely validate the M2PA protocol without
redundancy. Each test is described as simply as possible to check
precisely the elementary function of the protocol. The tests are
listed in no specific order[1].
1.1. Scope
Although the SS7 MTP Level 2 Test Specification [Q.781] is largely
applicable to SS7 signalling links using the SS7 MTP2-User Peer-to-
Peer Adaptation Layer [M2PA], those test cases describe messages and
some sequences that are not applicable to M2PA. This document
describes a set of Validation and Compatibility tests that are
consistent with the SS7 MTP Level 2 Test Specification [Q.781], but
which are applicable to M2PA.
The Test Environment used for M2PA testing described in this
document is largely compatible with the SS7 Test Specifications
[Q.780].
M2PA [M2PA] provides that, unless modified by the M2PA specification
[M2PA], that the procedures of the applicable MTP Level 2 standard are
to be used. This includes ITU [Q.703], ANSI [T1.111], ETSI [EN 300
008-1], TTC [JT-Q.703], and other narrow band specifications as well
as broadband specifications for ITU [Q.2140], ANSI [T1.637], and
others. This document describes testing of the procedures applicable
to ITU signalling links [Q.781, Q.703] only. Some other testing
methodologies applicable to ANSI [T1.111] or ETSI [ETS 300 336],
although similar, are outside the scope of this document.
1.2. Terminology
This document extends the terminology of M2PA [M2PA] with the
following terms:
Compatibility Test (CPT) -- A test where multiple implementations are
tested in interaction with each other to test for compatibility
B. Bidulock Version 0.6 Page 2
Internet Draft M2PA-TEST October 16, 2005
between implementations.
Implementation Under Test (IUT) -- An implementation being tested (the
object of testing) as part of a Validation Test or a Compatibility
Test within the Test Environment.
Interoperability Test (IOT) -- A test where multiple implementations
are tested in interaction with each other to test for
interoperability between implementations.
M2PA Monitor -- A device or function used to monitor, capture, record
and analyze the exchange of M2PA messages across an IP network
between implementations or protocol testers. This device or
function may be integrated with a Protocol Tester.
MTP Level 3 Simulator -- A device or function used to simulate the SS7
MTP Level 3 [Q.704] to SS7 MTP Level 2 [Q.703] implementation.
This device or function may be integrated within the Test
Environment. This device or function is normally required for SS7
MTP Level 2 Test Specification [Q.781] Validation as well as
Compatibility tests.
Protocol Tester (PT) -- A device or function used to generate normal
or abnormal messages and test sequences for the purpose of
Validation testing.
Test Case -- A particular sequence of messages and patterns that make
up a single Validation or Compatibility test.
Test Environment -- The environment that contains testing device and
functions necessary and sufficient for executing a Test Suite.
Test Suite -- A collection of Test Cases meant to achieve a specific
objective of Validation or Compatibility testing.
Validation Test (VAT) -- A test where a single implementation is
tested in interaction with a Protocol Tester to test for
validation of the implementation to a technical specification.
1.3. Abbreviations
ASP -- Application Server Process
CPT -- Compatibility Test
IOT -- Interoperability Test
IPSP -- IP Signalling Point
IUT -- Implementation Under Test
PT -- Protocol Tester
SG -- Signalling Gateway
SGP -- Signalling Gateway Process
SP -- Signalling Point
VAT -- Validation Test
B. Bidulock Version 0.6 Page 3
Internet Draft M2PA-TEST October 16, 2005
1.4. Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when they appear in this document, are to be interpreted
as described in [RFC 2119].
This test specification is not a replacement for or extension of the
SS7 MTP2-User Peer-to-Peer Adaptation Layer protocol specification
[M2PA]. Where this document and the requirements or recommendations
of the SS7 MTP2-User Peer-to-Peer Adaptation Layer protocol
specification [M2PA] disagree, the requirements and recommendations of
the SS7 MTP2-User Peer-to-Peer Adaptation Layer protocol specification
[M2PA] shall be taken as authoritative.
Notes for Section 1
[1] IMPLEMENTATION NOTE:-- An implementation of M2PA which conforms
to these test specifications and a test program which executes
the validation portion of these tests on that implementation
are available from http://www.openss7.org/downloads.html
2. Test Environment
The test environment for SS7 MTP Level 2 [Q.781] testing is
described in the General Aspects of SS7 Testing [Q.780]. There are
three types of testing that are accommodated as follows:
Validation Testing -- consists of validating a single Implementation
Under Test (IUT). This is performed by connecting the IUT to a
Protocol Tester (PT) within the test environment.
Validation testing is more extensive than compatibility testing.
This is because it is possible, with the use of the PT, to
generate abnormal messages and patterns that cannot normally be
generated from an implementation. These tests validate the
response of the IUT to abnormal (as well as normal) conditions.
Compatibility Testing -- consists of testing the compatibility of one
Implementation Under Test (IUT) with another. This is performed
by connecting the IUT together within the test environment.
Compatibility testing is less extensive than validation testing.
This is because it is not normally possible to generate abnormal
test patterns or generate negative test cases with an
implementation that conforms to validation testing. However,
compatibility tests are better at testing the interoperability of
two implementations.
Interoperability Testing -- consists of testing the interoperability
of one Implementation Under Test (IUT) with another. This is
performed by connecting the IUT together within the test
environment.
B. Bidulock Version 0.6 Page 4
Internet Draft M2PA-TEST October 16, 2005
Interoperability testing is more extensive than compatibility
testing and less extensive than validation testing. Where
compatibility testing assumes that the IUT have passed validation
testing, interoperability testing makes no such assumption. In
addition, the test environment is expected to have more control
over the IUT in interoperability testing than in compatibility
testing. It may be possible to generate some message and command
or response sequences that would not normally by possible with an
IUT during compatibility testing.
The objectives of interoperability testing are often different
than compatibility testing. The object of compatibility testing
is to assure that an implementation that passes validation
testing is, in other respects not tested by validation testing,
compatible with other such implementations. The object of
interoperability testing is to show that there exist
implementations with which each of the IUT being tested can
indeed function.
Although they have different objectives, the test environment
configuration for interoperability testing is the same as that
for compatibility testing.
This document uses the test environment described in the SS7 Test
Specification [Q.780].
2.1. Test Configurations
This section details the Validation and Compatibility test
configurations used for testing M2PA for SS7 MTP Level 2 [Q.781]
conformance.
2.1.1. Validation Test Configuration
B. Bidulock Version 0.6 Page 5
Internet Draft M2PA-TEST October 16, 2005
___________________________________________________________________
| |
| TEST ENVIRONMENT |
| MTP Level 3 |
| Simulator |
| : |
| _________ ____:____ |
| | | M2PA Link | | |
| | PT |______________________________| IUT | |
| | | | | | |
| |_________| | SCTP |_________| |
| | Association |
| SP B ____|____ SP A |
| | | |
| | M2PA | |
| | Monitor | |
| |_________| |
| |
|___________________________________________________________________|
Figure 2.1.1-1. Validation Test Configuration
Figure 2.1.1-1 illustrates the Validation Test Configuration. The
Validation Test environment contains the following essential
components:
(1) Implementation Under Test (IUT) -- An implementation for
validation testing acting as "SP A".
(2) Protocol Tester (PT) -- A protocol testing device acting as "SP
B".
(3) MTP Level 3 Simulator -- A simulation device or function used
to issue commands and collect response to and from the SS7
MTP2-User Peer-to-Peer Adaptation Layer [M2PA] implementation
at position "SP A".
(4) M2PA Monitor -- A device or function used to monitor, capture,
record and analyze the exchange of M2PA messages between the PT
and IUT across the IP network in SCTP associations.
(5) IP Network -- An intervening IP network used to form SCTP
associations between PT and IUT and to exchange messages.
(6) SCTP Associations -- An single SCTP connection formed between
the PT and IUT for the exchange of M2PA messages.
For this configuration, the interface between the Implementation
Under Test (IUT) and the MTP Level 3 Simulator is that described in
the SS7 Test Specification [Q.780]. This is the normal configuration
for SS7 MTP Level 2 testing [Q.781] with the exception that an M2PA
[M2PA] signalling link has been interposed for an SS7 signalling link
[Q.703].
B. Bidulock Version 0.6 Page 6
Internet Draft M2PA-TEST October 16, 2005
All test cases in this document should be executed when performing
Validation testing.
2.1.2. Compatibility Test Configuration
___________________________________________________________________
| |
| TEST ENVIRONMENT |
| |
| MTP Level 3 MTP Level 3 |
| Simulator Simulator |
| : : |
| ____:____ ____:____ |
| | | M2PA Link | | |
| | IUT |______________________________| IUT | |
| | | | | | |
| |_________| | SCTP |_________| |
| | Association |
| SP B ____|____ SP A |
| | | |
| | M2PA | |
| | Monitor | |
| |_________| |
| |
|___________________________________________________________________|
Figure 2.1.2-1. Compatibility Test Configuration
Figure 2.1.2-1 illustrates the Compatibility Test Configuration.
The Compatibility Test environment contains the following essential
components:
(1) Implementation Under Test (IUT) -- An implementation for
compatibility testing acting as "SP A".
(2) Implementation Under Test (IUT) -- An implementation for
compatibility testing acting as "SP B".
(3) MTP Level 3 Simulator -- A simulation device or function used
to issue commands and collect responses to and from the SS7
MTP2-User Peer-to-Peer Adaptation Layer [M2PA] implementation
at position "SP A".
(4) MTP Level 3 Simulator -- A simulation device or function used
to issue commands and collect responses to and from the SS7
MTP2-User Peer-to-Peer Adaptation Layer [M2PA] implementation
at position "SP B".
(5) M2PA Monitor -- A device or function used to monitor, capture,
record and analyze the exchange of M2PA messages between the
IUT across the IP network in SCTP associations.
B. Bidulock Version 0.6 Page 7
Internet Draft M2PA-TEST October 16, 2005
(6) IP Network -- An intervening IP network used to form SCTP
associations between IUT and to exchange messages.
(7) SCTP Associations -- A single SCTP connection formed between
IUT for the exchange of M2PA messages.
For this configuration, the interface between each Implementation
Under Test (IUT) and the MTP Level 3 Simulator is that described in
the SS7 Test Specifications [Q.780]. Tihs is the normal configuration
to SS7 MTP Level 2 testing [Q.781] with the exception that an M2PA
[M2PA] signalling link has been interposed for an SS7 signalling link
[Q.703].
Only select test case apply to Compatibility testing in accordance
with the SS7 MTP Level 2 Test Specification [Q.781].
2.1.3. Interoperability Test Configuration
The interoperability test configuration closely resembles that for
compatibility testing as illustrated in Figure 2.1.2-1, above, with
the exception that the MTP Level 3 Simulator typically has more
capabilities for controlling the implementation during testing. For
example, the MTP Level 3 Simulator can in some instances be capable of
closely controlling the sequence of messages generated by the
implementation and may even be able to inject or withhold messages
during testing.
2.2. Testing Methodology
The normal methodology for testing SS7 MTP Level 2 [Q.781] is to
perform Validation testing on an IUT before performing Compatibility
testing. The tests presented in this document test functionality the
the M2PA MTP Level 2 state machines; however, they do not adequately
test the M2PA L2 to L3 interface.
To complete Validation and Compatibility testing of M2PA, the
Validation and Compatibility tests present in the SS7 MTP Level 3 Test
Specification [Q.782] SHOULD be performed with M2PA links in the test
environment to assure that the M2PA IUT has properly implemented the
L2 to L3 interface.
2.3. Recommended IUT Settings
The following settings are recommended[1] for use with both
Validation and Compatibility testing, in the absence of other
recommended values to be adopted by the PT and IUT.
2.3.1. Timer Values
It is recommended[1] that the timer values listed in Table 2.3.1-1
be configured at the IUT for the purposes of performing both
validation and compatibility tests.
Internet Draft M2PA-TEST October 16, 2005
Table 2.3.1-1. Recommended[1] IUT Timer Values
Timer Value Units Notes
-------------------------------------------
T1 45 seconds
T2 5 seconds
T2l 20 seconds (not applicable)
T2h 100 seconds (not applicable)
T3 1 seconds
T4n 8 seconds
T4e 0.5 seconds
T5 0.1 seconds (not applicable)
T6 4 seconds
T7 1 seconds
T8 0.1 seconds (not applicable)
-------------------------------------------
2.3.2. Buffer Threshold Values
It is recommended that the buffer threshold values listed in Table
2.3.2-1 be configured at the IUT for the purpose of performing both
validation and compatibility tests.
Table 2.3.2-1. Recommended IUT Buffer Threshold Values
Threshold Value Units Notes
------------------------------------------------
N1 -- Octets (not applicable)
N2 127 Messages
2.3.3. MSU Length
It is illustrated that all normal User Data messages which are sent
have a payload length of 35 bytes. This, however, is not essential to
the correct performance of the tests and is an arbitrary choice. Use
of different valid MSU lengths should not have an affect on the
results.
2.3.4. Labeling of Messages and Primitives
The messages and primitives (requests and indications between M2PA
and MTP3) in the test cases that follow are labeled as listed in Table
2.3.4-1. All tests are labeled with "VAT:", "CPT:" or "IOT",
indicating that the test is applicable to Validation, Compatibility or
Interoperability forms of testing.
B. Bidulock Version 0.6 Page 9
Internet Draft M2PA-TEST October 16, 2005
Table 2.3.4-1. Labeling of Messages and Primitives
Label Link Status Message
-------------------------------------------------------------------
BUSY Busy
BUSY-ENDED Busy Ended
PROCESSOR-OUTAGE Processor Outage
PROCESSOR-RECOVERED Processor Recovered
OUT-OF-SERVICE Out of Service
READY Ready
PROVING-NORMAL Proving Normal
PROVING-EMERGENCY Proving Emergency
ALIGNMENT Alignment
Label User Data Message
-------------------------------------------------------------------
DATA (non-zero length)
DATA-ACK (zero-length)
Label Invalid Messages
-------------------------------------------------------------------
[INVALID-STATUS] (Link Status Message with an invalid status
value or an invalid length.)
[INVALID-CLASS] (M2PA Message with Invalid Message Class.)
[INVALID-TYPE] (M2PA Message with Invalid Message Type.)
Label Request Primitive
-------------------------------------------------------------------
:start AAL-START-request
:msu AAL-MESSAGE_FOR_TRANSMISSION-request
:clear buffers AAL-FLUSH_BUFFERS-request
:stop AAL-STOP-request
:set emergency AAL-EMERGENCY-request
:clear emergency AAL-EMERGENCY-CEASES-request
:set lpo MAAL-LOCAL_PROCESSOR_OUTAGE-request
:clear lpo MAAL-LOCAL_PROCESSOR_RECOVERED-request
:power on (form SCTP association)
:tx break (abort SCTP association)
:make cong discard (receive discard congestion)
:clear congestion (receive congestion abatement)
Label Indication Primitive
-------------------------------------------------------------------
!in service AAL-IN_SERVICE-indication
!msu AAL-RECEIVED_MESSAGE-indication
!out of service AAL-OUT_OF_SERVICE-indication
!rpo (remote processor outage indication)
!rpr (remote processor receovered indication)
B. Bidulock Version 0.6 Page 10
Internet Draft M2PA-TEST October 16, 2005
2.3.5. Labeling of Sequence Numbers
Messages containing significant sequence numbers have the sequence
numbered labeled in the test diagram. An example is illustrated
below.
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :msu |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| BSN FSN |
| |
| DATA-ACK --FFFFFF, 000000-> |
| FSN BSN |
| |
| <-FFFFFF, 000001-- DATA [ 35 bytes] |
| BSN FSN |
| :set lpo |
| [ 35 bytes] DATA --000000, 000000-> |
| FSN BSN |
| |
| <----------------- PROCESSOR-OUTAGE |
| DATA-ACK --000000, 000001-> |
| FSN BSN |
| :clear buffers |
| :clear lpo |
| :msu |
| <-FFFFFF, 000001-- PROCESSOR-RECOVERED |
| BSN FSN |
| |
| READY --FFFFFF, 000001-> |
| FSN BSN |
| :msu |
| <-FFFFFF, 000002-- DATA [ 35 bytes] |
| BSN FSN |
| |
| DATA-ACK --FFFFFF, 000002-> |
| FSN BSN |
| |
|___________________________________________________________________|
Figure 2.3.5-0 illustrates the labeling of sequence numbers. The
Forward Sequence Number (FSN) is always labeled closest to the SP
originating the message. The Backward Sequence Number (BSN) is always
labeled closest to the SP receiving the message.
B. Bidulock Version 0.6 Page 11
Internet Draft M2PA-TEST October 16, 2005
Notes for Section 2
[1] IMPLEMENTATION NOTE:-- The values are recommended to facilitate
testing only, and do no represent a recommendation for
operational networks. Operational values must be determined
considering the needs of the operational network in which M2PA
must function.
3. Tests
The M2PA Validation ("VAT") and Compatibility ("CPT") tests cases
are detailed in the sections that follow. All tests cases that are
applicable to M2PA are applicable to Validation testing. Selected
test cases (marked as "CPT" in Table 3-1) are applicable to M2PA
Compatibility testing. Interoperability testing at an IETF
interoperability event may include some additional Validation tests in
Interoperability testing, depending on the capabilities of the MTP
Level 3 Simulator. These additional tests have been marked "IOT" in
Table 3-1.
Table 3-1. Test Case Applicability
No. Title VAT CPT IOT
----------------------------------------------------------------------
3.1.1 Initialization (Power-up) VAT CPT IOT
3.1.2 Timer T2 VAT CPT IOT
3.1.3 Timer T3 VAT - -
3.1.4 Timer T1 & Timer T4 (Normal) VAT - -
3.1.5 Normal alignment procedure VAT CPT IOT
3.1.6 Normal alignment procedure VAT - -
- correct procedure (Data)
3.1.7 Status "Alignment" received VAT - -
during normal proving period
3.1.8 Normal alignment with PO set VAT - IOT
3.1.9 Normal alignment with PO set (Data) VAT - IOT
3.1.10 Normal alignment with PO set and cleared VAT - IOT
3.1.11 Set RPO when "Aligned not ready" VAT - -
3.1.12 Status "Out of Service" received VAT - -
when "Aligned not ready"
3.1.13 Status "Alignment" received VAT - -
when "Aligned not ready"
3.1.14 Set and clear LPO VAT - IOT
when "Initial alignment"
3.1.15 Set and clear LPO VAT - -
when "Aligned ready"
3.1.16 Timer T1 in "Aligned not ready" state VAT - IOT
3.1.17 No status "Alignment" sent VAT - -
during normal proving period
3.1.18 Set and cease emergency VAT - -
prior to "start alignment"
B. Bidulock Version 0.6 Page 12
Internet Draft M2PA-TEST October 16, 2005
No. Title VAT CPT IOT
----------------------------------------------------------------------
3.1.19 Set emergency while in "not aligned" state VAT CPT IOT
3.1.20 Set emergency when "aligned" VAT - IOT
3.1.21 Both ends set emergency. VAT - IOT
3.1.22 Individual end sets emergency VAT - IOT
3.1.23 Set emergency during normal proving VAT - IOT
3.1.24 No status "Alignment" sent VAT - -
during emergency alignment
3.1.25 Deactivation during initial alignment VAT CPT IOT
3.1.26 Deactivation during aligned state VAT - -
3.1.27 Deactivation during aligned not ready VAT - IOT
3.1.28 Status "alignment" received VAT - -
during link in service
3.1.29 Status "out of service" received VAT CPT IOT
during link in service
3.1.30 Deactivation during LPO VAT - IOT
3.1.31 Deactivation during RPO VAT - IOT
3.1.32 Deactivation during the proving period VAT CPT IOT
3.1.33 Status "Alignment" received VAT - -
instead of status "Ready"
3.1.34 Status "Out of Service" received VAT - -
instead of status "Ready"
3.1.35 Status "Processor Outage" received VAT - IOT
instead of status "Ready"
3.2.1 Unexpected signal units/orders VAT - -
in "Out of service" state
3.2.2 Unexpected signal units/orders VAT - -
in "Not Aligned" state
3.2.3 Unexpected signal units/orders VAT - -
in "Aligned" state
3.2.4 Unexpected signal units/orders VAT - -
in "Proving" state
3.2.5 Unexpected signal units/orders VAT - -
in "Aligned Ready" state
3.2.6 Unexpected signal units/orders VAT - -
in "Aligned Not Ready" state
3.2.7 Unexpected signal units/orders VAT - -
in "In Service" state
3.2.8 Unexpected signal units/orders VAT - -
in "Processor Outage" state
3.3.1 Link aligned ready (Abort) VAT - -
3.3.2 Link aligned ready (Corrupt FIBs) - - -
3.3.3 Link aligned not ready (Abort) VAT - -
3.3.4 Link aligned not ready (Corrupt FIBs) - - -
3.3.5 Link in service (Abort) VAT CPT IOT
3.3.6 Link in service (Corrupt FIBs) - - -
3.3.7 Link in processor outage (Abort) VAT - IOT
3.3.8 Link in processor outage (Corrupt FIBs) - - -
3.4.1 Set and clear LPO while link in service VAT - IOT
3.4.2 RPO during LPO VAT - IOT
3.4.3 Clear LPO when "Both processor outage" VAT - IOT
B. Bidulock Version 0.6 Page 13
Internet Draft M2PA-TEST October 16, 2005
No. Title VAT CPT IOT
----------------------------------------------------------------------
3.5.1 More than 7 ones between MSU opening and - - -
closing flags
3.5.2 Greater than maximum signal unit length - - -
3.5.3 Below minimum signal unit length VAT - -
3.5.4 Reception of single and multiple - - -
flags between FISUs
3.5.5 Reception of single and multiple - - -
flags between MSUs
3.6.1 Error rate of 1 in 256 - - -
- Link remains in service
3.6.2 Error rate of 1 in 254 - - -
- Link out of service
3.6.3 Consecutive corrupt SUs - - -
3.6.4 Time controlled break of the link - - -
3.7.1 Error rate below the normal threshold - - -
3.7.2 Error rate at the normal threshold - - -
3.7.3 Error rate above the normal threshold - - -
3.7.4 Error rate at the emergency threshold - - -
3.8.1 Data transmission and reception VAT CPT IOT
3.8.2 Negative acknowledgments of an MSU - - -
3.8.3 Check RTB full VAT - -
3.8.4 Single invalid Ack VAT - -
3.8.5 Duplicated FSN VAT - -
3.8.6 Erroneous retransmission - Single MSU - - -
3.8.7 Erroneous retransmission - Multiple FISUs - - -
3.8.8 Single FISU with corrupt FIB VAT - -
3.8.9 In Service prior to RPO being set VAT - IOT
3.8.10 Abnormal BSN - single Data message VAT - -
3.8.11 Abnormal BSN - two consecutive messages VAT - -
3.8.12 Excessive delay of acknowledgments VAT - -
3.8.13 Level 3 Stop command VAT - IOT
3.9.1 MSU transmission and reception - - -
3.9.2 Priority control - - -
3.9.3 Forced retransmission with the value N1 - - -
3.9.4 Forced retransmission with the value N2 - - -
3.9.5 Forced retransmission cancel - - -
3.9.6 Reception of forced retransmission - - -
3.9.7 MSU transmission while RPO set - - -
3.9.8 Abnormal BSN - Single MSU - - -
3.9.9 Abnormal BSN - Two MSUs - - -
3.9.10 Unexpected FSN - - -
3.9.11 Excessive delay of acknowledgments - - -
3.9.12 FISU with FSN expected for MSU - - -
3.9.13 Level 3 Stop command - - -
3.10.1 Congestion abatement VAT - IOT
3.10.2 Timer T7 VAT - -
3.10.3 Timer T6 VAT - -
B. Bidulock Version 0.6 Page 14
Internet Draft M2PA-TEST October 16, 2005
3.1. Link State Control - Expected signal units/orders
3.1.1. Initialization (Power-up)
These tests check that the IUT enters the correct state upon
establishment of the SCTP association. Establishing the association
at both peers is the equivalent to the Q.703 "Power On". The correct
behavior is for both M2PA peers to send a status "Out of Service" and
enter the "Out of Service" state. These test are useful both for
Validation and Compatibility testing.
3.1.1.1. Forward Direction
The test is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.1-1.
Reference: Q.781/Test 1.1(a)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| :power on |
| OUT-OF-SERVICE -----------------> |
| :power on |
| <----------------- OUT-OF-SERVICE |
| (Note) OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE (Note) |
| |
|___________________________________________________________________|
Figure 3.1.1-1. Initialization (Power-up)
Test Description:
(1) The test begins with both SP B and SP A in the "Power Off"
state.
(2) The "Power On" command is issued at SP B and then SP A.
(3) Check that SP A sends a status "Out of Service" message enters
and remains in the "Out of Service" state. (Note that SP A or
B may send additional status "Out of Service" messages.)
(4) Repeat the test in the opposite direction as shown below.
3.1.1.2. Reverse Direction
This is the test repeated in the opposite direction. The expected
sequence of events is illustrated in Figure 3.1.1-2.
B. Bidulock Version 0.6 Page 15
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.1(b)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| :power on |
| <----------------- OUT-OF-SERVICE |
| :power on |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE (Note) |
| (Note) OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.1.1-2. Initialization (Power-up)
Test Description:
(1) The test begins with both SP A and SP B in the "Power Off"
state.
(2) The "Power On" command is issued at SP A and then SP B.
(3) Check that SP A sends a status "Out of Service" message enters
and remains in the "Out of Service" state. (Note that SP A or
B may send additional status "Out of Service" messages.)
3.1.2. Timer T2
This test validates the T2 (Not Aligned) timer and procedure at the
IUT. This is the duration of time that the M2PA peer will wait to
receive a status "Alignment" message after sending a status
"Alignment" message.
B. Bidulock Version 0.6 Page 16
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.2
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| (Note) OUT-OF-SERVICE -----------------> |
| <----------------- ALIGNMENT (Note) |
| ! |
| ! T2 5.0 <= T2 <= 150.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(AERM) |
| |
|___________________________________________________________________|
Figure 3.1.2-1. Timer T2
Test Description:
(1) The test begins with both SP B and SP A in the "Out of Service"
state.
(2) The "Start" command is issued at SP A.
(3) Check that SP A sends a status "Alignment" message. (Note that
SP A may send additional status "Alignment" messages, and SP B
may send additional status "Out of Service" messages.)
(4) Check that SP A sends a status "Out of Service" and issues an
"Out of Service" indication to Level 3 with reason "Alignment
Not Possible".
(5) Check that T2 is between 5.0 seconds and 150.0 seconds in
duration.
(6) SP A should stay in the "Out of Service" state.
3.1.3. Timer T3
This test validates the T3 (Aligned) timer and procedure at the IUT.
This is the duration of time that the M2PA peer will wait to receive a
status "Proving Normal" or status "Proving Emergency" message from the
M2PA peer after sending status "Proving Normal" or status "Proving
Emergency". This test case is conditional on the IUT being configured
for proving. The expected sequence of events is illustrated in Figure
3.1.3-1.
B. Bidulock Version 0.6 Page 17
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| ! |
| ! T3 1.0 <= T3 <= 1.5 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(AERM) |
| |
|___________________________________________________________________|
Figure 3.1.3-1. Timer T3
Test Description:
(1) The test begins with both the PT and the IUT in the "Out of
Service" state and the IUT set to perform proving.
(2) The Level 3 "Start" command is issued at the IUT.
(3) Check that the IUT sends a status "Alignment" message.
(4) Send a status "Alignment" message to the IUT.
(5) Check that the IUT response with a status "Proving Normal"
message. (Note that the IUT may send additional status
"Proving Normal" messages.)
(6) Check that the link goes out of service for reason "Alignment
Not Possible".
(7) Check that T3 is between 1.0 seconds and 1.5 seconds in
duration.
3.1.4. Timer T1 & Timer T4 (Normal)
This test validates the T4(Normal) (Proving) and T1 (Aligned Ready)
timers and procedures at the IUT. T4 is the duration of time that the
M2PA peer will wait to complete proving. T1 is the duration that the
M2PA peer will wait to receive a status "Ready" or a status "Processor
Outage" message from the M2PA peer after sending a status "Ready" or
status "Processor Outage" message. This test case is condition the
IUT being configured to perform proving. The expected sequence of
events is illustrated in Figure 3.1.4-1.
B. Bidulock Version 0.6 Page 18
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| ! |
| | T4(Pn) 7.5 <= T4 <= 9.5 |
| ! |
| <----------------- READY |
| <----------------- READY (Note) |
| ! |
| ! T1 40.0 <= T1 <- 50.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T1) |
| |
|___________________________________________________________________|
Figure 3.1.4-1. Timer T1 & Timer T4 (Normal)
Test Description:
(1) The test begins with both the PT and the IUT in the "Out of
Service" state and the IUT set to perform proving.
(2) The Level 3 "Start" command is issued at the IUT.
(3) Check that the IUT sends a status "Alignment" message.
(4) Send a status "Alignment" message to the IUT and exchange
status "Proving Normal" messages. (Note that the IUT or PT may
send additional status "Alignment" or status "Proving Normal"
messages.)
(5) Check that a status "Ready" message is received from the IUT
within time T4. (Note that the IUT may send additional status
"Ready" messages before sending status "Out of Service".)
(6) Check that T4 is between 7.5 seconds and 9.5 seconds in
duration.
(7) Check that a status "Out of Service" message is received from
the IUT within time T1 and that an "Out of Service" indication
is given to Level 3 at the IUT with reason "T1 Timeout".
B. Bidulock Version 0.6 Page 19
Internet Draft M2PA-TEST October 16, 2005
(8) Check that T1 is between 40.0 seconds and 50.0 seconds in
duration.
3.1.5. Normal alignment procedure
This test case validates the normal alignment procedure at the IUT.
This is a normal successful alignment procedure which results in the
link going to and staying in the "Ready" state.
3.1.5.1. Forward Direction with Proving
The test is performed in the forward direction with proving enabled
at the IUT. The expected sequence of events is illustrated in Figure
3.1.5-1.
Reference: Q.781/Test 1.5(a)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.5-1. Normal alignment procedure
Test Description:
(1) The test begins with the link "Out of Service" and SP A set to
perform proving.
(2) The Level 3 "Start" command is issued at SP A and SP B.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.5-1. (Note that SP A or SP B may send additional
status "Proving Normal" messages.)
(4) Check that SP A sends a status "Ready" message and indicates
"In Service" to Level 3.
(5) Check that the link maintains the "In Service" state.
B. Bidulock Version 0.6 Page 20
Internet Draft M2PA-TEST October 16, 2005
3.1.5.2. Reverse Direction with Proving
This test is performed in the reverse direction with proving enabled
at the IUT.
The equivalent Q.781 test case is normally repeated with with 2-byte
LSSUs instead of 1-byte LSSUs when testing Q.703 links. The effect of
sending 2-byte LSSUs is simulated by adding a "filler" to the status
message. The expected sequence of events is illustrated in Figure
3.1.5-2.
Reference: Q.781/Test 1.5(b)
___________________________________________________________________
| |
| CPT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.5-2. Normal alignment procedure
Test Description:
(1) The test begins with the link "Out of Service" and SP A set to
perform proving.
(2) The Level 3 "Start" command is issued at SP A and SP B.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.5-2. (Note that SP A or B may send additional
status "Alignment" or status "Proving Normal" messages.)
(4) Check that SP A sends a status "Ready" message and indicates
"In Service" to Level 3.
(5) Check that the link maintains the "In Service" state.
3.1.5.3. Forward Direction without Proving
This test is performed in the forward direction with proving
disabled at the IUT. This test is only applicable if the IUT supports
B. Bidulock Version 0.6 Page 21
Internet Draft M2PA-TEST October 16, 2005
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.5-3.
Reference: Q.781/Test 1.5(a)
___________________________________________________________________
| |
| CPT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.5-3. Normal alignment procedure (without proving)
Test Description:
(1) The test begins with the link "Out of Service" and SP A set to
not perform proving.
(2) The Level 3 "Start" command is issued at SP A and SP B.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.5-3.
(4) Check that SP A sends a status "Ready" message and indicates
"In Service" to Level 3.
(5) Check that the link maintains the "In Service" state.
3.1.5.4. Reverse Direction without Proving
This test is performed in the reverse direction with proving
disabled at the IUT. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.5-4.
B. Bidulock Version 0.6 Page 22
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.5(b)
___________________________________________________________________
| |
| CPT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.5-4. Normal alignment procedure (without proving)
Test Description:
(1) The test begins with the link "Out of Service" and SP A set to
not perform proving.
(2) The Level 3 "Start" command is issued at SP A and SP B.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.5-4.
(4) Check that SP A sends a status "Ready" message and indicates
"In Service" to Level 3.
(5) Check that the link maintains the "In Service" state.
3.1.6. Normal alignment procedure - correct procedure (Data)
The test case validates the normal alignment procedure at the IUT
when a DATA message is used instead of a status "Ready" to complete
the alignment procedure.
3.1.6.1. Correct Procedure (Data) with Proving
This test is performed with the IUT set for proving. The expected
sequence of events is illustrated in Figure 3.1.6-1.
B. Bidulock Version 0.6 Page 23
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.6
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| <-000000, FFFFFF-- DATA-ACK |
| !in service |
| !msu |
| |
|___________________________________________________________________|
Figure 3.1.6-1. Normal alignment procedure (Data) with proving
Test Description:
(1) The test begins with the link "Out of Service" and the IUT set
to perform proving.
(2) The Level 3 "Start" command is issued at the IUT and the PT.
(3) Check that the IUT sends the message sequence illustrated in
Figure 3.1.6-1. (Note that the IUT may send additional status
"Out of Service," status "Alignment" or status "Proving Normal"
messages.)
(4) Check that the IUT sends a status "Ready" message and indicates
"In Service" to Level 3.
(5) Check that the IUT acknowledges the Data message with a "Data
Ack" message.
(6) The IUT should maintain the "In Service" state.
3.1.6.2. Correct Procedure (Data) without Proving
This test is performed with the IUT set to disable proving. This
test is only applicable if the IUT supports suppression of the proving
period. The expected sequence of events is illustrated in Figure
3.1.6-2.
B. Bidulock Version 0.6 Page 24
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.6
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- READY |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| <-000000, FFFFFF-- DATA-ACK |
| !in service |
| !msu |
| |
|___________________________________________________________________|
Figure 3.1.6-2. Normal alignment procedure (Data) without proving
Test Description:
(1) The test begins with the link "Out of Service" and the IUT set
to not perform proving.
(2) The Level 3 "Start" command is issued at the IUT and the PT.
(3) Check that the IUT sends the message sequence illustrated in
Figure 3.1.6-2.
(4) Check that the IUT sends a status "Ready" message and indicates
"In Service" to Level 3.
(5) Check that the IUT acknowledges the Data message with a "Data
Ack" message.
(6) The IUT should maintain the "In Service" state.
3.1.7. Status "Alignment" received during normal proving period
This test case validates that the IUT restarts the alignment and
proving procedure when receiving a status "Alignment" message in the
"Proving" state. The expected sequence of events is illustrated in
Figure 3.1.7-1.
B. Bidulock Version 0.6 Page 25
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.7
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| <----------------- PROVING-NORMAL |
| ! |
| :start ! |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| ! |
| ! T4(Pn) 7.5 <= T4 <= 9.5 |
| ! |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.7-1. "Alignment" during normal proving
Test Description:
(1) The test begins with the link in the "Out of Service" state and
the IUT set to perform proving.
(2) Issue the Level 3 "Start" command at the IUT and the PT.
(3) When normal proving begins, wait for half the duration of T4
and then send the IUT a status "Alignment" message.
(4) Check that the IUT restarts the proving period and sends a
status "Ready" message T4 after the last status "Alignment"
message was sent to the IUT. (Note that the IUT may send
additional status "Out of Service," "Alignment" or "Proving
Normal" messages.)
(5) Check that T4(Pn) is between 7.5 seconds and 9.5 seconds in
duration.
3.1.8. Normal alignment with PO set
This case tests the normal alignment procedure where one M2PA peer
is experiencing a local processor outage before and during alignment.
The M2PA peers should still align and the link should go into service
at Level 3.
B. Bidulock Version 0.6 Page 26
Internet Draft M2PA-TEST October 16, 2005
3.1.8.1. Forward Direction with Proving
The test is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.8-1.
Reference: Q.781/Test 1.8(a)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| READY -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.8-1. Normal alignment with PO set
Test Description:
(1) The test begins with the link in the "Out of Service" state and
SP A set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A and the "Start" command at SP B.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.8-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Check that SP A sends status "Processor Outage" message.
(5) Check that the link maintains the "Processor Outage" state at
SP A.
3.1.8.2. Reverse Direction with Proving
This case is the same test in the reverse direction. The expected
sequence of events is illustrated in Figure 3.1.8-2.
B. Bidulock Version 0.6 Page 27
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.8(b)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.8-2. Normal alignment with PO set
Test Description:
(1) The test begins with the link in the "Out of Service" state and
SP A set to perform proving.
(2) Issue the Level 3 "Local Processor Outage" and "Start" command
at SP B and the "Start" command at SP A.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.8-2. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Check that SP A sends status "Ready" message and indicates
"Remote Processor Outage" indication to Level 3.
(5) Check that the link maintains the "Processor Outage" state at
SP A.
3.1.8.3. Forward Direction without Proving
The test is performed in the forward direction with the IUT set to
not perform proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.8-3.
B. Bidulock Version 0.6 Page 28
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.8(a)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| READY -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.8-3. Normal alignment with PO set
Test Description:
(1) The test begins with the link in the "Out of Service" state and
SP A set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A and the "Start" command at SP B.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.8-3.
(4) Check that SP A sends status "Processor Outage" message.
(5) Check that the link maintains the "Processor Outage" state at
SP A.
3.1.8.4. Reverse Direction without Proving
This case is the same test in the reverse direction. with the IUT
set to not perform proving. This test is only applicable if the IUT
supports suppression of the proving period. The expected sequence of
events is illustrated in Figure 3.1.8-4.
B. Bidulock Version 0.6 Page 29
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.8(b)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| <----------------- READY |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.8-4. Normal alignment with PO set
Test Description:
(1) The test begins with the link in the "Out of Service" state and
SP A set to not perform proving.
(2) Issue the Level 3 "Local Processor Outage" and "Start" command
at SP B and the "Start" command at SP A.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.8-4.
(4) Check that SP A sends status "Ready" message and indicates
"Remote Processor Outage" indication to Level 3.
(5) Check that the link maintains the "Remote Processor Outage"
state at SP A.
3.1.9. Normal alignment with PO set (Data)
This test case validates the normal alignment procedure at the IUT
in the "Processor Outage" state when a Data message is used instead of
an "Ready" message to complete the alignment procedure.
3.1.9.1. Forward Direction with Proving
The test is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.9-1.
B. Bidulock Version 0.6 Page 30
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.9(a)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| |
|___________________________________________________________________|
Figure 3.1.9-1. Normal alignment with PO set (Data)
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.9-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Check that SP A sends status "Processor Outage" message and
send a Data message to SP A to complete the alignment
procedure.
(5) Check that SP A does not acknowledge the Data message.
(6) Check that SP A maintains the "Processor Outage" state.
3.1.9.2. Reverse Direction with Proving
This is the same test in the reverse direction. The expected
sequence of events is illustrated in Figure 3.1.9-2.
B. Bidulock Version 0.6 Page 31
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.9(b)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| :msu |
| PROVING-NORMAL -----------------> |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.9-2. Normal alignment with PO set (Data)
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP B and the "Start" command at SP A.
(3) Provide an MSU for transmission at SP A before the proving
period ends.
(4) Check that SP A sends the message sequence illustrated in
Figure 3.1.9-2. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(5) Check that SP A completes the proving process with the MSU and
indicates "Remote Processor Outage" to Level 3.
(6) Check that SP A maintains the "Processor Outage" state and does
not require acknowledgment of the Data message used to complete
alignment.
3.1.9.3. Forward Direction without Proving
The test is performed in the forward direction with the IUT set to
not perform proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.9-3.
B. Bidulock Version 0.6 Page 32
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.9(a)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| |
|___________________________________________________________________|
Figure 3.1.9-3. Normal alignment with PO set (Data)
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A.
(3) Check that SP A sends the message sequence illustrated in
Figure 3.1.9-3.
(4) Check that SP A sends status "Processor Outage" message and
send a Data message to SP A to complete the alignment
procedure.
(5) Check that SP A does not acknowledge the Data message.
(6) Check that SP A maintains the "Processor Outage" state.
3.1.9.4. Reverse Direction without Proving
This is the same test in the reverse direction with the IUT set to
not perform proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.9-4.
B. Bidulock Version 0.6 Page 33
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.9(b)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.9-4. Normal alignment with PO set (Data)
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP B and the "Start" command at SP A.
(3) Provide an MSU for transmission at SP A before the proving
period ends.
(4) Check that SP A sends the message sequence illustrated in
Figure 3.1.9-4.
(5) Check that SP A completes the proving process with the MSU and
indicates "Remote Processor Outage" to Level 3.
(6) Check that SP A maintains the "Processor Outage" state and does
not require acknowledgment of the Data message used to complete
alignment.
3.1.10. Normal alignment with PO set and cleared
This case tests that if the local processor outage condition is set
and cleared before the alignment procedure starts that normal
alignment is performed and no status "Processor Outage" message is
sent to the M2PA peer.
B. Bidulock Version 0.6 Page 34
Internet Draft M2PA-TEST October 16, 2005
3.1.10.1. PO set and cleared with Proving
This test is performed with proving set at the IUT. The expected
sequence of events is illustrated in Figure 3.1.10-1.
Reference: Q.781/Test 1.10
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :clear lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.10-1. Normal alignment with PO set and cleared
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage," "Clear Local
Processor Outage" and "Start" commands at SP A and "Start"
command at SP B.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.10-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Check that SP A completes the alignment procedure and sends the
status "Ready" message and indicates "In Service" to Level 3.
3.1.10.2. PO set and cleared without Proving
This test is performed with proving disabled at the IUT. This test
is only applicable if the IUT supports suppression of the proving
period. The expected sequence of events is illustrated in Figure
3.1.10-2.
B. Bidulock Version 0.6 Page 35
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.10
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :clear lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.10-2. Normal alignment with PO set and cleared
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage," "Clear Local
Processor Outage" and "Start" commands at SP A and "Start"
command at SP B.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.10-2.
(4) Check that SP A completes the alignment procedure and sends the
status "Ready" message and indicates "In Service" to Level 3.
3.1.11. Set RPO when "Aligned not ready"
This test case validates the behavior of the IUT when processor
outage condition is set at both the PT and the IUT.
3.1.11.1. Forward Direction with Proving
This test is performed in the forward direction with the IUT set to
perform proving. The expected sequence of events is illustrated in
Figure 3.1.11-1.
B. Bidulock Version 0.6 Page 36
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.11
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.11-1. Set RPO when "Aligned Not Ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and PT.
(3) Check that the alignment procedure follows the sequence of
events illustrated in Figure 3.1.11-1. (Note that the IUT may
send additional status "Out of Service," "Alignment" or
"Proving Normal" messages.)
(4) Check that the IUT sends status "Processor Outage" and
indicates "Remote Processor Outage" to Level 3.
3.1.11.2. Forward Direction without Proving
This test is performed in the forward direction with the IUT set to
not perform proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.11-2.
B. Bidulock Version 0.6 Page 37
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.11
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.11-2. Set RPO when "Aligned Not Ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and PT.
(3) Check that the alignment procedure follows the sequence of
events illustrated in Figure 3.1.11-2. (Note that the IUT may
send additional status "Out of Service," "Alignment" or
"Proving Normal" messages.)
(4) Check that the IUT sends status "Processor Outage" and
indicates "Remote Processor Outage" to Level 3.
3.1.12. Status "Out of Service" received when "Aligned not ready"
These test cases validate the behavior of the IUT when it receives a
status "Out of Service" message in the "Aligned Not Ready" state or
sends a Status "Out of Service" message when the M2PA peer is in the
"Aligned Not Ready" state.
3.1.12.1. Forward Direction with Proving
The test is performed in the forward direction with the IUT set to
perform proving. The expected sequence of events is illustrated in
Figure 3.1.12-1.
B. Bidulock Version 0.6 Page 38
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.12(a)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :stop |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIOS) |
| |
|___________________________________________________________________|
Figure 3.1.12-1. "Out of Service" when "Aligned not ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and the "Start" command at the PT.
(3) Check that the IUT follows the sequence of events illustrated
in Figure 3.1.12-1. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Check that the IUT sends a status "Processor Outage" message
when it completes the initial alignment procedure and issue a
Level 3 "Stop" command at the PT.
(5) Check that the IUT sends status "Out of Service" and indicates
"Out of Service" to Level 3 with the reason "Received SIOS".
3.1.12.2. Reverse Direction with Proving
The test is repeated in the reverse direction with the IUT set to
perform proving. The expected sequence of events is illustrated in
Figure 3.1.12-2.
B. Bidulock Version 0.6 Page 39
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.12(b)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| :stop |
| READY -----------------> |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.12-2. "Out of Service" when "Aligned not ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Start" command at the IUT and the PT.
(3) Check that the sequence of events follows those illustrated in
Figure 3.1.12-2. (Note that the IUT may send additional status
"Out of Service," "Alignment" or "Proving Normal" messages.)
(4) When the IUT goes to the "In Service" state, issue the Level 3
"Stop" command at the IUT.
(5) Check that the IUT sends the status "Out of Service" message.
3.1.12.3. Forward Direction without Proving
The test is performed in the forward direction with the IUT set to
disable proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.12-3.
B. Bidulock Version 0.6 Page 40
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.12(a)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :stop |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIOS) |
| |
|___________________________________________________________________|
Figure 3.1.12-3. "Out of Service" when "Aligned not ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and the "Start" command at the PT.
(3) Check that the IUT follows the sequence of events illustrated
in Figure 3.1.12-3.
(4) Check that the IUT sends a status "Processor Outage" message
when it completes the initial alignment procedure and issue a
Level 3 "Stop" command at the PT.
(5) Check that the IUT sends status "Out of Service" and indicates
"Out of Service" to Level 3 with the reason "Received SIOS".
3.1.12.4. Reverse Direction without Proving
The test is repeated in the reverse direction with the IUT set to
disable proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.12-4.
B. Bidulock Version 0.6 Page 41
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.12(b)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- READY |
| :stop |
| READY -----------------> |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.12-4. "Out of Service" when "Aligned not ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to not perform proving.
(2) Issue the Level 3 "Start" command at the IUT and the PT.
(3) Check that the sequence of events follows those illustrated in
Figure 3.1.12-4.
(4) When the IUT goes to the "In Service" state, issue the Level 3
"Stop" command at the IUT.
(5) Check that the IUT sends the status "Out of Service" message.
3.1.13. Status "Alignment" received when "Aligned not ready"
This test case validates the behavior of the IUT when it receives a
status "Alignment" message in the "Aligned Not Ready" state.
3.1.13.1. Forward Direction with Proving
This test is performed with the IUT set to perform proving. The
expected sequence of events is illustrated in Figure 3.1.13-1.
B. Bidulock Version 0.6 Page 42
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.13
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| ALIGNMENT -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIO) |
| OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.1.13-1. "Alignment" when "Aligned not ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and "Start" command at the PT.
(3) Check that the sequence of events follows the normal alignment
procedure illustrated in Figure 3.1.13-1. (Note that the IUT
may send additional status "Out of Service," "Alignment" or
"Proving Normal" messages.)
(4) When the IUT sends the status "Processor Outage" message, send
a status "Alignment" message to the IUT.
(5) Check that the IUT sends the status "Out of Service" message
and indicates "Out of Service" to Level 3 with reason "Received
SIO".
3.1.13.2. Forward Direction without Proving
This test is performed with the IUT set to disable proving. This
test is only applicable if the IUT supports suppression of the proving
period. The expected sequence of events is illustrated in Figure
3.1.13-2.
B. Bidulock Version 0.6 Page 43
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.13
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| ALIGNMENT -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIO) |
| OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.1.13-2. "Alignment" when "Aligned not ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and "Start" command at the PT.
(3) Check that the sequence of events follows the normal alignment
procedure illustrated in Figure 3.1.13-2.
(4) When the IUT sends the status "Processor Outage" message, send
a status "Alignment" message to the IUT.
(5) Check that the IUT sends the status "Out of Service" message
and indicates "Out of Service" to Level 3 with reason "Received
SIO".
3.1.14. Set and clear LPO when "Initial alignment"
This test case validates the behavior of the IUT when it receives
Level 3 "Set Local Processor Outage" and "Clear Local Processor
Outage" commands in the "Initial Alignment" state. The expected
sequence of events is illustrated in Figure 3.1.14-1.
B. Bidulock Version 0.6 Page 44
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.14
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| :set lpo |
| PROVING-NORMAL -----------------> |
| :clear lpo |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.14-1. Set and clear LPO when "Initial Alignment"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Start" command at SP A and SP B.
(3) Check that SP A follows the normal alignment procedure and
sequence of events illustrated in Figure 3.1.14-1. (Note that
SP A or B may send additional status "Out of Service,"
"Alignment" or "Proving Normal" messages.)
(4) Issue the Level 3 "Set Local Processor Outage" command at SP A
when SP A begins initial alignment.
(5) Issue the Level 3 "Clear Local Processor Outage" command at SP
A before SP A completes initial alignment.
(6) Check that SP A sends the status "Ready" message when it
completes initial alignment and that the "In Service"
indication is given to Level 3 at SP A.
3.1.15. Set and clear LPO when "Aligned ready"
This test case validates the behavior of the IUT when it receives
the Level 3 "Set Local Processor Outage" and "Clear Local Processor
Outage" commands in the "Aligned Ready" state.
B. Bidulock Version 0.6 Page 45
Internet Draft M2PA-TEST October 16, 2005
3.1.15.1. Forward Direction with Proving
This test is performed in the forward direction with the IUT set to
perform proving. The expected sequence of events is illustrated in
Figure 3.1.15-1.
Reference: Q.781/Test 1.15
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| :set lpo |
| READY -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :clear lpo |
| <----------------- PROCESSOR-RECOVERED |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.15-1. Set and clear LPO when "Aligned ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Start" command at both the IUT and the PT.
(3) Check that the IUT follows the normal alignment procedure and
sequence of events illustrated in Figure 3.1.15-1. (Note that
the IUT may send additional status "Out of Service,"
"Alignment" or "Proving Normal" messages.)
(4) When the IUT has completed the initial alignment procedure,
issues the Level 3 "Set Local Processor Outage" command at the
IUT.
(5) Check that the IUT sends a status "Processor Outage" message.
(6) Send a status "Ready" message to the IUT.
B. Bidulock Version 0.6 Page 46
Internet Draft M2PA-TEST October 16, 2005
(7) Check that the IUT indicates "In Service" to Level 3 at the
IUT.
(8) Issue the Level 3 "Clear Local Processor Outage" command at the
IUT.
(9) Check that the IUT sends a status "Processor Recovered"
message.
(10) Send a status "Ready" message to the IUT on the data stream.
(11) Check that the IUT enters the "In Service" state.
(12) Check that the
3.1.15.2. Forward Direction without Proving
This test is performed in the forward direction with the IUT set to
disable proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.15-2.
Reference: Q.781/Test 1.15
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- READY |
| :set lpo |
| READY -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :clear lpo |
| <----------------- PROCESSOR-RECOVERED |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.1.15-2. Set and clear LPO when "Aligned ready"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to not perform proving.
(2) Issue the Level 3 "Start" command at both the IUT and the PT.
B. Bidulock Version 0.6 Page 47
Internet Draft M2PA-TEST October 16, 2005
(3) Check that the IUT follows the normal alignment procedure and
sequence of events illustrated in Figure 3.1.15-2.
(4) When the IUT has completed the initial alignment procedure,
issues the Level 3 "Set Local Processor Outage" command at the
IUT.
(5) Check that the IUT sends a status "Processor Outage" message
and indicates "In Service" to Level 3 at the IUT.
(6) Issue the Level 3 "Clear Local Processor Outage" command at the
IUT.
(7) Check that the IUT sends a status "Processor Recovered"
message.
(8) Send a status "Ready" message to the IUT on the data stream.
(9) Check that the IUT indicates "In Service" to Level 3 at the
IUT.
3.1.16. Timer T1 in "Aligned not ready" state
This test case validates the T1 timer and procedures at the IUT when
the IUT is in the "Aligned Not Ready" state.
3.1.16.1. Forward Direction with Proving
This test is performed in the forward direction with the IUT set to
perform proving. The expected sequence of events is illustrated in
Figure 3.1.16-1.
B. Bidulock Version 0.6 Page 48
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.16
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| <----------------- PROCESSOR-OUTAGE (Note)|
| ! |
| ! T1 40.0 <= T1 <= 50.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T1) |
| |
|___________________________________________________________________|
Figure 3.1.16-1. Timer T1 in "Aligned not ready" state
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A and "Start" command at SP B.
(3) Check that SP A follows the sequence of events illustrated in
Figure 3.1.16-1 while completing the initial alignment
procedure. (Note that SP A or B may send additional status
"Out of Service," "Alignment" or "Proving Normal" messages.)
(Note that SP A may send additional status "Processor Outage"
messages before sending the status "Out of Service" message.)
(4) Check that SP A sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 with reason "T1 Timeout".
(5) Check that T1 is between 40.0 seconds and 50.0 seconds in
duration.
3.1.16.2. Forward Direction without Proving
This test is performed in the forward direction with the IUT set to
disable proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
B. Bidulock Version 0.6 Page 49
Internet Draft M2PA-TEST October 16, 2005
illustrated in Figure 3.1.16-2.
Reference: Q.781/Test 1.16
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| <----------------- PROCESSOR-OUTAGE (Note)|
| ! |
| ! T1 40.0 <= T1 <= 50.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T1) |
| |
|___________________________________________________________________|
Figure 3.1.16-2. Timer T1 in "Aligned not ready" state
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A and "Start" command at SP B.
(3) Check that SP A follows the sequence of events illustrated in
Figure 3.1.16-2 while completing the initial alignment
procedure. <Note that SP A may send additional status
"Processor Outage" messages before sending the status "Out of
Service" message.)
(4) Check that SP A sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 with reason "T1 Timeout".
(5) Check that T1 is between 40.0 seconds and 50.0 seconds in
duration.
3.1.17. No status "Alignment" sent during normal proving period
This test validates that the normal alignment procedure completes at
the IUT when no status "Alignment" message is sent. The expected
sequence of events is illustrated in Figure 3.1.17-1.
B. Bidulock Version 0.6 Page 50
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.17
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| PROVING-NORMAL -----------------> |
| <----------------- PROVING-NORMAL |
| ! |
| ! T3+T4(Pn) 7.5 <= T3+T4 <= 11.0 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.17-1. No "Alignment" during normal proving period
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Start" command at both the IUT and the PT.
(3) Respond to status "Alignment" message sent by the IUT with a
status "Proving Normal" message and continue proving. (Note
that the IUT may send additional status "Out of Service,"
"Alignment" or "Proving Normal" messages.)
(4) Check that the IUT sends a status "Ready" message within T4(Pn)
plus T3.
(5) Check that the delay from the start of the proving period to
the status "Ready" message T4(Pn)+T3 is between 7.5 seconds and
11.0 seconds in duration.
3.1.18. Set and cease emergency prior to "start alignment"
This test case validates the behavior of the IUT when the Level 3
"Set Emergency" and "Clear Emergency" commands are issued prior to the
Level 3 "Start" command at the IUT. The expected sequence of events
is illustrated in Figure 3.1.18-1.
B. Bidulock Version 0.6 Page 51
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.18
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set emergency |
| :clear emergency |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| ! |
| ! T4(Pn) 7.5 <= T4 <= 10.0 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.18-1. Toggle emergency before "start alignment"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Set Emergency," "Clear Emergency" then
"Start" commands at the IUT and "Start" command at the PT.
(3) Check that the sequence of events are as illustrated in Figure
3.1.18-1. Check that the IUT sends a status "Proving Normal"
message in response to the "Alignment" message. (Note that the
IUT may send additional status "Out of Service," "Alignment" or
"Proving Normal" messages.)
(4) Check that the IUT sends a status "Ready" message.
(5) Check that the IUT uses a normal proving period by timing the
delay from the status "Proving Normal" message to the status
"Ready" message sent by the IUT.
(6) Check that T4 is between 7.5 seconds and 10.0 seconds in
duration.
3.1.19. Set emergency while in "not aligned" state
This test case validates the behavior of the IUT when the Level 3
"Set Emergency" command is issued at the IUT immediately after the
Level 3 "Start" command (when the IUT is in the "Not Aligned" state).
The expected sequence of events is illustrated in Figure 3.1.19-1.
B. Bidulock Version 0.6 Page 52
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.19
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :set emergency |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-EMERGENCY |
| PROVING-EMERGENCY -----------------> |
| ! |
| ! T4(Pe) 0.4 <= T4 <= 0.6 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.19-1. Set emergency in "not aligned" state
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Start" and "Set Emergency" commands at SP A
and "Start" command at SP B.
(3) Check that the sequence of events are as illustrated in Figure
3.1.19-1. Check that SP A sends a status "Proving Emergency"
message in response to the "Alignment" message. (Note that SP
A or B may send additional status "Out of Service," "Alignment"
or "Proving Emergency" messages.)
(4) Check that SP A sends a status "Ready" message.
(5) Check that SP A uses an emergency proving period by timing the
delay from the status "Proving Emergency" message to the status
"Ready" message sent by SP A.
(6) Check that T4 is between 0.4 seconds and 0.6 seconds in
duration.
3.1.20. Set emergency when "aligned"
This test case validates the response of the IUT to the Level 3 "Set
Emergency" command when issued in the "Aligned" state at the IUT. The
expected sequence of events is illustrated in Figure 3.1.20-1.
B. Bidulock Version 0.6 Page 53
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.20
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| :set emergency |
| <----------------- PROVING-EMERGENCY |
| ! |
| ! T4(Pe) 0.4 <= T4 <= 0.6 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.20-1. Set emergency when "aligned"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Start" command at SP A and SP B.
(3) Check that the normal alignment procedure starts as illustrated
in Figure 3.1.20-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Before the normal proving period completes, issue the Level 3
"Set Emergency" command at SP A.
(5) Check that SP A sends a status "Proving Emergency" message and
later follows with a status "Ready" message. (Note that SP A
may send additional status "Proving Emergency" messages.)
(6) Check that SP A begins an emergency proving period by timing
the delay from the status "Proving Emergency" message to the
status "Ready" message.
(7) Check that T4 is between 0.4 seconds and 0.6 seconds in
duration.
B. Bidulock Version 0.6 Page 54
Internet Draft M2PA-TEST October 16, 2005
3.1.21. Both ends set emergency.
This test case validates the IUT behavior when the Level 3 "Set
Emergency" command is issued at both ends of the link before the Level
3 "Start" command. The expected sequence of events is illustrated in
Figure 3.1.21-1.
Reference: Q.781/Test 1.21
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set emergency |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-EMERGENCY |
| PROVING-EMERGENCY -----------------> |
| ! |
| ! T4(Pe) 0.4 <= T4 <= 0.6 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.21-1. Both ends set emergency
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Emergency" and "Start" commands at SP A
and the "Start" command at SP B.
(3) Check that SP A starts the emergency alignment procedure by
sending a status "Proving Emergency" message.
(4) Check that SP A follows the sequence of events as illustrated
in Figure 3.1.21-1. Check that SP A completes the alignment
procedure and sends a status "Ready" message. (Note that SP A
or B may send additional status "Out of Service," "Alignment"
or "Proving Emergency" messages.)
(5) Check that SP A uses an emergency proving period by timing the
delay between sending the status "Proving Normal" message and
the status "Ready" message.
B. Bidulock Version 0.6 Page 55
Internet Draft M2PA-TEST October 16, 2005
(6) Check that T4 is between 0.4 seconds and 0.6 seconds in
duration.
3.1.22. Individual end sets emergency
This test case validates the behavior of the IUT when emergency is
individually set at the PT before the initial alignment procedure
begins. The expected sequence of events is illustrated in Figure
3.1.22-1.
Reference: Q.781/Test 1.22
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set emerg |
| :start |
| ALIGNMENT -----------------> |
| :start |
| <----------------- ALIGNMENT |
| PROVING-EMERGENCY -----------------> |
| <----------------- PROVING-NORMAL |
| ! |
| ! T4(Pe) 0.4 <= T4 <= 0.6 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.22-1. Individual end sets emergency
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Emergency" and "Start" commands at SP B
and the "Start" command at SP A.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.22-1.
(4) Check that SP A uses the emergency proving period by timing the
delay between the status "Proving Normal" message and the
status "Ready" message. (Note that SP B may send additional
status "Out of Service," "Alignment" or "Proving Emergency"
messages.) (Note that SP A may send additional status "Out of
Service," "Alignment" or "Proving Normal" messages.)
B. Bidulock Version 0.6 Page 56
Internet Draft M2PA-TEST October 16, 2005
(5) Check that T4 is between 0.4 seconds and 0.6 seconds in
duration.
3.1.23. Set emergency during normal proving
This test case validates the IUT behavior when it receives a Level 3
"Set Emergency" command after it has already commenced normal proving.
The expected sequence of events is illustrated in Figure 3.1.23-1.
Reference: Q.781/Test 1.23
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| :set emergency |
| <----------------- PROVING-EMERGENCY |
| ! |
| ! T4(Pe) 0.4 <= T4 <= 0.6 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.23-1. Set emergency during normal proving
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Start" command at SP A and SP B.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.23-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Before the normal proving period completes at SP A, issue the
Level 3 "Set Emergency" command at SP A.
(5) Check that SP A sends a status "Proving Emergency" message and
continues proving. (Note that SP A may send additional status
"Proving Emergency" messages.)
B. Bidulock Version 0.6 Page 57
Internet Draft M2PA-TEST October 16, 2005
(6) Check that SP A sends a status "Ready" message.
(7) Check that SP A uses an emergency proving period by timing the
delay between the status "Proving Emergency" message and the
status "Ready" message.
(8) Check that T4 is between 0.4 seconds and 0.6 seconds in
duration.
3.1.24. No status "Alignment" sent during emergency alignment
This test case validates the response of the IUT to receiving a
status "Proving Normal" without a status "Alignment" during initial
alignment using an emergency proving period. The expected sequence of
events is illustrated in Figure 3.1.24-1.
Reference: Q.781/Test 1.24
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set emergency |
| :start |
| <----------------- ALIGNMENT |
| :start |
| PROVING-EMERGENCY -----------------> |
| <----------------- PROVING-EMERGENCY |
| ! |
| ! T4(Pe) 0.4 <= T4 <= 0.6 |
| ! |
| <----------------- READY |
| |
|___________________________________________________________________|
Figure 3.1.24-1. No "Alignment" during emergency alignment
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Set Emergency" and "Start" commands at both
the IUT and PT.
(3) Check that the IUT sends a status "Proving Emergency" message
and starts proving. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Emergency"
messages.)
(4) Check that the IUT completes proving and sends a status "Ready"
message.
B. Bidulock Version 0.6 Page 58
Internet Draft M2PA-TEST October 16, 2005
(5) Check that the IUT uses an emergency proving period by timing
the delay between the status "Proving Emergency" message and
the status "Ready" message.
(6) Check that T4 is between 0.4 seconds and 0.6 seconds in
duration.
3.1.25. Deactivation during initial alignment
This test case validates the behavior of the IUT in response to the
Level 3 "Stop" command issued during the "Initial Alignment" state at
the IUT. The expected sequence of events is illustrated in Figure
3.1.25-1.
Reference: Q.781/Test 1.25
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :stop |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.25-1. Deactivate during initial alignment
Test Description:
(1) The test begins with the link in the "Out of Service" state.
(2) Issue the Level 3 "Start" command at SP A.
(3) Before timer T2 expires, issue the Level 3 "Stop" command at
the IUT.
(4) Check that SP A sends a status "Out of Service" message and
stays in the "Out of Service" state.
3.1.26. Deactivation during aligned state
This test case validates the behavior of the IUT in response to the
Level 3 "Stop" command issued during "Aligned" state at the IUT. The
expected sequence of events is illustrated in Figure 3.1.26-1.
B. Bidulock Version 0.6 Page 59
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.26
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| :stop |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.26-1. Deactivate during aligned state
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue the Level 3 "Start" command at the IUT and the PT.
(3) Check that the IUT follows the sequence of events illustrated
in Figure 3.1.26-1. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) Issue the Level 3 "Stop" command at the IUT.
(5) Check that the IUT sends a status "Out of Service" message and
stays in the "Out of Service" state.
3.1.27. Deactivation during aligned not ready
This test case validates the behavior of the IUT in response to the
Level 3 "Stop" command issued during the "Aligned Not Ready" state at
the IUT.
3.1.27.1. Forward Direction with Proving
This test is performed in the forward direction with the IUT set to
perform proving. The expected sequence of events is illustrated in
Figure 3.1.27-1.
B. Bidulock Version 0.6 Page 60
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.27
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :stop |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.27-1. Deactivate during aligned not ready
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A and the "Start" command at the PT.
(3) Check that SP A follows the sequence of events illustrated in
Figure 3.1.27-1 and sends a status "Processor Outage" message.
(Note that SP A or B may send additional status "Out of
Service," "Alignment" or "Proving Normal" messages.)
(4) Issue the Level 3 "Stop" command at SP A.
(5) Check that SP A sends a status "Out of Service" message and
stays in the "Out of Service" state.
3.1.27.2. Forward Direction without Proving
This test is performed in the forward direction with the IUT set to
disable proving. This test is only applicable if the IUT supports
suppression of the proving period. The expected sequence of events is
illustrated in Figure 3.1.27-2.
B. Bidulock Version 0.6 Page 61
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.27
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :stop |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.27-2. Deactivate during aligned not ready
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to not perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at SP A and the "Start" command at SP B.
(3) Check that SP A follows the sequence of events illustrated in
Figure 3.1.27-2 and sends a status "Processor Outage" message.
(4) Issue the Level 3 "Stop" command at SP A.
(5) Check that SP A sends a status "Out of Service" message and
stays in the "Out of Service" state.
3.1.28. Status "alignment" received during link in service
This test case validates the IUT response to receiving a status
"Alignment" message in the "In Service" state. The expected sequence
of events is illustrated in Figure 3.1.28-1.
B. Bidulock Version 0.6 Page 62
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.28
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| ALIGNMENT -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIO) |
| |
|___________________________________________________________________|
Figure 3.1.28-1. "Alignment" during link in service
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send a status "Alignment" to the IUT.
(3) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 with reason "Received
SIO".
3.1.29. Status "out of service" received during link in service
This test case validates the response of the IUT to sending or
receiving a status "Out of Service" message in the "In Service" state.
3.1.29.1. Forward Direction
The test case is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.29-1.
Reference: Q.781/Test 1.29(a)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| :stop |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIOS) |
| |
|___________________________________________________________________|
Figure 3.1.29-1. "Out of service" during link in service
Test Description:
(1) The test begins with the link in the "In Service" state.
B. Bidulock Version 0.6 Page 63
Internet Draft M2PA-TEST October 16, 2005
(2) Issue the Level 3 "Stop" command at SP B and send a status "Out
of Service" message to SP A.
(3) Check that SP A sends a status "Out of Service" message and
indicates "Out of Service" to the Level 3 at SP A with reason
"Received SIOS".
3.1.29.2. Reverse Direction
The test case is repeated in the reverse direction. The expected
sequence of events is illustrated in Figure 3.1.29-2.
Reference: Q.781/Test 1.29(b)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| :stop |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.1.29-2. "Out of service" during link in service
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue the Level 3 "Stop" command at SP A.
(3) Check that SP A sends a status "Out of Service" message and
stays in the "Out of Service" state.
3.1.30. Deactivation during LPO
These test cases validate the response of the IUT to sending a
status "Out of Service" message while in the "Processor Outage" state
with LPO set, or receiving an "Out of Service" message from an M2PA
peer in the "Processor Outage" state with RPO set.
3.1.30.1. Forward Direction
The test is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.30-1.
B. Bidulock Version 0.6 Page 64
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.30(a)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| :stop |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.30-1. Deactivation during LPO
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue the Level 3 "Set Local Processor Outage" command at SP A.
(3) Check that SP A sends a status "Processor Outage" message.
(4) Issue the Level 3 "Stop" command at SP A.
(5) Check that SP A sends a status "Out of Service" message and
stays in the "Out of Service" state.
3.1.30.2. Reverse Direction
The test is repeated in the reverse direction. The expected
sequence of events is illustrated in Figure 3.1.30-2.
Reference: Q.781/Test 1.30(b)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :set lpo |
| PROCESSOR-OUTAGE -----------------> |
| :stop |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE |
| !rpo |
| !out of service(SIOS) |
| |
|___________________________________________________________________|
Figure 3.1.30-2. Deactivation during LPO
B. Bidulock Version 0.6 Page 65
Internet Draft M2PA-TEST October 16, 2005
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue the Level 3 "Set Local Processor Outage" and "Stop"
commands at SP B.
(3) Check that SP A sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at SP A with reason
"Received SIOS".
3.1.31. Deactivation during RPO
These test cases validate the response of the IUT to sending a
status "Out of Service" message while in the "Processor Outage" state
with RPO set, or receiving an "Out of Service" message from an M2PA
peer in the "Processor Outage" state with LPO set.
3.1.31.1. Forward Direction
The test is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.31-1.
Reference: Q.781/Test 1.31(a)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| PROCESSOR-OUTAGE -----------------> |
| :stop |
| <----------------- OUT-OF-SERVICE |
| |
|___________________________________________________________________|
Figure 3.1.31-1. Deactivation during RPO
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue the Level 3 "Set Local Processor Outage" command at SP B
and send a status "Processor Outage" message to SP A.
(3) Issue the Level 3 "Stop" command at SP A.
(4) Check that SP A sends the status "Out of Service" message and
remains in the "Out of Service" state.
3.1.31.2. Reverse Direction
The test is repeated in the reverse direction. The expected
sequence of events is illustrated in Figure 3.1.31-2.
B. Bidulock Version 0.6 Page 66
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.31(b)
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| :stop |
| OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.1.31-2. Deactivation during RPO
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue the Level 3 "Set Local Processor Outage" command at SP A.
(3) Check that SP A sends a status "Processor Outage" message.
(4) Issue the Level 3 "Stop" command at SP B and send the status
"Out of Service" message.
(5) Check that SP A does not indicate "Out of Service" until the
local processor outage condition recovers.
3.1.32. Deactivation during the proving period
These test cases validate the response of the IUT to deactivation
(sending or receiving a status "Out of Service" message) during the
proving period.
3.1.32.1. Forward Direction
The test is performed in the forward direction. The expected
sequence of events is illustrated in Figure 3.1.32-1.
B. Bidulock Version 0.6 Page 67
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.32(a)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| :stop |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(AERM) |
| |
|___________________________________________________________________|
Figure 3.1.32-1. Deactivation during the proving period
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Start" command at SP A and SP B.
(3) Check that SP A follows the sequence of events illustrated in
Figure 3.1.32-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) During the proving period, issue the Level 3 "Stop" command at
SP B and send status "Out of Service" to SP A.
(5) Check that SP A sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at SP A with reason
"Alignment Not Possible".
3.1.32.2. Reverse Direction
The test is repeated in the reverse direction. The expected
sequence of events is illustrated in Figure 3.1.32-2.
B. Bidulock Version 0.6 Page 68
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.32(b)
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| OUT-OF-SERVICE -----------------> |
| :start |
| :start |
| ALIGNMENT -----------------> |
| <----------------- OUT-OF-SERVICE |
| <----------------- ALIGNMENT |
| PROVING-NORMAL -----------------> |
| <----------------- PROVING-NORMAL |
| :stop |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.1.32-2. Deactivation during the proving period
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue the Level 3 "Start" command at SP B and SP A.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.32-2. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) During the proving period, issue a Level 3 "Stop" command at SP
A.
(5) Check that SP A sends a status "Out of Service" message and
remains in the "Out of Service" state.
3.1.33. Status "Alignment" received instead of status "Ready"
This test case validates the response of the IUT to receiving a
status "Alignment" message instead of a status "Ready" or "Processor
Outage" message at the completion of initial alignment. The expected
sequence of events is illustrated in Figure 3.1.33-1.
B. Bidulock Version 0.6 Page 69
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.33
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| ALIGNMENT -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIO) |
| |
|___________________________________________________________________|
Figure 3.1.33-1. "Alignment" instead of "In Service"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue a Level 3 "Start" command at the IUT and the PT.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.33-1. (Note that the IUT may send additional status
"Out of Service," "Alignment" or "Proving Normal" messages.)
(4) When the IUT sends a status "Ready" message, send a status
"Alignment" message to the IUT.
(5) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at the IUT with reason
"Received SIO".
3.1.34. Status "Out of Service" received instead of status "Ready"
This test case validates the response of the IUT to receiving a
status "Out of Service" message instead of a status "Ready" or
"Processor Outage" message at the completion of initial alignment.
The expected sequence of events is illustrated in Figure 3.1.34-1.
B. Bidulock Version 0.6 Page 70
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.34
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| :stop |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE |
| !out of service(SIOS) |
| |
|___________________________________________________________________|
Figure 3.1.34-1. "Out of Service" instead of "In Service"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with the IUT set to perform proving.
(2) Issue a Level 3 "Start" command at the IUT and the PT.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.34-1. (Note that the IUT may send additional status
"Out of Service," "Alignment" or "Proving Normal" messages.)
(4) When the IUT sends a status "Ready" message, send a status "Out
of Service" message to the IUT.
(5) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at the IUT with reason
"Received SIOS".
3.1.35. Status "Processor Outage" received instead of status "Ready"
This test case validates the response of the IUT to receiving a
status "Processor Outage" message instead of a status "Ready" message
at the completion of initial alignment. The expected sequence of
events is illustrated in Figure 3.1.35-1.
B. Bidulock Version 0.6 Page 71
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 1.35
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| :set lpo |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| |
|___________________________________________________________________|
Figure 3.1.35-1. "Processor Outage" instead of "In Service"
Test Description:
(1) The test begins with the link in the "Out of Service" state
with SP A set to perform proving.
(2) Issue a Level 3 "Start" command at SP A and SP B.
(3) Check that the sequence of events follows that illustrated in
Figure 3.1.35-1. (Note that SP A or B may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) When SP A sends a status "Ready" message, issue a Level 3 "Set
Local Processor Outage" command at SP B and send a status
"Processor Outage" message to SP A.
(5) Check that SP A indicates "Remote Processor Outage" to Level 3
at SP A.
3.2. Link State Control - Unexpected signal units/orders
This suite of test cases test the response of the Implementation
Under Test to unexpected sequences Level 3 requests and received M2PA
messages in various states. These test cases validates the robustness
of the implementation in responding to unusual circumstances.
3.2.1. Unexpected signal units/orders in "Out of service" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 requests and receipt of unexpected M2PA messages
B. Bidulock Version 0.6 Page 72
Internet Draft M2PA-TEST October 16, 2005
while in the "Out of Service" state. All of the unexpected sequences
in this test case MUST be ignored by the IUT. The expected sequence
of events is illustrated in Figure 3.2.1-1.
Reference: Q.781/Test 2.1
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| ALIGNMENT -----------------> |
| PROVING-NORMAL -----------------> |
| PROVING-EMERGENCY -----------------> |
| PROCESSOR-RECOVERED -----------------> |
| PROCESSOR-OUTAGE -----------------> |
| BUSY-ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| READY -----------------> |
| DATA-ACK --FFFFFF, FFFFFF-> |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :stop |
| :start |
| <----------------- ALIGNMENT |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.2.1-1. Unexpected events in the "Out of Service" State
Test Description:
(1) The test begins with both M2PA peers in the "Out of Service"
state with the IUT set to perform proving.
(2) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Out of Service"
- Status "Alignment"
- Status "Proving Normal"
- Status "Proving Emergency"
- Status "Processor Recovered"
- Status "Processor Outage"
- Status "Busy Ended"
B. Bidulock Version 0.6 Page 73
Internet Draft M2PA-TEST October 16, 2005
- Status "Busy"
- Status "Ready"
- Status Invalid
- Data Ack
- Data
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
(3) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Stop" command
(4) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(5) The Level 3 "Start" command is then issued.
(6) Check that the link aligns normally.
(7) Check that link alignment uses normal alignment procedures.
(8) Check that the link goes in service and stays in service
without local or remote processor outage indications to Level
3.
3.2.2. Unexpected signal units/orders in "Not Aligned" state
This test case validates the response of the IUT to the receipt of
unexpected Level 3 requests and receipt of unexpected M2PA messages
while in the "Not Aligned" state. All of the unexpected sequences in
this test case MUST be ignored by the IUT. The expected sequence of
events is illustrated in Figure 3.2.2-1.
B. Bidulock Version 0.6 Page 74
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 2.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| OUT-OF-SERVICE -----------------> |
| PROCESSOR-RECOVERED -----------------> |
| PROCESSOR-OUTAGE -----------------> |
| BUSY_ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| READY -----------------> |
| DATA-ACK --FFFFFF, FFFFFF-> |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :clear emergency |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.2.2-1. Unexpected events while "not aligned"
Test Description:
(1) The test begins with both M2PA peers in the "Out of Service"
state with the IUT set to perform proving.
(2) The Level 3 "Start" command is issued to IUT to place the IUT
in the "Not Aligned" state.
(3) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Out of Service"
- Status "Processor Recovered"
- Status "Processor Outage"
- Status "Busy Ended"
- Status "Busy"
- Status "Ready"
- Status Invalid
- Data Ack
- Data
B. Bidulock Version 0.6 Page 75
Internet Draft M2PA-TEST October 16, 2005
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
(4) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Clear Emergency" command
- Level 3 "Start" command
(5) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(6) A status "Alignment" is then sent to the IUT.
(7) Check that the IUT aligns as usual and performs the normal
alignment procedures. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(8) Check that the IUT places the link in service and that no local
or remote processor outage indications are given to Level 3 at
the IUT.
3.2.3. Unexpected signal units/orders in "Aligned" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 request and receipt of unexpected M2PA messages
while in the "Aligned" state. All of the unexpected sequences in this
test case MUST be ignored by the IUT. The expected sequence of events
is illustrated in Figure 3.2.3-1.
B. Bidulock Version 0.6 Page 76
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 2.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| ALIGNMENT -----------------> |
| PROCESSOR-RECOVERED -----------------> |
| PROCESSOR-OUTAGE -----------------> |
| BUSY-ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| READY -----------------> |
| DATA-ACK --FFFFFF, FFFFFF-> |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :clear emergency |
| :start |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.2.3-1. Unexpected events while "aligned"
Test Description:
(1) The test begins with both IUT and PT in the "Out of Service"
state with the IUT set to perform proving.
(2) The IUT is brought to the "Aligned" state using normal
procedures.
(3) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Alignment"
- Status "Processor Recovered"
- Status "Processor Outage"
- Status "Busy Ended"
- Status "Busy"
- Status "Ready"
- Status Invalid
- Data Ack
B. Bidulock Version 0.6 Page 77
Internet Draft M2PA-TEST October 16, 2005
- Data
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
(4) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Clear Emergency" command
- Level 3 "Start" command
(5) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(6) Check that the IUT aligns as usual and performs the normal
alignment procedure. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(7) Check that the IUT places the link in service and that no local
or remote processor outage indications are given to Level 3 at
the IUT.
3.2.4. Unexpected signal units/orders in "Proving" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 request and receipt of unexpected M2PA messages
while in the "Proving" state. All of the unexpected sequences in this
test case MUST be ignored by the IUT. The expected sequence of events
is illustrated in Figure 3.2.4-1.
B. Bidulock Version 0.6 Page 78
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 2.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| PROCESSOR-RECOVERED -----------------> |
| PROCESSOR-OUTAGE -----------------> |
| BUSY-ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| READY -----------------> |
| DATA-ACK --FFFFFF, FFFFFF-> |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :clear emergency |
| :start |
| <----------------- READY |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.2.4-1. Unexpected events while "proving"
Test Description:
(1) The test begins with both IUT and PT in the "Out of Service"
state with the IUT set to perform proving.
(2) The IUT is brought to the "Proving" state using normal
procedures.
(3) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Processor Recovered"
- Status "Processor Outage"
- Status "Busy Ended"
- Status "Busy"
- Status "Ready"
- Status Invalid
- Data Ack
- Data
- M2PA Message with Invalid Message Class
B. Bidulock Version 0.6 Page 79
Internet Draft M2PA-TEST October 16, 2005
- M2PA Message with Invalid Message Type
(4) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Clear Emergency" command
- Level 3 "Start" command
(5) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(6) Check that the IUT aligns as usual and performs the normal
alignment procedure. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(7) Check that the IUT places the link in service and that no local
or remote processor outage indications are given to Level 3 at
the IUT.
3.2.5. Unexpected signal units/orders in "Aligned Ready" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 request and receipt of unexpected M2PA messages
while in the "Aligned Ready" state. All of the unexpected sequences
in this test case MUST be ignored by the IUT. The expected sequence
of events is illustrated in Figure 3.2.5-1.
B. Bidulock Version 0.6 Page 80
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 2.5
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| PROCESSOR-RECOVERED -----------------> |
| BUSY-ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :set emergency |
| :clear emergency |
| :clear lpo |
| :start |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.2.5-1. Unexpected events while "aligned ready"
Test Description:
(1) The test begins with both IUT and PT in the "Out of Service"
state with the IUT set to perform proving.
(2) The IUT is brought to the "Aligned Ready" state using normal
procedures.
(3) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Processor Recovered"
- Status "Busy Ended"
- Status "Busy"
- Status Invalid
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
(4) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
B. Bidulock Version 0.6 Page 81
Internet Draft M2PA-TEST October 16, 2005
- Level 3 "Set Emergency" command
- Level 3 "Clear Emergency" command
- Level 3 "Clear Local Processor Outage" command
- Level 3 "Start" command
(5) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(6) Check that the IUT aligns as usual and performs the normal
alignment procedure. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(7) Check that the IUT places the link in service and that no local
or remote processor outage indications are given to Level 3 at
the IUT.
3.2.6. Unexpected signal units/orders in "Aligned Not Ready" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 request and receipt of unexpected M2PA messages
while in the "Aligned Not Ready" state. All of the unexpected
sequences in this test case MUST be ignored by the IUT. The expected
sequence of events is illustrated in Figure 3.2.6-1.
B. Bidulock Version 0.6 Page 82
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 2.6
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| PROCESSOR-RECOVERED -----------------> |
| BUSY-ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :set emergency |
| :clear emergency |
| :set lpo |
| :start |
| READY -----------------> |
| !in service |
| |
|___________________________________________________________________|
Figure 3.2.6-1. Unexpected events while "aligned not ready"
Test Description:
(1) The test begins with both IUT and PT in the "Out of Service"
state with the IUT set to perform proving.
(2) The IUT is brought to the "Aligned Not Ready" state using
normal procedures. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(3) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Processor Recovered"
- Status "Busy Ended"
- Status "Busy"
- Status Invalid
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
B. Bidulock Version 0.6 Page 83
Internet Draft M2PA-TEST October 16, 2005
(4) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Set Emergency" command
- Level 3 "Clear Emergency" command
- Level 3 "Set Local Processor Outage" command
- Level 3 "Start" command
(5) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(6) Check that the IUT places the link in service.
3.2.7. Unexpected signal units/orders in "In Service" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 request and receipt of unexpected M2PA messages
while in the "In Service" state. All of the unexpected sequences in
this test case MUST be ignored by the IUT. The expected sequence of
events is illustrated in Figure 3.2.7-1.
Reference: Q.781/Test 2.7
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| PROCESSOR-RECOVERED -----------------> |
| BUSY-ENDED -----------------> |
| [INVALID-STATUS] -----------------> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :set emergency |
| :clear emergency |
| :clear lpo |
| :start |
| |
|___________________________________________________________________|
Figure 3.2.7-1. Unexpected events while "in service"
Test Description:
(1) The test begins with both IUT and PT in the "In Service" state.
(2) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Processor Recovered"
- Status "Busy Ended"
- Status Invalid
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
B. Bidulock Version 0.6 Page 84
Internet Draft M2PA-TEST October 16, 2005
(3) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Set Emergency" command
- Level 3 "Clear Emergency" command
- Level 3 "Clear Local Processor Outage" command
- Level 3 "Start" command
(4) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(5) Check that the IUT retains the link in the in service state and
that no local or remote processor outage indications are given
to Level 3 at the IUT.
3.2.8. Unexpected signal units/orders in "Processor Outage" state
This case validates the response of the IUT to the receipt of
unexpected Level 3 request and receipt of unexpected M2PA messages
while in the "Processor Outage" state. All of the unexpected
sequences in this test case MUST be ignored by the IUT. The expected
sequence of events is illustrated in Figure 3.2.8-1.
Reference: Q.781/Test 2.8
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| PROCESSOR-RECOVERED -----------------> |
| BUSY-ENDED -----------------> |
| BUSY -----------------> |
| [INVALID-STATUS] -----------------> |
| [INVALID-CLASS] -----------------> |
| [INVALID-TYPE] -----------------> |
| :set emergency |
| :clear emergency |
| :start |
| READY -----------------> |
| PROCESSOR-RECOVERED -----------------> |
| BUSY-ENDED -----------------> |
| |
|___________________________________________________________________|
Figure 3.2.8-1. Unexpected events while "processor outage"
Test Description:
(1) The test begins with both IUT and PT in the "In Service" state.
B. Bidulock Version 0.6 Page 85
Internet Draft M2PA-TEST October 16, 2005
(2) The IUT is brought to the "Processor Outage" state using normal
procedures.
(3) A sequence of unexpected M2PA messages are sent to the IUT.
These unexpected messages are:
- Status "Processor Recovered"
- Status "Busy Ended"
- Status "Busy"
- Status "Ready"
- Status Invalid
- M2PA Message with Invalid Message Class
- M2PA Message with Invalid Message Type
(4) A sequence of unexpected Level 3 commands are issued at the
IUT. These unexpected Level 3 commands are:
- Level 3 "Set Emergency" command
- Level 3 "Clear Emergency" command
- Level 3 "Start" command
(5) Check that the IUT ignores the unexpected M2PA messages/Level 3
commands.
(6) Check that the IUT keeps the link in service and that no local
or remote processor outage indications are given to Level 3 at
the IUT.
3.3. Transmission Failure
This set of test cases validate specific transmission path failures
and anomalies. Specifically transmission path failures, corrupt
acknowledgments and invalid sequencing. Because SCTP does not have a
transmission path that is separate from a receive path, the Q.781
tests that validate response to breaking the transmission path are
simulated by aborting the association. Because M2PA does not have
forward indicator bits, the Q.781 tests that validate response to
abnormal forward indicator bits are simulated by invalid "Data Ack"
messages.
3.3.1. Link aligned ready (Abort)
This case validates the response of the IUT to aborting the SCTP
association when the IUT is in the "Aligned Ready" state. The
expected sequence of events is illustrated in Figure 3.3.1-1.
B. Bidulock Version 0.6 Page 86
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 3.1
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- READY |
| :tx break |
| !out of service(SUERM) |
| |
|___________________________________________________________________|
Figure 3.3.1-1. Link aligned ready (Abort)
Test Description:
(1) The test begins with both IUT and PT in the "Out of Service"
state with the IUT set to perform proving.
(2) Issue a Level 3 "Start" command at the IUT and the PT.
(3) Check that the IUT follows the sequence of events illustrated
in Figure 3.3.1-1. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) When the IUT sends a status "Ready" message, abort the SCTP
association.
(5) Check that the IUT indicates "Out of Service" to Level 3 at the
IUT with reason "Excessive error rate SUERM" and stays in the
"Out of Service" state.
3.3.2. Link aligned ready (Corrupt FIBs)
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.3.2-1.
B. Bidulock Version 0.6 Page 87
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 3.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.3.2-1. Not applicable
Test Description:
(1) Not applicable.
3.3.3. Link aligned not ready (Abort)
This test case validates the response of the IUT to aborting the
SCTP association when the IUT is in the "Aligned Not Ready" state.
The expected sequence of events is illustrated in Figure 3.3.3-1.
Reference: Q.781/Test 3.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| :set lpo |
| :start |
| <----------------- ALIGNMENT |
| :start |
| ALIGNMENT -----------------> |
| <----------------- PROVING-NORMAL |
| PROVING-NORMAL -----------------> |
| <----------------- PROCESSOR-OUTAGE |
| :tx break |
| !out of service(SUERM) |
| |
|___________________________________________________________________|
Figure 3.3.3-1. Link aligned not ready (Abort)
Test Description:
(1) The test begins with both PT and IUT in the "Out of Service"
state with the IUT set to perform proving.
(2) Issue the Level 3 "Set Local Processor Outage" and "Start"
commands at the IUT and the "Start" command at the PT.
B. Bidulock Version 0.6 Page 88
Internet Draft M2PA-TEST October 16, 2005
(3) Check that the IUT follows the sequence of events illustrated
in Figure 3.3.3-1. (Note that the IUT may send additional
status "Out of Service," "Alignment" or "Proving Normal"
messages.)
(4) When the IUT sends a status "Processor Outage" message, abort
the SCTP association.
(5) Check that the IUT indicates "Out of Service" to Level 3 at the
IUT with reason "Excessive Error Rate/SUERM" and stays in the
"Out of Service" state.
3.3.4. Link aligned not ready (Corrupt FIBs)
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.3.4-1.
Reference: Q.781/Test 3.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.3.4-1. Not applicable
Test Description:
(1) Not applicable.
3.3.5. Link in service (Abort)
The expected sequence of events is illustrated in Figure 3.3.5-1.
Reference: Q.781/Test 3.5
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| :tx break |
| !out of service(SUERM) |
| |
|___________________________________________________________________|
Figure 3.3.5-1. Link in service (Abort)
Test Description:
B. Bidulock Version 0.6 Page 89
Internet Draft M2PA-TEST October 16, 2005
(1) The test begins with the link in the "In Service" state.
(2) Abort the SCTP association.
(3) Check that SP A indicates "Out of Service" to Level 3 at SP A
with reason "Excessive Error Rate/SUERM" and stays in the "Out
of Service" state.
3.3.6. Link in service (Corrupt FIBs)
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.3.6-1.
Reference: Q.781/Test 3.6
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.3.6-1. Not applicable
Test Description:
(1) Not applicable.
3.3.7. Link in processor outage (Abort)
This test case validates the response of the IUT to aborting the
SCTP association when the IUT is in the "Processor Outage" state. The
expected sequence of events is illustrated in Figure 3.3.7-1.
Reference: Q.781/Test 3.7
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| :tx break |
| !out of service(SUERM) |
| |
|___________________________________________________________________|
Figure 3.3.7-1. Link in processor outage (Abort)
Test Description:
B. Bidulock Version 0.6 Page 90
Internet Draft M2PA-TEST October 16, 2005
(1) The test begins with the link in the "In Service" state.
(2) Issues the Level 3 "Set Local Processor Outage" command at SP
A.
(3) Check that SP A sends a status "Processor Outage" message.
(4) Abort the SCTP association.
(5) Check that SP A indicates "Out of Service" to Level 3 at SP A
with reason "Excessive Error Rate/SUERM" and stays in the "Out
of Service" state.
3.3.8. Link in processor outage (Corrupt FIBs)
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.3.8-1.
Reference: Q.781/Test 3.8
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.3.8-1. Not applicable
Test Description:
(1) Not applicable.
3.4. Processor Outage Control
3.4.1. Set and clear LPO while link in service
This test case validates the response of the IUT to a local
processor outage condition and recovery with buffer clearing.
3.4.1.1. Forward Direction
This test is in the forward direction, where the IUT suffers local
processor outage. The expected sequence of events is illustrated in
Figure 3.4.1-1.
B. Bidulock Version 0.6 Page 91
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 4.1
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :msu |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| :set lpo |
| [ 35 bytes] DATA --000001, FFFFFF-> |
| <-000000, 000000-- DATA-ACK |
| <-000000, 000001-- DATA [ 35 bytes] |
| DATA-ACK --000001, 000000-> |
| <-000000, 000001-- PROCESSOR-OUTAGE |
| [ 35 bytes] DATA --000002, 000000-> |
| !msu |
| :clear buffers |
| :clear lpo |
| :msu |
| <-000000, 000001-- PROCESSOR-RECOVERED |
| [ 35 bytes] DATA --000003, 000000-> |
| READY --000000, 000000-> |
| [ 35 bytes] DATA --000001, 000000-> |
| <-000000, 000001-- DATA [ 35 bytes] |
| DATA-ACK --000001, 000001-> |
| <-000001, 000001-- DATA-ACK |
| !msu |
| |
|___________________________________________________________________|
Figure 3.4.1-1. Set and clear LPO while link in service
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send one data mesage from SP B to SP A.
(3) Send two MSUs from SP A, issue a Level 3 "Set Local Processor
Outage" command at SP A, and send another MSU from SP A.
(4) Send another data message from SP B to SP A and acknowledge the
first data message sent from SP A.
(5) Check that SP A sends two Data messages and acknowledges one
data message before sending a status "Processor Outage"
message.
(6) Check that the second data message sent after "Set Local
Processor Outage" was asserted is not acknowledged or
indicated.
B. Bidulock Version 0.6 Page 92
Internet Draft M2PA-TEST October 16, 2005
(7) Upon receiving a status "Processor Outage" message from SP A,
send another data message to SP A from SP B.
(8) Check that this last message is neither acknolwedged by nor
indicated at SP A.
(9) Issue Level 3 "Clear Buffers" and Level 3 "Clear Local
Processor Outage" commands at SP A and send another MSU from SP
A.
(10) Check that SP A sends a statu "Processor Outage Ended" message.
(11) Send another data message to SP A and send a status "Ready"
message from SP B to SP A with the appropriate sequence
numbers.
(12) Check that the message sent before status "Ready" is neither
acknolwedged by nor indicated at SP A.
(13) Send another data message to SP A.
(14) Check that SP A and SP B exchange this last set of data
messages and acknowledgements.
3.4.1.2. Reverse Direction
This test is in the reverse direction, where the IUT suffers remote
processor outage. The expected sequence of events is illustrated in
Figure 3.4.1-2.
B. Bidulock Version 0.6 Page 93
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 4.1
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :msu |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| <-000000, 000000-- DATA-ACK |
| <-000000, 000001-- DATA [ 35 bytes] |
| DATA-ACK --000000, 000000-> |
| PROCESSOR-OUTAGE --000001, 000000-> |
| [ 35 bytes] DATA --000001, 000000-> |
| :msu |
| <-000001, 000001-- DATA-ACK |
| !msu |
| !rpo |
| !msu |
| PROCESSOR-RECOVERED --000001, 000000-> |
| [ 35 bytes] DATA --000002, 000000-> |
| <-000001, 000000-- READY |
| <-000001, 000001-- DATA [ 35 bytes] |
| DATA-ACK --000001, 000001-> |
| <-000002, 000001-- DATA-ACK |
| !rpr |
| !msu |
| |
|___________________________________________________________________|
Figure 3.4.1-2. Set and clear LPO while link in service
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send two data messages from SP A to SP B and one data message
from SP B to SP A.
(3) Check that SP A acknowledges the data message sent from SP B to
SP A.
(4) Send a "Data Ack" message from SP B to SP A acknolwedging the
first data message and send a status "Processor Outage"
message.
(5) Send another data message from SP B to SP A and send another
MSU from SP A to SP B (during the processor outage period).
(6) Check that SP A acknolwedges the data message sent to it during
the processor outage period.
B. Bidulock Version 0.6 Page 94
Internet Draft M2PA-TEST October 16, 2005
(7) Check that SP A does not issue a data message for the MSU
requested at SP A after receipt of status "Processor Outage".
(8) Check that SP A indicates both MSUs and "Remote Processor
Outage" to Level 3.
(9) Wait for T7 to ensure that SP A does not require
acknowledgement to the data message sent before processor
outage was invoked.
(10) Send a status "Processor Recovered" message to SP A.
(11) Check that SP A responds with a status "Ready" message and
indicates "Remote Processor Recovered" to Level 3.
(12) Check that SP A sends a data message for the MSU that was
requested during processor outage.
(13) Send a "Data Ack" message to SP A to acknowledge the data
message.
(14) Send a data message to SP A.
(15) Check that SP A acknolwedges the data message with a "Data Ack"
message with the appropriate sequence numbers.
3.4.2. RPO during LPO
This test case validates the response of the IUT to receiving a
status "Processor Outage" message and status "Processor Recovered"
message while in the "Processor Outage" state with LPO set at the IUT.
The expected sequence of events is illustrated in Figure 3.4.2-1.
Reference: Q.781/Test 4.2
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| set lpo: |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| clear lpo: |
| PROCESSOR-RECOVERED -----------------> |
| <----------------- READY |
| !rpr |
| |
|___________________________________________________________________|
Figure 3.4.2-1. RPO during LPO
B. Bidulock Version 0.6 Page 95
Internet Draft M2PA-TEST October 16, 2005
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue a Level 3 "Set Local Processor Outage" command at SP A.
(3) Check that SP A sends a status "Processor Outage" message.
(4) Issue a Level 3 "Set Local Processor Outage" command at SP B
and send a status "Processor Outage" message to SP A.
(5) Check that SP A indicates "Remote Processor Outage" to Level 3
at SP A.
(6) Issue a level 3 "Clear Local Processor Outage" command at SP B
and send a status "Processor Recovered" message to SP A.
(7) Check that SP A sends a status "Ready" message in the data
stream and indicates "Remote Processor Recovered" to Level 3 at
SP A.
3.4.3. Clear LPO when "Both processor outage"
This test case validates the response of the IUT to the receipt of a
Level 3 "Clear Local Processor Outage" command when the IUT is in the
"Processor Outage" state with both processors marked PO. The expected
sequence of events is illustrated in Figure 3.4.3-1.
Reference: Q.781/Test 4.3
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| :set lpo |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| :clear lpo |
| <----------------- PROCESSOR-RECOVERED |
| READY -----------------> |
| !rpo |
| :clear lpo |
| PROCESSOR-RECOVERED -----------------> |
| <----------------- READY |
| !rpr |
| |
|___________________________________________________________________|
Figure 3.4.3-1. Clear LPO when "Both processor outage"
B. Bidulock Version 0.6 Page 96
Internet Draft M2PA-TEST October 16, 2005
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Issue a Level 3 "Set Local Processor Outage" command at SP A.
(3) Check that SP A sends a status "Processor Outage" message.
(4) Issue a Level 3 "Set Local Processor Outage" command at SP B
and send a status "Processor Outage" message to SP A.
(5) Check that SP A indicates "Remote Processor Outage" to Level 3
at SP A.
(6) Issue a Level 3 "Clear Local Processor Outage" command at SP A.
(7) Check that SP A sends a status "Processor Ended" message and SP
B sends a status "Ready" message.
(8) Issue a Level 3 "Clear Local Processor Outage" command at SP B
and send a status "Processor Recovered" message to SP A.
(9) Check that SP A sends a status "Ready" message, indicates
"Remote Processor Recovered" to Level 3 at SP A and remains in
the "In Service" state.
3.5. SU delimitation, alignment, error detection and correction
Most of the test cases in this section are not applicable to M2PA
operation.
3.5.1. More than 7 ones between MSU opening and closing flags
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.5.1-1.
Reference: Q.781/Test 5.1
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.5.1-1. Not applicable
Test Description:
(1) Not applicable.
B. Bidulock Version 0.6 Page 97
Internet Draft M2PA-TEST October 16, 2005
3.5.2. Greater than maximum signal unit length
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.5.2-1.
Reference: Q.781/Test 5.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.5.2-1. Not applicable
Test Description:
(1) Not applicable.
3.5.3. Below minimum signal unit length
This test case validates the IUT response to a Data message with a
payload below the minimum MSU length. The expected sequence of events
is illustrated in Figure 3.5.3-1.
Reference: Q.781/Test 5.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| [ 1 bytes] DATA --000000, FFFFFF-> |
| |
|___________________________________________________________________|
Figure 3.5.3-1. Below minimum signal unit length
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send a Data message with one byte of payload to the IUT.
(3) Check that the IUT does not acknowledge the Data message and
remains in the "In Service" state.
3.5.4. Reception of single and multiple flags between FISUs
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.5.4-1.
B. Bidulock Version 0.6 Page 98
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 5.4(a)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.5.4-1. Not applicable
Test Description:
(1) Not applicable.
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.5.4-2.
Reference: Q.781/Test 5.4(b)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.5.4-2. Not applicable
Test Description:
(1) Not applicable.
3.5.5. Reception of single and multiple flags between MSUs
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.5.5-1.
Reference: Q.781/Test 5.5(a)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.5.5-1. Not applicable
Test Description:
B. Bidulock Version 0.6 Page 99
Internet Draft M2PA-TEST October 16, 2005
(1) Not applicable.
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.5.5-2.
Reference: Q.781/Test 5.5(b)
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.5.5-2. Not applicable
Test Description:
(1) Not applicable.
3.6. SUERM check
The test cases in this section are not applicable to M2PA. These
tests might have corresponding tests at the SCTP layer, however, that
is the topic of an SCTP test specification rather than an M2PA test
specification.
3.6.1. Error rate of 1 in 256 - Link remains in service
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.6.1-1.
Reference: Q.781/Test 6.1
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.6.1-1. Not applicable
Test Description:
(1) Not applicable.
3.6.2. Error rate of 1 in 254 - Link out of service
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.6.2-1.
B. Bidulock Version 0.6 Page 100
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 6.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.6.2-1. Not applicable
Test Description:
(1) Not applicable.
3.6.3. Consecutive corrupt SUs
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.6.3-1.
Reference: Q.781/Test 6.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.6.3-1. Not applicable
Test Description:
(1) Not applicable.
3.6.4. Time controlled break of the link
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.6.4-1.
Reference: Q.781/Test 6.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.6.4-1. Not applicable
B. Bidulock Version 0.6 Page 101
Internet Draft M2PA-TEST October 16, 2005
Test Description:
(1) Not applicable.
3.7. AERM check
The test cases in this section are not applicable to M2PA. These
test might have corresponding test at the SCTP layer, however, that is
the topic of an SCTP test specification rather than an M2PA test
specification.
3.7.1. Error rate below the normal threshold
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.7.1-1.
Reference: Q.781/Test 7.1
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.7.1-1. Not applicable
Test Description:
(1) Not applicable.
3.7.2. Error rate at the normal threshold
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.7.2-1.
Reference: Q.781/Test 7.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.7.2-1. Not applicable
Test Description:
(1) Not applicable.
B. Bidulock Version 0.6 Page 102
Internet Draft M2PA-TEST October 16, 2005
3.7.3. Error rate above the normal threshold
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.7.3-1.
Reference: Q.781/Test 7.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.7.3-1. Not applicable
Test Description:
(1) Not applicable.
3.7.4. Error rate at the emergency threshold
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.7.4-1.
Reference: Q.781/Test 7.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.7.4-1. Not applicable
Test Description:
(1) Not applicable.
3.8. Transmission and reception control (Basic)
A number of test cases in this section are not applicable to M2PA.
Some may be the topic of a test specification for SCTP but are not
applicable to M2PA. Test cases that are applicable in this section
validate the basic transmission, reception and acknowledgments of Data
messages with status "Data Ack" messages.
3.8.1. Data transmission and reception
This test case validates the IUT response to the sending and receipt
of Data and "Data Ack" messages. The expected sequence of events is
B. Bidulock Version 0.6 Page 103
Internet Draft M2PA-TEST October 16, 2005
illustrated in Figure 3.8.1-1.
Reference: Q.781/Test 8.1
___________________________________________________________________
| |
| CPT: IOT: SP B SP A |
| VAT: PT IUT |
| |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| <-000000, FFFFFF-- DATA-ACK |
| !msu |
| :msu |
| <-000000, 000000-- DATA [ 35 bytes] |
| DATA-ACK --000000, 000000-> |
| |
|___________________________________________________________________|
Figure 3.8.1-1. Data transmission and reception
Test Description:
(1) This test begins with the link in the "In Service" state.
(2) Send a Data message to SP A.
(3) Check that SP A sends a "Data Ack" message acknowledging the
received Data message and delivers the received MSU to Level 3
at SP A.
(4) Issue a Level 3 MSU to SP A.
(5) Check that SP A sends a Data message.
(6) Send a "Data Ack" message to SP A acknowledging the data
message.
(7) Check that SP A receives the acknowledgments by waiting longer
than time T7 and ensuring that SP A stays in the "In Service"
state.
3.8.2. Negative acknowledgments of an MSU
M2PA does not perform negative acknowledgments at the M2PA layer.
Negative acknowledgments are performed as necessary by the underlying
SCTP transport. As such, test cases involving negative
acknowledgments are not applicable. The expected sequence of events
is illustrated in Figure 3.8.2-1.
B. Bidulock Version 0.6 Page 104
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.8.2-1. Not Applicable
Test Description:
(1) Not applicable.
3.8.3. Check RTB full
This test case validates the IUT response to an RTB full condition
at the IUT. The expected sequence of events is illustrated in Figure
3.8.3-1.
Reference: Q.781/Test 8.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :msu |
| :msu |
| :msu |
| . |
| . |
| . |
| Ct= 254 |
| |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| <-FFFFFF, 000001-- DATA [ 35 bytes] |
| <-FFFFFF, 000002-- DATA [ 35 bytes] |
| . |
| . |
| . |
| Ct= 127 |
| DATA-ACK --FFFFFF, 00007F-> |
| <-FFFFFF, 000080-- DATA [ 35 bytes] |
| <-FFFFFF, 000081-- DATA [ 35 bytes] |
| <-FFFFFF, 000082-- DATA [ 35 bytes] |
| . |
| . |
| . |
| Ct= 127 |
| DATA-ACK --FFFFFF, 0000FE-> |
| |
|___________________________________________________________________|
B. Bidulock Version 0.6 Page 105
Internet Draft M2PA-TEST October 16, 2005
Figure 3.8.3-1. Check RTB full
Test Description:
(1) This test begins with the link in the "In Service" state.
(2) Send 2 x N2 MSUs at the IUT.
(3) Check that the IUT sends N2 Data messages and then stops
sending Data messages (RTB Full condition).
(4) Acknowledge the N2 Data messages in a single "Data Ack"
message.
(5) Check that the IUT sends another N2 Data messages.
(6) Acknowledge the N2 Data messages in a single "Data Ack"
message.
(7) Check that the IUT remains in the "In Service" state longer
than time T7.
3.8.4. Single invalid Ack
This test case validates the response of the IUT to a single invalid
"Data Ack" message. The expected sequence of events is illustrated in
Figure 3.8.4-1.
Reference: Q.781/Test 8.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| DATA-ACK --FFFFFF, FFFFFF-> |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| DATA-ACK --FFFFFF, 000000-> |
| [ 35 bytes] DATA --000000, 000000-> |
| <-000000, 000000-- DATA-ACK |
| !msu |
| |
|___________________________________________________________________|
Figure 3.8.4-1. Single invalid Ack
Test Description:
(1) This test begins with the link in the "In Service" state.
(2) Send an invalid "Data Ack" message to the IUT.
B. Bidulock Version 0.6 Page 106
Internet Draft M2PA-TEST October 16, 2005
(3) Send an MSU at the IUT.
(4) Check that the IUT sends a Data message.
(5) Acknowledge the Data message with a "Data Ack" message to the
IUT
(6) Send an Data message to the IUT.
(7) Check that the IUT acknowledges the Data message with a "Data
Ack" message and delivers an MSU to Level 3 at the IUT.
3.8.5. Duplicated FSN
This test validates the response of the IUT to a single Data message
which has a repeated Forward Sequence Number. The expected sequence
of events is illustrated in Figure 3.8.5-1.
Reference: Q.781/Test 8.5
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| <-000000, FFFFFF-- DATA-ACK |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| !msu |
| [ 35 bytes] DATA --000001, FFFFFF-> |
| <-000001, FFFFFF-- DATA-ACK |
| !msu |
| |
|___________________________________________________________________|
Figure 3.8.5-1. Duplicated FSN
Test Description:
(1) This test begins with the link in the "In Service" state.
(2) Send an valid Data message to the IUT.
(3) Check that the IUT acknowledges the Data message and delivers
an M3U to Level 3 at the IUT.
(4) Send an invalid Data message that contains the same FSN as the
previous Data message to the IUT.
(5) Check that the IUT does not deliver an MSU to Level 3 at the
IUT.
(6) Send a valid Data message to the IUT.
B. Bidulock Version 0.6 Page 107
Internet Draft M2PA-TEST October 16, 2005
(7) Check that the IUT acknowledges the Data message and delivers
an M3U to Level 3 at the IUT.
(8) Check that the IUT maintains the "In Service" state.
3.8.6. Erroneous retransmission - Single MSU
Retransmission of DATA messages is performed by SCTP for M2PA and as
such the related Q.781 tests are not applicable. The expected
sequence of events is illustrated in Figure 3.8.6-1.
Reference: Q.781/Test 8.6
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.8.6-1. Not Applicable
Test Description:
(1) Not applicable.
3.8.7. Erroneous retransmission - Multiple FISUs
Retransmission of DATA messages is performed by SCTP for M2PA and as
such the related Q.781 tests are not applicable. The expected
sequence of events is illustrated in Figure 3.8.7-1.
Reference: Q.781/Test 8.7
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.8.7-1. Not Applicable
Test Description:
(1) Not applicable.
3.8.8. Single FISU with corrupt FIB
The expected sequence of events is illustrated in Figure 3.8.8-1.
B. Bidulock Version 0.6 Page 108
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.8
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.8.8-1. Not Applicable
Test Description:
(1) Not applicable.
3.8.9. In Service prior to RPO being set
3.8.9.1. Forward Direction
This test is for the forward direction where the PT suffers local
processor outage. The expected sequence of events is illustrated in
Figure 3.8.9-1.
Reference: Q.781/Test 8.9
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :msu |
| :set lpo |
| PROCESSOR-OUTAGE -----------------> |
| !rpo |
| [ 35 bytes] DATA --000000, FFFFFF-> |
| <-000000, FFFFFF-- DATA-ACK |
| !msu |
| :clear lpo |
| PROCESSOR-RECOVERED --000000, FFFFFF-> |
| <-000000, FFFFFF-- READY |
| !rpr |
| :msu |
| [ 35 bytes] DATA --000001, FFFFFF-> |
| <-000001, FFFFFF-- DATA-ACK |
| !msu |
| |
|___________________________________________________________________|
Figure 3.8.9-1. In service prior to RPO being set
Test Description:
B. Bidulock Version 0.6 Page 109
Internet Draft M2PA-TEST October 16, 2005
(1) The test beings with the link in the "In Service" state.
(2) Issue a Level 3 "Set Local Processor Outage" command at SP B
and send a status "Processor Outage" message to SP A.
(3) Check that SP A indicates "Remote Processor Outage" to Level 3
at SP A.
(4) Send one User Data message to SP A.
(5) Check that SP A acknowledges the Data message with a "Data Ack"
within timer T7 and that the MSU is delivered ot Level 3 at SP
A.
(6) Issue a Level 3 "Clear Local Processor Outage" command at SP B
and send a status "Processor Recovered" message to SP A.
(7) Check that SP A sends a status "Ready" message in the data
stream and indicates "Remote Processor Recovered" to Level 3 at
SP A.
(8) Send one User Data message to SP A.
(9) Check that SP A acknowledges the Data message with a "Data Ack"
and that the MSU is delivered to Level 3 at SP A.
(10) Check that SP A remains in the "In Service" state.
3.8.9.2. Reverse Direction
This test is for the reverse direction where the IUT suffers local
processor outage. The expected sequence of events is illustrated in
Figure 3.8.9-2.
B. Bidulock Version 0.6 Page 110
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.9
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| :set lpo |
| <----------------- PROCESSOR-OUTAGE |
| DATA-ACK --FFFFFF, 000000-> |
| :clear lpo |
| <-FFFFFF, 000000-- PROCESSOR-RECOVERED |
| READY --FFFFFF, 000001-> |
| :msu |
| <-FFFFFF, 000001-- DATA [ 35 bytes] |
| DATA-ACK --FFFFFF, 000001-> |
| |
|___________________________________________________________________|
Figure 3.8.9-2. In service prior to RPO being set
Test Description:
(1) The test beings with the link in the "In Service" state.
(2) Issue one MSU at SP A and then issue a Level 3 "Set Local
Processor Outage" command at SP A.
(3) Check that SP A sends a User Data message followed by a status
"Processor Outage" message.
(4) Send a "Data Ack" message from SP B acknowledging the User Data
message from SP A and issue a Level 3 "Clear Local Processor
Outage" command at SP A.
(5) Check that SP A sends a status "Processor Recovered" message
and that the FSN of the status "Processor Recovered" message is
the FSN of the acknowledged User Data message.
(6) Send a status "Ready" message to the IUT on the data stream.
(7) Issue one MSU at SP A.
(8) Check that SP A sends a User Data message and that the FSN of
the user data message is incremented by one from the FSN of the
status "Processor Recovered" message.
(9) Send a "Data Ack" message from SP B acknowledging the User Data
message from SP A.
(10) Check that SP A remains in the "In Service" state.
B. Bidulock Version 0.6 Page 111
Internet Draft M2PA-TEST October 16, 2005
3.8.10. Abnormal BSN - single Data message
This test validates the behavior of the IUT to receiving a single
abnormal Backward Sequence Number in a Data message. The expected
sequence of events is illustrated in Figure 3.8.10-1.
Reference: Q.781/Test 8.10
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| [ 35 bytes] DATA --000000, 7FFFFF-> |
| <-000000, FFFFFF-- DATA-ACK |
| !msu |
| [ 35 bytes] DATA --000001, FFFFFF-> |
| <-000001, FFFFFF-- DATA-ACK |
| !msu |
| |
|___________________________________________________________________|
Figure 3.8.10-1. Abnormal BSN - single Data message
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send a Data message to the IUT with an abnormal Backward
Sequence Number.
(3) Check that the IUT acknowledges the Data message delivers an
MSU to Level 3 at the IUT.
(4) Send a Data message to the IUT with an normal Backward Sequence
Number.
(5) Check that the IUT acknowledges the Data message delivers an
MSU to Level 3 at the IUT.
(6) Check that the IUT maintains the "In Service" state.
3.8.11. Abnormal BSN - two consecutive messages
This test validates the reponse of the IUT to receiving two
consecutive abnormal Backward Sequence Numbers. The expected sequence
of events is illustrated in Figure 3.8.11-1.
B. Bidulock Version 0.6 Page 112
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.11
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| DATA-ACK --FFFFFF, 7FFFFF-> |
| DATA-ACK --FFFFFF, 7FFFFF-> |
| DATA-ACK --FFFFFF, FFFFFF-> |
| <----------------- OUT-OF-SERVICE |
| !out of service |
| |
|___________________________________________________________________|
Figure 3.8.11-1. Abnormal BSN - two consecutive messages
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send two "Data Ack" messages with an abnormal Backward Sequence
Number.
(3) Send a "Data Ack" message with an normal Backward Sequence
Number.
(4) Check that the IUT responds with a status "Out of Service"
message and indicates "Out of Service" to Level 3 at the IUT.
3.8.12. Excessive delay of acknowledgments
This test case validates the IUT response to a excessively delayed
acknowledgment.
3.8.12.1. Excessive delay of acknowledgment (single Data)
This test checks excessive delay of acknowledgment where a single
User Data message is sent. The expected sequence of events is
illustrated in Figure 3.8.12-1.
B. Bidulock Version 0.6 Page 113
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.12
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| ! |
| ! T7 0.5 <= T7 <= 2.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T7) |
| |
|___________________________________________________________________|
Figure 3.8.12-1. Excessive delay of acknowledgments
Test Description:
(1) This test case begins with the link in the "In Service" state.
(2) Send an MSU from the IUT.
(3) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at the IUT with reason
"T7 Timeout" and that the link remains in the "Out of Service"
state.
(4) Check that the T7 is between 0.5 seconds and 2.0 seconds in
duration.
3.8.12.2. Excessive delay of acknowledgment (multiple Data)
This test checks excessive delay of acknowledgment where a multiple
User Data messages are sent. Unlike MTP2 [Q.703, T1.111] requires
that the excessive delay of acknowledgment timer T7 expire when the
oldest unacknowledged User Data message is over T7 old. This test
sends User Data messages while T7 is running to ensure that the IUT
does not restart T7 on the receipt of User Data. The expected
sequence of events is illustrated in Figure 3.8.12-2.
B. Bidulock Version 0.6 Page 114
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.12
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| ! |
| ! T7 0.5 <= T7 <= 2.0 |
| ! |
| <-FFFFFF, 000001-- DATA [ 35 bytes] |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T7) |
| |
|___________________________________________________________________|
Figure 3.8.12-2. Excessive delay of acknowledgments
Test Description:
(1) This test case begins with the link in the "In Service" state.
(2) Send an MSU from the IUT.
(3) Wait a short period less than T7 and then send another MSU from
the IUT.
(4) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at the IUT with reason
"T7 Timeout" and that the link remains in the "Out of Service"
state.
(5) Check that the T7 is between 0.5 seconds and 2.0 seconds in
duration starting from the oldest unacknowledged DATA message.
3.8.13. Level 3 Stop command
This test case validates the response of the IUT to the Level 3
"Stop" command while in the "In Service" state. The expected sequence
of events is illustrated in Figure 3.8.13-1.
B. Bidulock Version 0.6 Page 115
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 8.13
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :stop |
| <----------------- OUT-OF-SERVICE |
| OUT-OF-SERVICE -----------------> |
| <----------------- OUT-OF-SERVICE (Note) |
| (Note) OUT-OF-SERVICE -----------------> |
| |
|___________________________________________________________________|
Figure 3.8.13-1. Level 3 Stop command
Test Description:
(1) This test begins with the link in the "In Service" state.
(2) Issue the Level 3 "Stop" command at SP A.
(3) Check that SP A sends a status "Out of Service" message and
remains in the "Out of Service" state. (Note that SP A or B
may send additional status "Out of Service" messages.)
3.9. Transmission and Reception Control (PCR)
M2PA does not perform Preventative Cyclic Retransmission and,
therefore, the test cases in this section are not applicable to M2PA.
3.9.1. MSU transmission and reception
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.1-1.
Reference: Q.781/Test 9.1
___________________________________________________________________
| |
| CPT: SP B SP A |
| VAT: PT IUT |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.1-1. Not Applicable
Test Description:
(1) Not applicable.
B. Bidulock Version 0.6 Page 116
Internet Draft M2PA-TEST October 16, 2005
3.9.2. Priority control
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.2-1.
Reference: Q.781/Test 9.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.2-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.3. Forced retransmission with the value N1
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.3-1.
Reference: Q.781/Test 9.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.3-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.4. Forced retransmission with the value N2
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.4-1.
B. Bidulock Version 0.6 Page 117
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 9.4
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.4-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.5. Forced retransmission cancel
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.5-1.
Reference: Q.781/Test 9.5
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.5-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.6. Reception of forced retransmission
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.6-1.
Reference: Q.781/Test 9.6
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.6-1. Not Applicable
B. Bidulock Version 0.6 Page 118
Internet Draft M2PA-TEST October 16, 2005
Test Description:
(1) Not applicable.
3.9.7. MSU transmission while RPO set
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.7-1.
Reference: Q.781/Test 9.7
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.7-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.8. Abnormal BSN - Single MSU
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.8-1.
Reference: Q.781/Test 9.8
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.8-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.9. Abnormal BSN - Two MSUs
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.9-1.
B. Bidulock Version 0.6 Page 119
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 9.9
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.9-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.10. Unexpected FSN
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.10-1.
Reference: Q.781/Test 9.10
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.10-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.11. Excessive delay of acknowledgments
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.11-1.
Reference: Q.781/Test 9.11
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.11-1. Not Applicable
B. Bidulock Version 0.6 Page 120
Internet Draft M2PA-TEST October 16, 2005
Test Description:
(1) Not applicable.
3.9.12. FISU with FSN expected for MSU
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.12-1.
Reference: Q.781/Test 9.12
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.12-1. Not Applicable
Test Description:
(1) Not applicable.
3.9.13. Level 3 Stop command
This test case is not applicable to M2PA. The expected sequence of
events is illustrated in Figure 3.9.13-1.
Reference: Q.781/Test 9.13
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| |
| NOT APPLICABLE |
|___________________________________________________________________|
Figure 3.9.13-1. Not Applicable
Test Description:
(1) Not applicable.
3.10. Congestion Control
3.10.1. Congestion abatement
This test case validates the response of the IUT to the Level 3
"Congestion" and "Congestion Ceases" conditions. The expected
sequence of events is illustrated in Figure 3.10.1-1.
B. Bidulock Version 0.6 Page 121
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 10.1
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :make cong discard |
| <----------------- BUSY |
| <----------------- BUSY (Note) |
| :clear congestion |
| <----------------- BUSY-ENDED |
| |
|___________________________________________________________________|
Figure 3.10.1-1. Congestion abatement
Test Description:
(1) This test begins with the link in the "In Service" state.
(2) Generate a local Level 3 "Congestion" condition at the IUT.
(3) Check that the IUT sends a status "Busy" message. (Note that
the IUT may send additional status "Busy" messages before
sending a status "Busy Ended" message.)
(4) Generate a local Level 3 "Congestion Ceases" condition at the
IUT.
(5) Check that the IUT sends a status "Busy Ended" message.
3.10.2. Timer T7
This test case validates timer T7 and procedures at the IUT.
3.10.2.1. Timer T7 during Receive Congestion
This test case validates that timer T7 will not expire during
receive congestion period. The expected sequence of events is
illustrated in Figure 3.10.2-1.
B. Bidulock Version 0.6 Page 122
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 10.2
___________________________________________________________________
| |
| IOT: SP B SP A |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| BUSY -----------------> |
| ! |
| ! T7 0.5 <= T7 <= 2.0 |
| ! |
| BUSY-ENDED -----------------> |
| DATA-ACK --FFFFFF, 000000-> |
| |
|___________________________________________________________________|
Figure 3.10.2-1. Timer T7
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send an MSU at SP A.
(3) Wait for longer than T7 (but less than T6) and then send a Link
Status "Busy Ended" message and acknowledge the User Data
message with a "Data Ack" message to SP A.
(4) Check that SP A sends no further status messages and remains in
the "In Service" state.
3.10.2.2. Timer T7 expiry after Receive Congestion
This test case validates that timer T7 will expire after receive
congestion period. The expected sequence of events is illustrated in
Figure 3.10.2-2.
B. Bidulock Version 0.6 Page 123
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 10.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| BUSY -----------------> |
| ! |
| ! T6 3.0 <= T6 <= 6.0 |
| ! |
| BUSY-ENDED -----------------> |
| ! |
| ! T7 0.5 <= T7 <= 2.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T7) |
| |
|___________________________________________________________________|
Figure 3.10.2-2. Timer T7
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send an MSU at the IUT.
(3) Wait for a period less than T6 (but longer than T7) and then
send a "Link Status Busy Ended" message not acknowledging the
User Data.
(4) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 at the IUT with reason
"T7 Timeout" and that the link remains in the "Out of Service"
state.
(5) Check that the T7 is between 0.5 seconds and 2.0 seconds in
duration.
3.10.2.3. Timer T7 after Receive Congestion
This test case validates timer T7 after the receive congestion
period. The expected sequence of events is illustrated in Figure
3.10.2-3.
B. Bidulock Version 0.6 Page 124
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 10.2
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| BUSY -----------------> |
| ! |
| ! T6 3.0 <= T6 <= 6.0 |
| ! |
| BUSY-ENDED -----------------> |
| ! |
| ! T7 0.5 <= T7 <= 2.0 |
| ! |
| DATA-ACK --FFFFFF, 000000-> |
| |
|___________________________________________________________________|
Figure 3.10.2-3. Timer T7
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send an MSU at the IUT.
(3) Wait for a period less than T6 (but longer than T7) and then
send a "Link Status Busy Ended" message not acknowledging the
User Data.
(4) Wait for less than T7 and then acknowledge the Data message to
the IUT with a "Data Ack" message.
(5) Check that the IUT sends no further status messages and remains
in the "In Service" state.
3.10.3. Timer T6
This case validates timer T6 and procedures at the IUT. The
expected sequence of events is illustrated in Figure 3.10.3-1.
B. Bidulock Version 0.6 Page 125
Internet Draft M2PA-TEST October 16, 2005
Reference: Q.781/Test 10.3
___________________________________________________________________
| |
| VAT: PT IUT |
| |
| :msu |
| <-FFFFFF, 000000-- DATA [ 35 bytes] |
| BUSY -----------------> |
| ! :msu |
| ! |
| ! T6 3.0 <= T6 <= 6.0 |
| ! |
| <----------------- OUT-OF-SERVICE |
| !out of service(T6) |
| |
|___________________________________________________________________|
Figure 3.10.3-1. Timer T6
Test Description:
(1) The test begins with the link in the "In Service" state.
(2) Send an MSU at the IUT.
(3) Send a status "Busy" messages to the IUT.
(4) Request another MSU at the IUT.
(5) Check that the IUT sends a status "Out of Service" message and
indicates "Out of Service" to Level 3 with reason "T6 Timeout"
and remains in the "Out of Service" state.
(6) Check that T6 is between 3.0 seconds and 6.0 seconds in
duration.
(7) Check that the IUT does not send the second MSU during the busy
period.
Security Considerations
Although this document does not introduce new security
considerations for M2PA, mention of the role of M2PA security measure
during tested is in order.
When the Validation, Compatibility and Interoperability tests in
this document are being performed, the test environment and
Implementations Under Test (IUT) MUST use the security measures
required in the Security section of the M2PA specification [M2PA]
while the tests are being performed. Test results without the
required security measures in place during testing will be of little
value for validating the behavior of an implementation for later
operation.
B. Bidulock Version 0.6 Page 126
Internet Draft M2PA-TEST October 16, 2005
IANA Considerations
There are no IANA considerations for this draft.
0. Change History
This section provides historical information on the changes made to
this draft. This section will be removed from the document when the
document is finalized.
0.6. Changes fron Version 0.5 to Version 0.6
(1) The test specification has been updated to the M2PA RFC [M2PA].
(2) Updated first page and last page IETF boiler plates.
0.5. Changes fron Version 0.4 to Version 0.5
(1) The test specification has been updated to M2PA Draft Revision
11 [M2PA11].
(2) Corrected error in test case 3.1.8: SP A should maintain the
"Processor Outage" state and not the "In Service" state.
(3) Added status "Ready" response to receipt of state "Processor
Recovered".
(4) Added sequence numbers to status "Ready" and status "Processor
Recovered" message because these status values are now
significant.
(5) Removed test case 3.8.14 because out of order FSNs are just
discarded instead of taking the link out of service.
(6) Made test case 3.3.2, 3.3.4, 3.3.6 and 3.3.8 not applicable
because out of order FSNs are discarded and invalid acks cannot
be generated.
(7) Some corrections to labeling.
(8) Added disclaimer to "Conventions" section.
(9) Minor spelling and typo corrections.
(10) Added description of the labeling of sequence numbers.
(11) Reworked test case 3.4.1(a) and 3.4.1(b) to test new sequence
number synchronization, acknowledgement and sending rules for
processor outage.
0.4. Changes from Version 0.3 to Version 0.4
(1) The test specification has been updated to M2PA Draft Revision
B. Bidulock Version 0.6 Page 127
Internet Draft M2PA-TEST October 16, 2005
9 [M2PA09].
(2) Split references into Normative and Informative.
(3) Updated acknowledgments to include those making comments on the
draft.
(4) Added section describing labeling of messages and primitives in
the diagrams.
(5) Expanded test environment description. Tests have been
identified for compatibility and interoperability testing.
(6) Added a test list showing which tests are applicable to
Validation, Compatibility and Interoperability testing.
(7) Added a Security section describing that M2PA security measures
must be in place during testing.
(8) M2PA Draft Revision 9 [M2PA09] uses normal initial sequence
numbers. Sequence numbers on all tests have been updated to
match.
(9) M2PA Draft Revision 9 [M2PA09] makes proving configurable.
Test cases have been added to 3.1.5, 3.1.6, 3.1.8, 3.1.9,
3.1.10, 3.1.11, 3.1.12, 3.1.13, 3.1.15, 3.1.16 and 3.1.27 to
test also the situation where the link is not configured for
proving.
(10) M2PA Draft Revision 9 [M2PA09] uses a flexible T7 timer that
times the age of the oldest unacknowledged data message in the
retransmission buffer. This is slightly different that MTP2
[Q.703, T1.111] behavior. A test case was added to 3.8.12
(Excessive delay of acknowledgment) to test this variation from
MTP2.
(11) M2PA Draft Revision 9 [M2PA09] has some problems with T6 and T7
timer handling. It is anticipated that changes will be made to
the T6 and T7 timer handling. Additions to test case 3.10.2
have been made in anticipation of these changes.
(12) PROCESSOR-OUTAGE-ENDED renamed to PROCESSOR-RECOVERED.
(13) M2PA Draft Revision 9 [M2PA09] has some problems with processor
outage handing. It is anticipated that changes will be made to
the processor outage handling on both sides. Addition or
changes to test cases 3.4.1 and 3.8.9 have been made in
anticipation of these changes.
(14) Link Status "Out of Service," "Alignment," "Ready," and
"Processor Outage" messages can be repeated until the condition
that caused them to be sent has cleared. Comments have been
added to test cases 3.1.1, 3.1.2, 3.1.4, 3.1.16, 3.8.13 and
3.10.1 to accommodate for this.
B. Bidulock Version 0.6 Page 128
Internet Draft M2PA-TEST October 16, 2005
(15) Link Status "Proving Normal" and "Proving Emergency" messages
are repeated at the proving interval. Notes have been added to
test cases performing proving to indicate that these messages
may be repeated.
(16) Added Link Status "Busy Ended" and "Processor Recovered" as
well as M2PA messages with invalid message class and message
type to test cases 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6,
3.2.7 and 3.2.8 to fully test unexpected message sequences.
(17) Added new test case 3.8.14 to test the situation where the IUT
receives an out of order forward sequence number.
For the most part, however, there have been few changes to the
actual test cases.
0.3. Changes from Version 0.2 to Version 0.3
(1) The test specification has been updated to M2PA Draft Revision
7 [M2PA07], with anticipated changes for M2PA Draft Revision 8
[M2PA08].
0.2. Changes from Version 0.1 to Version 0.2
(1) The test specification has been updated to M2PA Draft Revision
6 [M2PA06], with anticipated changes for M2PA Draft Revision 7
[M2PA07].
(2) M2PA Draft Revision 6 [M2PA06] provides for acknowledgment of
DATA messages using a special DATA message which contains no
data payload. This message has been labeled "DATA-ACK" in the
diagrams.
This has resulted in changes to test cases 1.6, 2.1, 2.2, 2.3,
2.4, 3.2, 3.4, 3.6, 3.8, 4.1, 8.1, 8.3, 8.4, 8.5, 8.9, 8.10,
8.11, 10.2
(3) Although M2PA Draft Revision 6 [M2PA06] specifies that the
DATA-ACK message should have its Forward Sequence Number (FSN)
incremented as with any other normal DATA message, this causes
problems in that the DATA-ACK MUST then be acknowledged. This
test specification anticipates M2PA Draft Revision 7 by not
incrementing FSN for DATA-ACK messages.
(4) M2PA Draft Revision 6 [M2PA06] provides FSN and BSN sequence
numbers in STATUS messages as well as DATA messages. It has
been proposed that STATUS messages not contain FSN and BSN
because they should essentially be ignored because of mis-
ordering possibilities. Therefore, FSN and BSN of STATUS
messages are ignored in this version of the test specification
in anticipation of M2PA Draft Revision 7.
0.1. Changes from Version 0.0 to Version 0.1
B. Bidulock Version 0.6 Page 129
Internet Draft M2PA-TEST October 16, 2005
(1) The test specification has been updated to M2PA Draft Revision
4 [M2PA04], with anticipated changes for M2PA Draft Revision 5
[M2PA05].
(2) M2PA Draft Revision 4 [M2PA04] no longer contains a special
proving message. Status PROVING-NORMAL or PROVING-EMERGENCY
messages are padded and sent repeatedly to accomplish proving
during the proving period. The occurrence of PROVING messages
has been removed from the test cases to update this draft to
match the M2PA draft revision 4 [M2PA04].
(3) M2PA Draft Revision 4 [M2PA04] contains both forward and
backward sequence numbers (FSN, BSN). The test cases were
updated to include the sequence numbers (where other than zero)
and test cases were added for abnormal backward sequence
numbers.
(4) M2PA Draft Revision 4 [M2PA04] has no formal method for
acknowledging the receipt of a DATA message when there are no
other messages to send (DATA or STATUS). The Status of "In
Service", for which no other use has been specified in the
current draft [M2PA04], is used as such an explicit
acknowledgment. Another possibility would have been to send a
DATA message with no data in it. The old "ACK" message is now
labeled "IN-SERVICE".
(5) The status message previously labeled "IN-SERVICE" has been
relabeled "READY" to better reflect the name of that status
message in the draft and to not conflict with the new [M2PA04]
"IN-SERVICE" status message.
B. Bidulock Version 0.6 Page 130
Internet Draft M2PA-TEST October 16, 2005
R. References
R.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119 - BCP 14, The Internet Society
(March 1997).
[M2PA] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 2
(MTP2)-User Peer-to-Peer Adaptation Layer (M2PA)," RFC 4165,
Internet Engineering Task Force - Signalling Transport Working
Group (September 2005).
[Q.781] ITU, "Signalling System No. 7 - MTP Level 2 Test
Specification," ITU-T Recommendation Q.781, ITU-T
Telecommunication Standardization Sector of ITU, Geneva (March
1993). (Previously "CCITT Recommendation")
[Q.703] ITU, "Signalling System No. 7 - Signalling Link," ITU-T
Recommendation Q.703, ITU-T Telecommunication Standardization
Sector of ITU, Geneva (March 1993). (Previously "CCITT
Recommendation")
[Q.780] ITU, "Signalling System No. 7 Test Specification -- General
Description," ITU-T Recommendation Q.780, ITU-T Telecommunication
Standardization Sector of ITU, Geneva (October 1995).
(Previously "CCITT Recommendation")
[Q.782] ITU, "Specifications of Signalling System No. 7 -- Test
Specification -- MTP Level 3 Test Specification," ITU-T
Recommendation Q.782, ITU-T Telecommunication Standardization
Sector of ITU, Geneva (July 1996). (Previously "CCITT
Recommendation")
R.2. Informative References
[T1.111] ANSI, "Signalling System No. 7 - Message Transfer Part,"
ANSI T1.111, American National Standards Institue (1992).
[EN 300 008-1] ETSI, "Integrated Services Digital Network (ISDN);
Signalling System No. 7; Protocol Specification," ETSI EN 300
008-1 V1.3.1 [REN/SPAN-01074-1], European Telecommunications
Standards Institute, Cedex (September 2000). (ITU-T
Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707
and Q.708, modified)
[JT-Q.703] TTC, "Message Transfer Part - Signalling Link," TTC
Standard JT-Q.703, Telecommunication Technology Committee (TTC)
(April 28, 1992).
[Q.2140] ITU, "B-ISDN ATM Adaptation Layer - Service Specific
Coordination Function for Signalling at the Network Node
B. Bidulock Version 0.6 Page 131
Internet Draft M2PA-TEST October 16, 2005
Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T
Telecommunication Standardization Sector of ITU, Geneva (February
1996). (Previously "CCITT Recommendation")
[T1.637] "Service Specific Connection-Oriented Protocol (SSCOP),"
ANSI T1.637/2000, American National Standards Institute (2000).
[ETS 300 336] ETSI, "Integrated Services Digital Network (ISDN);
Signalling System No. 7; Message Transfer Part (MTP); Test
Specification," ETSI ETS 300 336, European Telecommunications
Standards Institute, Valbonne (September 1996). (ITU-T
Recommendations Q.781 and Q.782 (1993), modified)
[Q.704] ITU, "Message Transfer Part - Signalling Network Functions
and Messages," ITU-T Recommendation Q.704, ITU-T
Telecommunication Standardization Sector of ITU, Geneva (March
1993). (Previously "CCITT Recommendation")
[M2PA11] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
Morneault, K., "SS7 MTP2-User Peer-to-Peer Adaptation Layer,"
<draft-ietf-sigtran-m2pa-11.txt>, Internet Engineering Task Force
- Signalling Transport Working Group (January 29, 2004). Work In
Progress.
[M2PA09] George, T., Bidulock, B., Dantu, R., Kalla, M.,
Schwarzbauer, H. J. and Morneault, K., "SS7 MTP2-User Peer-to-
Peer Adaptation Layer," <draft-ietf-sigtran-m2pa-09.txt>,
Internet Engineering Task Force - Signalling Transport Working
Group (June 29, 2003). Work In Progress.
[M2PA07] George, T., Bidulock, B., Dantu, R., Kalla, M.,
Schwarzbauer, H. J., Sidebottom, G. and Morneault, K., "SS7
MTP2-User Peer-to-Peer Adaptation Layer," <draft-ietf-sigtran-
m2pa-07.txt>, Internet Engineering Task Force - Signalling
Transport Working Group (January 17, 2003). Work In Progress.
[M2PA08] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
Morneault, K., "SS7 MTP2-User Peer-to-Peer Adaptation Layer,"
<draft-ietf-sigtran-m2pa-08.txt>, Internet Engineering Task Force
- Signalling Transport Working Group (April 22, 2003). Work In
Progress.
[M2PA06] George, T., Dantu, R., Kalla, M., Schwarzbauer, H. J.,
Sidebottom, G., Morneault, K. and Bidulock, B., "SS7 MTP2-User
Peer-to-Peer Adaptation Layer," <draft-ietf-sigtran-m2pa-06.txt>,
Internet Engineering Task Force - Signalling Transport Working
Group (August 28, 2002). Work In Progress.
[M2PA04] George, T., Dantu, R., Kalla, M., Schwarzbauer, H. J.,
Sidebottom, G. and Morneault, K., "SS7 MTP2-User Peer-to-Peer
Adaptation Layer," <draft-ietf-sigtran-m2pa-04.txt>, Internet
Engineering Task Force - Signalling Transport Working Group
(February 28, 2002). Work In Progress.
B. Bidulock Version 0.6 Page 132
Internet Draft M2PA-TEST October 16, 2005
[M2PA05] George, T., Dantu, R., Kalla, M., Schwarzbauer, H. J.,
Sidebottom, G., Morneault, K. and Bidulock, B., "SS7 MTP2-User
Peer-to-Peer Adaptation Layer," <draft-ietf-sigtran-m2pa-05.txt>,
Internet Engineering Task Force - Signalling Transport Working
Group (May 3, 2002). Work In Progress.
Acknowledgments
The author would like to thank Jeffrey Craig, Tom George and Tolga
Aversen for their valuable comments and suggestions.
Author's Addresses
Brian Bidulock
OpenSS7 Corporation
1469 Jeffreys Crescent
Edmonton, AB T6L 6T1
Canada
Phone: +1-780-490-1141
Email: [email protected]
URL: http//www.openss7.org/
This draft expires April 2006.
B. Bidulock Version 0.6 Page 133
Internet Draft M2PA-TEST October 16, 2005
List of Tables
Table 2.3.1-1. Recommended[1] IUT Timer Values .................. 9
Table 2.3.2-1. Recommended IUT Buffer Threshold Values .......... 9
Table 2.3.4-1. Labeling of Messages and Primitives .............. 10
Table 3-1. Test Case Applicability .............................. 12
List of Illustrations
Figure 2.1.1-1. Validation Test Configuration ................... 6
Figure 2.1.2-1. Compatibility Test Configuration ................ 7
Figure 3.1.1-1. Initialization (Power-up) ....................... 15
Figure 3.1.1-2. Initialization (Power-up) ....................... 16
Figure 3.1.2-1. Timer T2 ........................................ 17
Figure 3.1.3-1. Timer T3 ........................................ 18
Figure 3.1.4-1. Timer T1 & Timer T4 (Normal) .................... 19
Figure 3.1.5-1. Normal alignment procedure ...................... 20
Figure 3.1.5-2. Normal alignment procedure ...................... 21
Figure 3.1.5-3. Normal alignment procedure (without proving)
............................................................... 22
Figure 3.1.5-4. Normal alignment procedure (without proving)
............................................................... 23
Figure 3.1.6-1. Normal alignment procedure (Data) with proving
............................................................... 24
Figure 3.1.6-2. Normal alignment procedure (Data) without
proving ....................................................... 25
Figure 3.1.7-1. "Alignment" during normal proving ............... 26
Figure 3.1.8-1. Normal alignment with PO set .................... 27
Figure 3.1.8-2. Normal alignment with PO set .................... 28
Figure 3.1.8-3. Normal alignment with PO set .................... 29
Figure 3.1.8-4. Normal alignment with PO set .................... 30
Figure 3.1.9-1. Normal alignment with PO set (Data) ............. 31
Figure 3.1.9-2. Normal alignment with PO set (Data) ............. 32
Figure 3.1.9-3. Normal alignment with PO set (Data) ............. 33
Figure 3.1.9-4. Normal alignment with PO set (Data) ............. 34
Figure 3.1.10-1. Normal alignment with PO set and cleared ....... 35
Figure 3.1.10-2. Normal alignment with PO set and cleared ....... 36
Figure 3.1.11-1. Set RPO when "Aligned Not Ready" ............... 37
Figure 3.1.11-2. Set RPO when "Aligned Not Ready" ............... 38
Figure 3.1.12-1. "Out of Service" when "Aligned not ready" ...... 39
Figure 3.1.12-2. "Out of Service" when "Aligned not ready" ...... 40
Figure 3.1.12-3. "Out of Service" when "Aligned not ready" ...... 41
Figure 3.1.12-4. "Out of Service" when "Aligned not ready" ...... 42
Figure 3.1.13-1. "Alignment" when "Aligned not ready" ........... 43
Figure 3.1.13-2. "Alignment" when "Aligned not ready" ........... 44
Figure 3.1.14-1. Set and clear LPO when "Initial Alignment" ..... 45
Figure 3.1.15-1. Set and clear LPO when "Aligned ready" ......... 46
Figure 3.1.15-2. Set and clear LPO when "Aligned ready" ......... 47
Figure 3.1.16-1. Timer T1 in "Aligned not ready" state .......... 49
Figure 3.1.16-2. Timer T1 in "Aligned not ready" state .......... 50
Figure 3.1.17-1. No "Alignment" during normal proving period
............................................................... 51
Figure 3.1.18-1. Toggle emergency before "start alignment" ...... 52
B. Bidulock Version 0.6 Page 134
Internet Draft M2PA-TEST October 16, 2005
Figure 3.1.19-1. Set emergency in "not aligned" state ........... 53
Figure 3.1.20-1. Set emergency when "aligned" ................... 54
Figure 3.1.21-1. Both ends set emergency ........................ 55
Figure 3.1.22-1. Individual end sets emergency .................. 56
Figure 3.1.23-1. Set emergency during normal proving ............ 57
Figure 3.1.24-1. No "Alignment" during emergency alignment ...... 58
Figure 3.1.25-1. Deactivate during initial alignment ............ 59
Figure 3.1.26-1. Deactivate during aligned state ................ 60
Figure 3.1.27-1. Deactivate during aligned not ready ............ 61
Figure 3.1.27-2. Deactivate during aligned not ready ............ 62
Figure 3.1.28-1. "Alignment" during link in service ............. 63
Figure 3.1.29-1. "Out of service" during link in service ........ 63
Figure 3.1.29-2. "Out of service" during link in service ........ 64
Figure 3.1.30-1. Deactivation during LPO ........................ 65
Figure 3.1.30-2. Deactivation during LPO ........................ 65
Figure 3.1.31-1. Deactivation during RPO ........................ 66
Figure 3.1.31-2. Deactivation during RPO ........................ 67
Figure 3.1.32-1. Deactivation during the proving period ......... 68
Figure 3.1.32-2. Deactivation during the proving period ......... 69
Figure 3.1.33-1. "Alignment" instead of "In Service" ............ 70
Figure 3.1.34-1. "Out of Service" instead of "In Service" ....... 71
Figure 3.1.35-1. "Processor Outage" instead of "In Service" ..... 72
Figure 3.2.1-1. Unexpected events in the "Out of Service"
State ......................................................... 73
Figure 3.2.2-1. Unexpected events while "not aligned" ........... 75
Figure 3.2.3-1. Unexpected events while "aligned" ............... 77
Figure 3.2.4-1. Unexpected events while "proving" ............... 79
Figure 3.2.5-1. Unexpected events while "aligned ready" ......... 81
Figure 3.2.6-1. Unexpected events while "aligned not ready" ..... 83
Figure 3.2.7-1. Unexpected events while "in service" ............ 84
Figure 3.2.8-1. Unexpected events while "processor outage" ...... 85
Figure 3.3.1-1. Link aligned ready (Abort) ...................... 87
Figure 3.3.2-1. Not applicable .................................. 88
Figure 3.3.3-1. Link aligned not ready (Abort) .................. 88
Figure 3.3.4-1. Not applicable .................................. 89
Figure 3.3.5-1. Link in service (Abort) ......................... 89
Figure 3.3.6-1. Not applicable .................................. 90
Figure 3.3.7-1. Link in processor outage (Abort) ................ 90
Figure 3.3.8-1. Not applicable .................................. 91
Figure 3.4.1-1. Set and clear LPO while link in service ......... 92
Figure 3.4.1-2. Set and clear LPO while link in service ......... 94
Figure 3.4.2-1. RPO during LPO .................................. 95
Figure 3.4.3-1. Clear LPO when "Both processor outage" .......... 96
Figure 3.5.1-1. Not applicable .................................. 97
Figure 3.5.2-1. Not applicable .................................. 98
Figure 3.5.3-1. Below minimum signal unit length ................ 98
Figure 3.5.4-1. Not applicable .................................. 99
Figure 3.5.4-2. Not applicable .................................. 99
Figure 3.5.5-1. Not applicable .................................. 99
Figure 3.5.5-2. Not applicable .................................. 100
Figure 3.6.1-1. Not applicable .................................. 100
Figure 3.6.2-1. Not applicable .................................. 101
Figure 3.6.3-1. Not applicable .................................. 101
Figure 3.6.4-1. Not applicable .................................. 101
B. Bidulock Version 0.6 Page 135
Internet Draft M2PA-TEST October 16, 2005
Figure 3.7.1-1. Not applicable .................................. 102
Figure 3.7.2-1. Not applicable .................................. 102
Figure 3.7.3-1. Not applicable .................................. 103
Figure 3.7.4-1. Not applicable .................................. 103
Figure 3.8.1-1. Data transmission and reception ................. 104
Figure 3.8.2-1. Not Applicable .................................. 105
Figure 3.8.3-1. Check RTB full .................................. 106
Figure 3.8.4-1. Single invalid Ack .............................. 106
Figure 3.8.5-1. Duplicated FSN .................................. 107
Figure 3.8.6-1. Not Applicable .................................. 108
Figure 3.8.7-1. Not Applicable .................................. 108
Figure 3.8.8-1. Not Applicable .................................. 109
Figure 3.8.9-1. In service prior to RPO being set ............... 109
Figure 3.8.9-2. In service prior to RPO being set ............... 111
Figure 3.8.10-1. Abnormal BSN - single Data message ............. 112
Figure 3.8.11-1. Abnormal BSN - two consecutive messages ........ 113
Figure 3.8.12-1. Excessive delay of acknowledgments ............. 114
Figure 3.8.12-2. Excessive delay of acknowledgments ............. 115
Figure 3.8.13-1. Level 3 Stop command ........................... 116
Figure 3.9.1-1. Not Applicable .................................. 116
Figure 3.9.2-1. Not Applicable .................................. 117
Figure 3.9.3-1. Not Applicable .................................. 117
Figure 3.9.4-1. Not Applicable .................................. 118
Figure 3.9.5-1. Not Applicable .................................. 118
Figure 3.9.6-1. Not Applicable .................................. 118
Figure 3.9.7-1. Not Applicable .................................. 119
Figure 3.9.8-1. Not Applicable .................................. 119
Figure 3.9.9-1. Not Applicable .................................. 120
Figure 3.9.10-1. Not Applicable ................................. 120
Figure 3.9.11-1. Not Applicable ................................. 120
Figure 3.9.12-1. Not Applicable ................................. 121
Figure 3.9.13-1. Not Applicable ................................. 121
Figure 3.10.1-1. Congestion abatement ........................... 122
Figure 3.10.2-1. Timer T7 ....................................... 123
Figure 3.10.2-2. Timer T7 ....................................... 124
Figure 3.10.2-3. Timer T7 ....................................... 125
Figure 3.10.3-1. Timer T6 ....................................... 126
Table of Contents
Status of this Memo ............................................. 1
Copyright ....................................................... 1
Abstract ........................................................ 1
Contents ........................................................ 2
1 Introduction .................................................. 2
1.1 Scope ....................................................... 2
1.2 Terminology ................................................. 2
1.3 Abbreviations ............................................... 3
1.4 Conventions ................................................. 4
Notes for Section 1 ............................................. 4
2 Test Environment .............................................. 4
2.1 Test Configurations ......................................... 5
2.1.1 Validation Test Configuration ............................. 5
2.1.2 Compatibility Test Configuration .......................... 7
B. Bidulock Version 0.6 Page 136
Internet Draft M2PA-TEST October 16, 2005
2.1.3 Interoperability Test Configuration ....................... 8
2.2 Testing Methodology ......................................... 8
2.3 Recommended IUT Settings .................................... 8
2.3.1 Timer Values .............................................. 8
2.3.2 Buffer Threshold Values ................................... 9
2.3.3 MSU Length ................................................ 9
2.3.4 Labeling of Messages and Primitives ....................... 9
2.3.5 Labeling of Sequence Numbers .............................. 11
Notes for Section 2 ............................................. 12
3 Tests ......................................................... 12
3.1 Link State Control - Expected signal units/orders ........... 15
3.1.1 Initialization (Power-up) ................................. 15
3.1.2 Timer T2 .................................................. 16
3.1.3 Timer T3 .................................................. 17
3.1.4 Timer T1 & Timer T4 (Normal) .............................. 18
3.1.5 Normal alignment procedure ................................ 20
3.1.6 Normal alignment procedure - correct procedure (Data) ..... 23
3.1.7 Status "Alignment" received during normal proving period
............................................................... 25
3.1.8 Normal alignment with PO set .............................. 26
3.1.9 Normal alignment with PO set (Data) ....................... 30
3.1.10 Normal alignment with PO set and cleared ................. 34
3.1.11 Set RPO when "Aligned not ready" ......................... 36
3.1.12 Status "Out of Service" received when "Aligned not
ready" ........................................................ 38
3.1.13 Status "Alignment" received when "Aligned not ready" ..... 42
3.1.14 Set and clear LPO when "Initial alignment" ............... 44
3.1.15 Set and clear LPO when "Aligned ready" ................... 45
3.1.16 Timer T1 in "Aligned not ready" state .................... 48
3.1.17 No status "Alignment" sent during normal proving period
............................................................... 50
3.1.18 Set and cease emergency prior to "start alignment" ....... 51
3.1.19 Set emergency while in "not aligned" state ............... 52
3.1.20 Set emergency when "aligned" ............................. 53
3.1.21 Both ends set emergency. ................................ 55
3.1.22 Individual end sets emergency ............................ 56
3.1.23 Set emergency during normal proving ...................... 57
3.1.24 No status "Alignment" sent during emergency alignment
............................................................... 58
3.1.25 Deactivation during initial alignment .................... 59
3.1.26 Deactivation during aligned state ........................ 59
3.1.27 Deactivation during aligned not ready .................... 60
3.1.28 Status "alignment" received during link in service ....... 62
3.1.29 Status "out of service" received during link in service
............................................................... 63
3.1.30 Deactivation during LPO .................................. 64
3.1.31 Deactivation during RPO .................................. 66
3.1.32 Deactivation during the proving period ................... 67
3.1.33 Status "Alignment" received instead of status "Ready"
............................................................... 69
3.1.34 Status "Out of Service" received instead of status
"Ready" ....................................................... 70
3.1.35 Status "Processor Outage" received instead of status
"Ready" ....................................................... 71
B. Bidulock Version 0.6 Page 137
Internet Draft M2PA-TEST October 16, 2005
3.2 Link State Control - Unexpected signal units/orders ......... 72
3.2.1 Unexpected signal units/orders in "Out of service" state
............................................................... 72
3.2.2 Unexpected signal units/orders in "Not Aligned" state ..... 74
3.2.3 Unexpected signal units/orders in "Aligned" state ......... 76
3.2.4 Unexpected signal units/orders in "Proving" state ......... 78
3.2.5 Unexpected signal units/orders in "Aligned Ready" state
............................................................... 80
3.2.6 Unexpected signal units/orders in "Aligned Not Ready"
state ......................................................... 82
3.2.7 Unexpected signal units/orders in "In Service" state ...... 84
3.2.8 Unexpected signal units/orders in "Processor Outage"
state ......................................................... 85
3.3 Transmission Failure ........................................ 86
3.3.1 Link aligned ready (Abort) ................................ 86
3.3.2 Link aligned ready (Corrupt FIBs) ......................... 87
3.3.3 Link aligned not ready (Abort) ............................ 88
3.3.4 Link aligned not ready (Corrupt FIBs) ..................... 89
3.3.5 Link in service (Abort) ................................... 89
3.3.6 Link in service (Corrupt FIBs) ............................ 90
3.3.7 Link in processor outage (Abort) .......................... 90
3.3.8 Link in processor outage (Corrupt FIBs) ................... 91
3.4 Processor Outage Control .................................... 91
3.4.1 Set and clear LPO while link in service ................... 91
3.4.2 RPO during LPO ............................................ 95
3.4.3 Clear LPO when "Both processor outage" .................... 96
3.5 SU delimitation, alignment, error detection and correction
............................................................... 97
3.5.1 More than 7 ones between MSU opening and closing flags
............................................................... 97
3.5.2 Greater than maximum signal unit length ................... 98
3.5.3 Below minimum signal unit length .......................... 98
3.5.4 Reception of single and multiple flags between FISUs ...... 98
3.5.5 Reception of single and multiple flags between MSUs ....... 99
3.6 SUERM check ................................................. 100
3.6.1 Error rate of 1 in 256 - Link remains in service .......... 100
3.6.2 Error rate of 1 in 254 - Link out of service .............. 100
3.6.3 Consecutive corrupt SUs ................................... 101
3.6.4 Time controlled break of the link ......................... 101
3.7 AERM check .................................................. 102
3.7.1 Error rate below the normal threshold ..................... 102
3.7.2 Error rate at the normal threshold ........................ 102
3.7.3 Error rate above the normal threshold ..................... 103
3.7.4 Error rate at the emergency threshold ..................... 103
3.8 Transmission and reception control (Basic) .................. 103
3.8.1 Data transmission and reception ........................... 103
3.8.2 Negative acknowledgments of an MSU ........................ 104
3.8.3 Check RTB full ............................................ 105
3.8.4 Single invalid Ack ........................................ 106
3.8.5 Duplicated FSN ............................................ 107
3.8.6 Erroneous retransmission - Single MSU ..................... 108
3.8.7 Erroneous retransmission - Multiple FISUs ................. 108
3.8.8 Single FISU with corrupt FIB .............................. 108
3.8.9 In Service prior to RPO being set ......................... 109
B. Bidulock Version 0.6 Page 138
Internet Draft M2PA-TEST October 16, 2005
3.8.10 Abnormal BSN - single Data message ....................... 112
3.8.11 Abnormal BSN - two consecutive messages .................. 112
3.8.12 Excessive delay of acknowledgments ....................... 113
3.8.13 Level 3 Stop command ..................................... 115
3.9 Transmission and Reception Control (PCR) .................... 116
3.9.1 MSU transmission and reception ............................ 116
3.9.2 Priority control .......................................... 117
3.9.3 Forced retransmission with the value N1 ................... 117
3.9.4 Forced retransmission with the value N2 ................... 117
3.9.5 Forced retransmission cancel .............................. 118
3.9.6 Reception of forced retransmission ........................ 118
3.9.7 MSU transmission while RPO set ............................ 119
3.9.8 Abnormal BSN - Single MSU ................................. 119
3.9.9 Abnormal BSN - Two MSUs ................................... 119
3.9.10 Unexpected FSN ........................................... 120
3.9.11 Excessive delay of acknowledgments ....................... 120
3.9.12 FISU with FSN expected for MSU ........................... 121
3.9.13 Level 3 Stop command ..................................... 121
3.10 Congestion Control ......................................... 121
3.10.1 Congestion abatement ..................................... 121
3.10.2 Timer T7 ................................................. 122
3.10.3 Timer T6 ................................................. 125
Security Considerations ......................................... 126
IANA Considerations ............................................. 127
0 Change History ................................................ 127
0.6 Changes fron Version 0.5 to Version 0.6 ..................... 127
0.5 Changes fron Version 0.4 to Version 0.5 ..................... 127
0.4 Changes from Version 0.3 to Version 0.4 ..................... 127
0.3 Changes from Version 0.2 to Version 0.3 ..................... 129
0.2 Changes from Version 0.1 to Version 0.2 ..................... 129
0.1 Changes from Version 0.0 to Version 0.1 ..................... 129
R References .................................................... 131
R.1 Normative References ........................................ 131
R.2 Informative References ...................................... 131
Acknowledgments ................................................. 133
Author's Addresses .............................................. 133
List of Tables .................................................. 134
List of Illustrations ........................................... 134
Table of Contents ............................................... 136
B. Bidulock Version 0.6 Page 139
Internet Draft M2PA-TEST October 16, 2005
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify such rights. Information on
the procedures with respect to rights in RFC documents can be found in
BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address to the IETF at [email protected].
Disclaimer of Validity
This document and the information contained herein is provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
B. Bidulock Version 0.6 Page 140
| ||||||||||||||||||
| Last modified: Wed, 27 Nov 2024 16:03:34 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||||