Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation July 26, 2003 Expires in January 2004 SS7 MTP2-User Peer-to-Peer Adaptation Layer Test Specifications M2PA-TEST Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 or RFC 2026. 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 as 'work in progress'. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html To learn the current status of any Internet-Draft, please check the Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This Internet Draft provides information for the Internet community on test cases for testing the SS7 M2P2-User Peer-to-Peer Adaptation Layer [M2PA09] based on the conformance test specifications for SS7 MTP Level 2 [Q.781]. 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]. B. Bidulock Version 0.4 Page 1 Internet Draft M2PA-TEST July 26, 2003 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 [M2PA09] 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 [M2PA09]. 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 [M2PA09], 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 [M2PA09] provides that, unless modified by the M2PA specification [M2PA09], 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 [M2PA09] with the following terms: Compatibility Test (CPT) -- A test where multiple implementations are tested in interaction with each other to test for compatibility between implementations. B. Bidulock Version 0.4 Page 2 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 3 Internet Draft M2PA-TEST July 26, 2003 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 [RFC 2119]. 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. 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 B. Bidulock Version 0.4 Page 4 Internet Draft M2PA-TEST July 26, 2003 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 ___________________________________________________________________ | | | 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: B. Bidulock Version 0.4 Page 5 Internet Draft M2PA-TEST July 26, 2003 (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 [M2PA09] 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 [M2PA09] signalling link has been interposed for an SS7 signalling link [Q.703]. All test cases in this document should be executed when performing Validation testing. 2.1.2. Compatibility Test Configuration B. Bidulock Version 0.4 Page 6 Internet Draft M2PA-TEST July 26, 2003 ___________________________________________________________________ | | | 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 [M2PA09] 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 [M2PA09] 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. (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. B. Bidulock Version 0.4 Page 7 Internet Draft M2PA-TEST July 26, 2003 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 [M2PA09] 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. B. Bidulock Version 0.4 Page 8 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 9 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 10 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 11 Internet Draft M2PA-TEST July 26, 2003 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 (Invalid Acks) VAT - - 3.3.3 Link aligned not ready (Abort) VAT - - 3.3.4 Link aligned not ready (Invalid Acks) VAT - - 3.3.5 Link in service (Abort) VAT CPT IOT 3.3.6 Link in service (Invalid Acks) VAT - - 3.3.7 Link in processor outage (Abort) VAT - IOT 3.3.8 Link in processor outage (Invalid Acks) VAT - - 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.4 Page 12 Internet Draft M2PA-TEST July 26, 2003 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.8.14 Abnormal FSN VAT - - 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.4 Page 13 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 14 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 15 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 16 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 17 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 18 Internet Draft M2PA-TEST July 26, 2003 (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.4 Page 19 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 20 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 21 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 22 Internet Draft M2PA-TEST July 26, 2003 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 status "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.4 Page 23 Internet Draft M2PA-TEST July 26, 2003 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 status "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.4 Page 24 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 25 Internet Draft M2PA-TEST July 26, 2003 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 -----------------> | | !in service | | | |___________________________________________________________________| 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 and indicates "In Service" to Level 3. (5) Check that the link maintains the "In Service" 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.4 Page 26 Internet Draft M2PA-TEST July 26, 2003 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 "In Service" 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.4 Page 27 Internet Draft M2PA-TEST July 26, 2003 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 -----------------> | | !in service | | | |___________________________________________________________________| 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 and indicates "In Service" to Level 3. (5) Check that the link maintains the "In Service" 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.4 Page 28 Internet Draft M2PA-TEST July 26, 2003 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 "In Service" 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.4 Page 29 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 30 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 31 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 32 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 33 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 34 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 35 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 36 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 37 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 38 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 39 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 40 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 41 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 42 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 43 Internet Draft M2PA-TEST July 26, 2003 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.4 Page 44 Internet Draft M2PA-TEST July 26, 2003 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 | | !in service | | :clear lpo | | <----------------- PROCESSOR-RECOVERED | | | |___________________________________________________________________| 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 and indicates "In Service" to Level 3 at the IUT. (6) Issue the Level 3 "Clear Local Processor Outage" command at the IUT. B. Bidulock Version 0.4 Page 45 Internet Draft M2PA-TEST July 26, 2003 (7) Check that the IUT sends a status "Processor Recovered" message and enters the "In Service" state. 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 | | !in service | | :clear lpo | | <----------------- PROCESSOR-RECOVERED | | | |___________________________________________________________________| 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. (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. B. Bidulock Version 0.4 Page 46 Internet Draft M2PA-TEST July 26, 2003 (7) Check that the IUT sends a status "Processor Recovered" message and enters the "In Service" state. 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. 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.) B. Bidulock Version 0.4 Page 47 Internet Draft M2PA-TEST July 26, 2003 (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 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. | | :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. B. Bidulock Version 0.4 Page 49 Internet Draft M2PA-TEST July 26, 2003 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. 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. B. Bidulock Version 0.4 Page 50 Internet Draft M2PA-TEST July 26, 2003 3.1.19. Set emergency while in "not aligned" state This test case validates the behavior of the IUT when the Level 3 "Set Emerg