Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation Expires in six months September 15, 2002 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). Abstract This Internet Draft provides information for the Internet community on test cases for testing the SS7 M2P2-User Peer-to-Peer Adaptation Layer [M2PA06] based on the conformance test specifications for SS7 MTP Level 2 [Q.781]. 1. Introduction This draft provides a set of detailed test of the SS7 MTP2-User Peer- to-Peer Adaptation Layer [M2PA06] 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 B. Bidulock Version 0.2 Page 1 Internet Draft M2PA-TEST September 15, 2002 [M2PA06]. 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. Change History 1.1.1. Changes from draft-bidulock-sigtran-m2pa-test-01 (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 acknowledgement of DATA messages using a special DATA message which contains no data payload. This message has been labelled "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 them 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. 1.1.2. Changes from draft-bidulock-sigtran-m2pa-test-00 (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 occurence 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 B. Bidulock Version 0.2 Page 2 Internet Draft M2PA-TEST September 15, 2002 updated to include the sequence numbers (where other than zero) and test cases were added for abnormal backwards 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 acknowledgement. Another possibilty would have been to send a DATA message with no data in it. The old "ACK" message is now labelled "IN-SERVICE". (5) The status message previously labelled "IN-SERVICE" has been relabelled "READY" to better reflect the name of that atatus message in the draft and to not conflict with the new [M2PA04] "IN-SERVICE" status message. 2. Test Environment 2.1. Test Configurations A single M2PA link is used in the tests. Figure 2.1-1 and Figure 2.1-2 show a single link between IUT and PT. In Test Configuration 1 as shown in Figure 2.1-1, PT initiates the association. In Test Configuration 2 as shown in Figure 2.1-2, IUT initiates the association. Test specifications in both configurations are written to test the M2PA at IUT . ________ Link 1 ________ | | SCTP Association | | | PT |-------------------------->| IUT | |________| |________| NOTE: PT initiates the association Figure 2.1-1. Test Configuration 1 ________ Link 1 ________ | | SCTP Association | | | PT |<--------------------------| IUT | |________| |________| NOTE: IUT initiates the association Figure 2.1-2. Test Configuration 2 2.2. Recommended IUT Settings 2.2.1. Timer Values It is recommended that the following timer values be configured at the IUT for the purposes of performing these validation tests: B. Bidulock Version 0.2 Page 3 Internet Draft M2PA-TEST September 15, 2002 T1 45 seconds T2 5 seconds T2l 20 seconds (not applicable) T2h 100 seconds (not applicable) T3 1 second T4n 8 seconds T4e 0.5 seconds T5 0.1 seconds (not applicable) T6 4 seconds T7 1 second T8 0.1 seconds (not applicable) 2.2.2. Buffer Threshold Values It is recommended that the following buffer threshold values be configured at the IUT for the purpose of performing these validation tests: N1 (not applicable) N2 127 messages 2.2.3. MSU Length It is illustrated that all 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 of the results. 3. Tests 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. B. Bidulock Version 0.2 Page 4 Internet Draft M2PA-TEST September 15, 2002 3.1.1.1. Forward Direction The test is performed in the forward direction. The expected sequence of events is illustrated Figure 3.1.1-1. Reference: Q.781/Test 1.1(a) ___________________________________________________________________ | | | PT IUT | | | | :power on | | OUT-OF-SERVICE -----------------> | | :power on | | <----------------- OUT-OF-SERVICE | | | |___________________________________________________________________| Figure 3.1.1-1. Initialization (Power-up) Test Description: (1) The test begins with both the PT and the IUT in the "Power Off" state. (2) The "Power On" command is issued at the PT and then the IUT. (3) Check that the IUT sends a status "Out of Service" message enters and remains in the "Out of Service" state. (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 Figure 3.1.1-2. Reference: Q.781/Test 1.1(b) ___________________________________________________________________ | | | PT IUT | | | | :power on | | <----------------- OUT-OF-SERVICE | | :power on | | OUT-OF-SERVICE -----------------> | | | |___________________________________________________________________| Figure 3.1.1-2. Initialization (Power-up) Test Description: (1) The test begins with both the PT and the IUT in the "Power Off" state. B. Bidulock Version 0.2 Page 5 Internet Draft M2PA-TEST September 15, 2002 (2) The "Power On" command is issued at the IUT and then the PT. (3) Check that the IUT sends a status "Out of Service" message enters and remains in the "Out of Service" state. 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. Reference: Q.781/Test 1.2 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | ! | | ! 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 the PT and the IUT in the "Out of Service" state. (2) The "Start" command is issued at the IUT. (3) Check that the IUT sends a status "Alignment" message. (4) Check that the IUT 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) The IUT 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 B. Bidulock Version 0.2 Page 6 Internet Draft M2PA-TEST September 15, 2002 the M2PA peer after sending status "Proving Normal" or status "Proving Emergency". The expected sequence of events is illustrated Figure 3.1.3-1. Reference: Q.781/Test 1.3 ___________________________________________________________________ | | | 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. (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. (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. The expected sequence B. Bidulock Version 0.2 Page 7 Internet Draft M2PA-TEST September 15, 2002 of events is illustrated Figure 3.1.4-1. Reference: Q.781/Test 1.4 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | :start | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL -----------------> | | ! | | | T4(Pn) 7.5 <= T4 <= 9.5 | | ! | | <----------------- READY | | ! | | ! 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. (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" and proving data messages. (5) Check that a status "Ready" message is received from the IUT within time T4. (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". (8) Check that T1 is between 40.0 seconds and 50.0 seconds in duration. B. Bidulock Version 0.2 Page 8 Internet Draft M2PA-TEST September 15, 2002 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 The test is performed in the forward direction. The expected sequence of events is illustrated Figure 3.1.5-1. Reference: Q.781/Test 1.5(a) ___________________________________________________________________ | | | 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". (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.5-1. (4) Check that the IUT 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.2. Reverse Direction 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 statu message. The expected sequence of events is illustrated Figure 3.1.5-2. B. Bidulock Version 0.2 Page 9 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.5(b) ___________________________________________________________________ | | | 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". (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.5-2. (4) Check that the IUT 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. The expected sequence of events is illustrated Figure 3.1.6-1. B. Bidulock Version 0.2 Page 10 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.6 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | :start | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL -----------------> | | <----------------- READY | | [ 35 bytes] DATA ---[0001, 0000]--> | | <--[0001, 0000]--- DATA-ACK | | !in service | | !msu | | | |___________________________________________________________________| Figure 3.1.6-1. Normal alignment procedure (Data) Test Description: (1) The test begins with the link "Out of Service". (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. (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 Figure 3.1.7-1. B. Bidulock Version 0.2 Page 11 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.7 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | :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. (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. (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. 3.1.8.1. Forward Direction The test is performed in the forward direction. The expected sequence of events is illustrated Figure 3.1.8-1. B. Bidulock Version 0.2 Page 12 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.8(a) ___________________________________________________________________ | | | 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. (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 sends the message sequence illustrated in Figure 3.1.8-1. (4) Check that the IUT sends status "Processor Outage" message and indicates "In Service" to Level 3. (5) Check that the link maintains the "In Service" state at the IUT. 3.1.8.2. Reverse Direction This case is the same test in the reverse direction. The expected sequence of events is illustrated Figure 3.1.8-2. B. Bidulock Version 0.2 Page 13 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.8(b) ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Local Processor Outage" and "Start" command at the PT and the "Start" command at the IUT. (3) Check that the IUT sends the message sequence illustrated in Figure 3.1.8-2. (4) Check that the IUT sends status "Ready" message and indicates "Remote Processor Outage" indication to Level 3. (5) Check that the link maintains the "In Service" state at the IUT. 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 The test is performed in the forward direction. The expected sequence of events is illustrated Figure 3.1.9-1. B. Bidulock Version 0.2 Page 14 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.9(a) ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :set lpo | | :start | | <----------------- ALIGNMENT | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL -----------------> | | <----------------- PROCESSOR-OUTAGE | | [ 35 bytes] DATA ---[0001, 0000]--> | | | |___________________________________________________________________| 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. (2) Issue the Level 3 "Set Local Processor Outage" and "Start" commands at the IUT. (3) Check that the IUT sends the message sequence illustrated in Figure 3.1.9-1. (4) Check that the IUT sends status "Processor Outage" message and send a Data message to the IUT to complete the alignment procedure. (5) Check that the IUT does not acknowledge the Data message. (6) Check that the IUT maintains the "Processor Outage" state. 3.1.9.2. Reverse Direction This is the same test in the reverse direction. The expected sequence of events is illustrated Figure 3.1.9-2. B. Bidulock Version 0.2 Page 15 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.9(b) ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :set lpo | | :start | | :start | | <----------------- ALIGNMENT | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | :msu | | PROVING-NORMAL -----------------> | | <--[0000, 0001]--- DATA [ 35 bytes] | | PROCESSOR-OUTAGE ---[0000, 0001]--> | | !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. (2) Issue the Level 3 "Set Local Processor Outage" and "Start" commands at the PT and the "Start" command at the IUT. (3) Provide an MSU for transmission at the IUT before the proving period ends. (4) Check that the IUT sends the message sequence illustrated in Figure 3.1.9-2. (5) Check that the IUT completes the proving process with the MSU and indicates "Remote Processor Outage" to Level 3. (6) Check that the IUT 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. The expected sequence of events is illustrated Figure 3.1.10-1. B. Bidulock Version 0.2 Page 16 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.10 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Set Local Processor Outage," "Clear Local Processor Outage" and "Start" commands at the IUT and "Start" command at the PT. (3) Check that the sequence of events follows that illustrated in Figure 3.1.10-1. (4) Check that the IUT 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. The expected sequence of events is illustrated Figure 3.1.11-1. B. Bidulock Version 0.2 Page 17 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.11 ___________________________________________________________________ | | | 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. (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. (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 The test is performed in the forward direction. The expected sequence of events is illustrated Figure 3.1.12-1. B. Bidulock Version 0.2 Page 18 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.12(a) ___________________________________________________________________ | | | 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. (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. (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 The test is repeated in the reverse direction. The expected sequence of events is illustrated Figure 3.1.12-2. B. Bidulock Version 0.2 Page 19 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.12(b) ___________________________________________________________________ | | | 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. (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. (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. The expected sequence of events is illustrated Figure 3.1.13-1. B. Bidulock Version 0.2 Page 20 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.13 ___________________________________________________________________ | | | 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. (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. (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 Figure 3.1.14-1. B. Bidulock Version 0.2 Page 21 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.14 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Start" command at the IUT and PT. (3) Issue the Level 3 "Set Local Processor Outage" command at the IUT when the IUT begins initial alignment. (4) Issue the Level 3 "Clear Local Processor Outage" command at the IUT before the IUT completes initial alignment. (5) Check that the IUT sends the status "Ready" message when it completes initial alignment and that the "In Service" indication is given to Level 3 at the IUT. 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. The expected sequence of events is illustrated Figure 3.1.15-1. B. Bidulock Version 0.2 Page 22 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.15 ___________________________________________________________________ | | | 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-OUTAGE-ENDED | | | |___________________________________________________________________| 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. (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. (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 Outage Ended" 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. The expected sequence of events is illustrated Figure 3.1.16-1. B. Bidulock Version 0.2 Page 23 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.16 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :set lpo | | :start | | <----------------- ALIGNMENT | | :start | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL -----------------> | | <----------------- PROCESSOR-OUTAGE | | ! | | ! 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. (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 IUT follows the sequence of events illustrated in Figure 3.1.16-1 while completing the initial alignment procedure. (4) Check that the IUT 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 Figure 3.1.17-1. B. Bidulock Version 0.2 Page 24 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.17 ___________________________________________________________________ | | | 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. (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. (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 Figure 3.1.18-1. B. Bidulock Version 0.2 Page 25 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.18 ___________________________________________________________________ | | | 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. (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. (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 Figure 3.1.19-1. B. Bidulock Version 0.2 Page 26 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.19 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Start" and "Set Emergency" commands at the IUT and "Start" command at the PT. (3) Check that the sequence of events are as illustrated in Figure 3.1.19-1. Check that the IUT sends a status "Proving Emergency" message in response to the "Alignment" message. (4) Check that the IUT sends a status "Ready" message. (5) Check that the IUT uses an emergency proving period by timing the delay from the status "Proving Emergency" message to the status "Ready" message sent by the IUT. (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 Figure 3.1.20-1. B. Bidulock Version 0.2 Page 27 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.20 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Start" command at the IUT and the PT. (3) Check that the normal alignment procedure starts as illustrated in Figure 3.1.20-1. (4) Before the normal proving period completes, issue the Level 3 "Set Emergency" command at the ITU. (5) Check that the IUT sends a status "Proving Emergency" message and later follows with a status "Ready" message. (6) Check that the IUT 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. 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 Figure 3.1.21-1. B. Bidulock Version 0.2 Page 28 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.21 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Set Emergency" and "Start" commands at the IUT and the "Start" command at the PT. (3) Check that the IUT starts the emergency alignment procedure by sending a status "Proving Emergency" message. (4) Check that the IUT follows the sequence of events as illustrated in Figure 3.1.21-1. Check that the IUT completes the alignment procedure and sends a status "Ready" message. (5) Check that the IUT uses an emergency proving period by timing the delay between sending the status "Proving Normal" message and the status "Ready" message. (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 Figure 3.1.22-1. B. Bidulock Version 0.2 Page 29 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.22 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Set Emergency" and "Start" commands at the PT and the "Start" command at the IUT. (3) Check that the sequence of events follows that illustrated in Figure 3.1.22-1. (4) Check that the IUT uses the emergency proving period by timing the delay between the status "Proving Normal" message and the status "Ready" message. (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 Figure 3.1.23-1. B. Bidulock Version 0.2 Page 30 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.23 ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Start" command at the IUT and the PT. (3) Check that the sequence of events follows that illustrated in Figure 3.1.23-1. (4) Before the normal proving period completes at the IUT, issue the Level 3 "Set Emergency" command at the IUT. (5) Check that the IUT sends a status "Proving Emergency" message and continues proving. (6) Check that the IUT sends a status "Ready" message. (7) Check that the IUT 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 Figure 3.1.24-1. B. Bidulock Version 0.2 Page 31 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.24 ___________________________________________________________________ | | | 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. (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. (4) Check that the IUT completes proving and sends a status "Ready" message. (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 Figure 3.1.25-1. B. Bidulock Version 0.2 Page 32 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.25 ___________________________________________________________________ | | | 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 the IUT. (3) Before timer T2 expires, issue the Level 3 "Stop" command at the IUT. (4) Check that the IUT 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 Figure 3.1.26-1. Reference: Q.781/Test 1.26 ___________________________________________________________________ | | | 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 B. Bidulock Version 0.2 Page 33 Internet Draft M2PA-TEST September 15, 2002 Test Description: (1) The test begins with the link in the "Out of Service" state. (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. (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. The expected sequence of events is illustrated Figure 3.1.27-1. Reference: Q.781/Test 1.27 ___________________________________________________________________ | | | 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. (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.27-1 and sends a status "Processor Outage" message. B. Bidulock Version 0.2 Page 34 Internet Draft M2PA-TEST September 15, 2002 (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.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 Figure 3.1.28-1. Reference: Q.781/Test 1.28 ___________________________________________________________________ | | | 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 Figure 3.1.29-1. B. Bidulock Version 0.2 Page 35 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.29(a) ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Stop" command at the PT and send a status "Out of Service" message to the IUT. (3) Check that the IUT sends a status "Out of Service" message and indicates "Out of Service" to the Level 3 at the IUT 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 Figure 3.1.29-2. Reference: Q.781/Test 1.29(b) ___________________________________________________________________ | | | 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 the IUT. (3) Check that the IUT sends a status "Out of Service" message and stays in the "Out of Service" state. B. Bidulock Version 0.2 Page 36 Internet Draft M2PA-TEST September 15, 2002 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 Figure 3.1.30-1. Reference: Q.781/Test 1.30(a) ___________________________________________________________________ | | | 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 the IUT. (3) Check that the IUT sends a status "Processor Outage" message. (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.30.2. Reverse Direction The test is repeated in the reverse direction. The expected sequence of events is illustrated Figure 3.1.30-2. B. Bidulock Version 0.2 Page 37 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.30(b) ___________________________________________________________________ | | | 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 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 the PT. (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 "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 Figure 3.1.31-1. Reference: Q.781/Test 1.31(a) ___________________________________________________________________ | | | PT IUT | | | | PROCESSOR-OUTAGE -----------------> | | :stop | | <----------------- OUT-OF-SERVICE | | | |___________________________________________________________________| Figure 3.1.31-1. Deactivation during RPO B. Bidulock Version 0.2 Page 38 Internet Draft M2PA-TEST September 15, 2002 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 the PT and send a status "Processor Outage" message to the IUT. (3) Issue the Level 3 "Stop" command at the IUT. (4) Check that the IUT 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 Figure 3.1.31-2. Reference: Q.781/Test 1.31(b) ___________________________________________________________________ | | | 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 the IUT. (3) Check that the IUT sends a status "Processor Outage" message. (4) Issue the Level 3 "Stop" command at the PT and send the status "Out of Service" message. (5) Check that the IUT 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. B. Bidulock Version 0.2 Page 39 Internet Draft M2PA-TEST September 15, 2002 3.1.32.1. Forward Direction The expected sequence of events is illustrated Figure 3.1.32-1. Reference: Q.781/Test 1.32(a) ___________________________________________________________________ | | | 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. (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.32-1. (4) During the proving period, issue the Level 3 "Stop" command at the PT and send status "Out of Service" to the ITU. (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 "Alignment Not Possible". 3.1.32.2. Reverse Direction The test is repeated in the reverse direction. The expected sequence of events is illustrated Figure 3.1.32-2. B. Bidulock Version 0.2 Page 40 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.32(b) ___________________________________________________________________ | | | 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. (2) Issue the Level 3 "Start" command at the PT and the IUT. (3) Check that the sequence of events follows that illustrated in Figure 3.1.32-2. (4) During the proving period, issue a Level 3 "Stop" command at the IUT. (5) Check that the IUT 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 Figure 3.1.33-1. B. Bidulock Version 0.2 Page 41 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.33 ___________________________________________________________________ | | | 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. (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. (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 Figure 3.1.34-1. B. Bidulock Version 0.2 Page 42 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.34 ___________________________________________________________________ | | | 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. (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. (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 Figure 3.1.35-1. B. Bidulock Version 0.2 Page 43 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 1.35 ___________________________________________________________________ | | | 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. (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.35-1. (4) When the IUT sends a status "Ready" message, issue a Level 3 "Set Local Processor Outage" command at the PT and send a status "Processor Outage" message to the IUT. (5) Check that the IUT indicates "Remote Processor Outage" to Level 3 at the IUT. 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 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 Figure 3.2.1-1. B. Bidulock Version 0.2 Page 44 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 2.1 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | ALIGNMENT -----------------> | | PROVING-NORMAL -----------------> | | PROVING-EMERGENCY -----------------> | | PROCESSOR-OUTAGE -----------------> | | BUSY -----------------> | | [INVALID-STATUS] -----------------> | |PROCESSOR-OUTAGE-ENDED -----------------> | | READY -----------------> | | BUSY-ENDED -----------------> | | DATA-ACK ---[0000, 0000]--> | | [ 35 bytes] DATA ---[0001, 0000]--> | | :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. (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 Outage" - Status "Busy" - Status Invalid - Status "Processor Outage Ended" - Status "Busy Ended" - Status "Ready" - Data Ack - Data B. Bidulock Version 0.2 Page 45 Internet Draft M2PA-TEST September 15, 2002 (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 Figure 3.2.2-1. Reference: Q.781/Test 2.2 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | OUT-OF-SERVICE -----------------> | | PROCESSOR-OUTAGE -----------------> | | BUSY -----------------> | | [INVALID-STATUS] -----------------> | | READY -----------------> | | DATA-ACK ---[0000, 0000]--> | | [ 35 bytes] DATA ---[0001, 0000]--> | | :clear emergency | | :start | | ALIGNMENT ---[0001, 0000]--> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL ---[0001, 0000]--> | | <----------------- READY | | READY ---[0001, 0000]--> | | !in service | | | |___________________________________________________________________| Figure 3.2.2-1. Unexpected events while "not aligned" B. Bidulock Version 0.2 Page 46 Internet Draft M2PA-TEST September 15, 2002 Test Description: (1) The test begins with both M2PA peers in the "Out of Service" state. (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 Outage" - Status "Busy" - Status Invalid - Status "Ready" - Data Ack - Data (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. (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 Figure 3.2.3-1. B. Bidulock Version 0.2 Page 47 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 2.3 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | :start | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | ALIGNMENT -----------------> | | PROCESSOR-OUTAGE -----------------> | | BUSY -----------------> | | [INVALID-STATUS] -----------------> | | READY -----------------> | |PROCESSOR-OUTAGE-ENDED -----------------> | | BUSY-ENDED -----------------> | | DATA-ACK ---[0000, 0000]--> | | [ 35 bytes] DATA ---[0001, 0000]--> | | :clear emergency | | :start | | PROVING-NORMAL ---[0001, 0000]--> | | <----------------- READY | | READY ---[0001, 0000]--> | | !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. (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 Outage" - Status "Busy" - Status Invalid - Status "Ready" - Status "Processor Outage Ended" - Status "Busy Ended" - Data Ack - Data B. Bidulock Version 0.2 Page 48 Internet Draft M2PA-TEST September 15, 2002 (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. (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 Figure 3.2.4-1. Reference: Q.781/Test 2.4 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | :start | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL -----------------> | |PROCESSOR-OUTAGE-ENDED -----------------> | | PROCESSOR-OUTAGE -----------------> | | BUSY-ENDED -----------------> | | BUSY -----------------> | | [INVALID-STATUS] -----------------> | | READY -----------------> | | DATA-ACK ---[0000, 0000]--> | | [ 35 bytes] DATA ---[0001, 0000]--> | | :clear emergency | | :start | | <----------------- READY | | READY ---[0001, 0000]--> | | !in service | | | |___________________________________________________________________| Figure 3.2.4-1. Unexpected events while "proving" B. Bidulock Version 0.2 Page 49 Internet Draft M2PA-TEST September 15, 2002 Test Description: (1) The test begins with both IUT and PT in the "Out of Service" state. (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 Outage Ended" - Status "Processor Outage" - Status "Busy Ended" - Status "Busy" - Status Invalid - Status "Ready" - Data Ack - Data (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. (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 Figure 3.2.5-1. B. Bidulock Version 0.2 Page 50 Internet Draft M2PA-TEST September 15, 2002 Reference: Q.781/Test 2.5 ___________________________________________________________________ | | | PT IUT | | | | <----------------- OUT-OF-SERVICE | | OUT-OF-SERVICE -----------------> | | :start | | <----------------- ALIGNMENT | | :start | | ALIGNMENT -----------------> | | <----------------- PROVING-NORMAL | | PROVING-NORMAL -----------------> | | <----------------- READY | | BUSY -----------------> | | [INVALID-STATUS] -----------------> | | :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. (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 "Busy" - Status Invalid (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 "Clear Local Processor Outage" command - Level 3 "Start" command (5) Check that the IUT ignores the unexpected M2PA messages/Level 3 commands. B. Bidulock Version 0.2 Page 51 Internet Draft M2PA-TEST September 15, 2002 (6) Check that the IUT aligns as usual and performs the normal alignment procedure. (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 Figure 3.2.6-1. Reference: Q.781/Test 2.6 ___________________________________________________________________ | | | PT IUT | | | |