OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Wed, 07 Jan 2009 09:41:10 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-bidulock-sigtran-m2pa-test-07
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-bidulock-sigtran-m2pa-test-07

Description: Request For Comments

You can download source copies of the file as follows:

draft-bidulock-sigtran-m2pa-test-07.txt in text format.
draft-bidulock-sigtran-m2pa-test-07.pdf in pdf format.

Listed below is the contents of file draft-bidulock-sigtran-m2pa-test-07.txt.




Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation

                                                           June 18, 2006
Expires in December 2006

              SS7 MTP2-User Peer-to-Peer Adaptation Layer
                          Test Specifications
                               M2PA-TEST
               <draft-bidulock-sigtran-m2pa-test-07.txt>

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

    This document may not be modified, and derivative works of it may
  not be created, except to publish it as an RFC and to translate it
  into languages other than English.

    Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other documents
  at any time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than 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.

    This Internet-Draft will expire in December 2006.

Copyright

    Copyright (C) The Internet Society (2006).

Abstract

    This Internet Draft provides information for the Internet community
  on test cases for testing the SS7 MTP2-User Peer-to-Peer Adaptation
  Layer [M2PA] based on the conformance test specifications for SS7 MTP
  Level 2 [Q.781].

B. Bidulock                    Version 0.7                        Page 1

Internet Draft                  M2PA-TEST                  June 18, 2006

    This memo describes the test environment and a detailed description
  of test cases for validation, compatibility and interoperability
  testing of the M2PA protocol implemented on the foundation of ITU SS7
  MTP Signalling Links [Q.703].

Contents

    A complete table of contents, list of illustrations, list of tables
  and change history for this document appears at the end of the
  document.

1.  Introduction

    This draft provides a set of detailed tests of the SS7 MTP2-User
  Peer-to-Peer Adaptation Layer [M2PA] based on the test specifications
  for SS7 MTP Level 2 [Q.781].  These tests are intended to validate the
  SS7 MTP2-User Peer-to-Peer Adaptation Layer (M2PA) protocol [M2PA].

    These tests attempt to completely validate the M2PA protocol without
  redundancy.  Each test is described as simply as possible to check
  precisely the elementary function of the protocol.  The tests are
  listed in no specific order<1>.

1.1.  Scope

    Although the SS7 MTP Level 2 Test Specification [Q.781] is largely
  applicable to SS7 signalling links using the SS7 MTP2-User Peer-to-
  Peer Adaptation Layer [M2PA], those test cases describe messages and
  some sequences that are not applicable to M2PA.  This document
  describes a set of Validation and Compatibility tests that are
  consistent with the SS7 MTP Level 2 Test Specification [Q.781], but
  which are applicable to M2PA.

    The Test Environment used for M2PA testing described in this
  document is largely compatible with the SS7 Test Specifications
  [Q.780].

    M2PA [M2PA] provides that, unless modified by the M2PA specification
  [M2PA], that the procedures of the applicable MTP Level 2 standard are
  to be used.  This includes ITU [Q.703], ANSI [T1.111], ETSI [EN 300
  008-1], TTC [JT-Q.703], and other narrow band specifications as well
  as broadband specifications for ITU [Q.2140], ANSI [T1.637], and
  others.  This document describes testing of the procedures applicable
  to ITU signalling links [Q.703], [Q.781] only.  Some other testing
  methodologies applicable to ANSI [T1.111] or ETSI [ETS 300 336],
  although similar, are outside the scope of this document.

1.2.  Terminology

    This document extends the terminology of M2PA [M2PA] with the
  following terms:

B. Bidulock                    Version 0.7                        Page 2

Internet Draft                  M2PA-TEST                  June 18, 2006

  Compatibility Test (CPT) -- A test where multiple implementations are
      tested in interaction with each other to test for compatibility
      between implementations.

  Implementation Under Test (IUT) -- An implementation being tested (the
      object of testing) as part of a Validation Test or a Compatibility
      Test within the Test Environment.

  Interoperability Test (IOT) -- A test where multiple implementations
      are tested in interaction with each other to test for
      interoperability between implementations.

  M2PA Monitor -- A device or function used to monitor, capture, record
      and analyze the exchange of M2PA messages across an IP network
      between implementations or protocol testers.  This device or
      function may be integrated with a Protocol Tester.

  MTP Level 3 Simulator -- A device or function used to simulate the SS7
      MTP Level 3 [Q.704] to SS7 MTP Level 2 [Q.703] implementation.
      This device or function may be integrated within the Test
      Environment.  This device or function is normally required for SS7
      MTP Level 2 Test Specification [Q.781] Validation as well as
      Compatibility tests.

  Protocol Tester (PT) -- A device or function used to generate normal
      or abnormal messages and test sequences for the purpose of
      Validation testing.

  Test Case -- A particular sequence of messages and patterns that make
      up a single Validation or Compatibility test.

  Test Environment -- The environment that contains testing device and
      functions necessary and sufficient for executing a Test Suite.

  Test Suite -- A collection of Test Cases meant to achieve a specific
      objective of Validation or Compatibility testing.

  Validation Test (VAT) -- A test where a single implementation is
      tested in interaction with a Protocol Tester to test for
      validation of the implementation to a technical specification.

1.3.  Abbreviations

      ASP    -- Application Server Process
      CPT    -- Compatibility Test
      IOT    -- Interoperability Test
      IPSP   -- IP Signalling Point
      IUT    -- Implementation Under Test
      PT     -- Protocol Tester
      SG     -- Signalling Gateway

B. Bidulock                    Version 0.7                        Page 3

Internet Draft                  M2PA-TEST                  June 18, 2006

      SGP    -- Signalling Gateway Process
      SP     -- Signalling Point
      VAT    -- Validation Test

1.4.  Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

    This test specification is not a replacement for or extension of the
  SS7 MTP2-User Peer-to-Peer Adaptation Layer protocol specification
  [M2PA].  Where this document and the requirements or recommendations
  of the SS7 MTP2-User Peer-to-Peer Adaptation Layer protocol
  specification [M2PA] disagree, the requirements and recommendations of
  the SS7 MTP2-User Peer-to-Peer Adaptation Layer protocol specification
  [M2PA] shall be taken as authoritative.

Notes for Section 1

  <1>  IMPLEMENTATION NOTE:-- An implementation of M2PA which conforms
       to these test specifications and a test program which executes
       the validation portion of these tests on that implementation
       are available from http://www.openss7.org/downloads.html

2.  Test Environment

    The test environment for SS7 MTP Level 2 [Q.781] testing is
  described in the General Aspects of SS7 Testing [Q.780].  There are
  three types of testing that are accommodated as follows:

  Validation Testing -- consists of validating a single Implementation
       Under Test (IUT).  This is performed by connecting the IUT to a
       Protocol Tester (PT) within the test environment.

       Validation testing is more extensive than compatibility testing.
       This is because it is possible, with the use of the PT, to
       generate abnormal messages and patterns that cannot normally be
       generated from an implementation.  These tests validate the
       response of the IUT to abnormal (as well as normal) conditions.

  Compatibility Testing -- consists of testing the compatibility of one
       Implementation Under Test (IUT) with another.  This is performed
       by connecting the IUT together within the test environment.

       Compatibility testing is less extensive than validation testing.
       This is because it is not normally possible to generate abnormal
       test patterns or generate negative test cases with an
       implementation that conforms to validation testing.  However,
       compatibility tests are better at testing the interoperability of
       two implementations.

B. Bidulock                    Version 0.7                        Page 4

Internet Draft                  M2PA-TEST                  June 18, 2006

  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
       IUT during compatibility testing.

       The objectives of interoperability testing are often different
       than compatibility testing.  The object of compatibility testing
       is to assure that an implementation that passes validation
       testing is, in other respects not tested by validation testing,
       compatible with other such implementations.  The object of
       interoperability testing is to show that there exist
       implementations with which each of the IUT being tested can
       indeed function.

       Although they have different objectives, the test environment
       configuration for interoperability testing is the same as that
       for compatibility testing.

    This document uses the test environment described in the SS7 Test
  Specification [Q.780].

2.1.  Test Configurations

    This section details the Validation and Compatibility test
  configurations used for testing M2PA for SS7 MTP Level 2 [Q.781]
  conformance.

2.1.1.  Validation Test Configuration

B. Bidulock                    Version 0.7                        Page 5

Internet Draft                  M2PA-TEST                  June 18, 2006

   ___________________________________________________________________
  |                                                                   |
  | TEST ENVIRONMENT                                                  |
  |                                                 MTP Level 3       |
  |                                                  Simulator        |
  |                                                      :            |
  |         _________                                ____:____        |
  |        |         |          M2PA Link           |         |       |
  |        |   PT    |______________________________|   IUT   |       |
  |        |         |      |                       |         |       |
  |        |_________|      |         SCTP          |_________|       |
  |                         |      Association                        |
  |           SP B      ____|____                      SP A           |
  |                    |         |                                    |
  |                    |   M2PA  |                                    |
  |                    | Monitor |                                    |
  |                    |_________|                                    |
  |                                                                   |
  |___________________________________________________________________|

              Figure 2.1.1-1.  Validation Test Configuration

    Figure 2.1.1-1 illustrates the Validation Test Configuration.  The
  Validation Test environment contains the following essential
  components:

   (1)   Implementation Under Test (IUT) -- An implementation for
         validation testing acting as "SP A".

   (2)   Protocol Tester (PT) -- A protocol testing device acting as "SP
         B".

   (3)   MTP Level 3 Simulator -- A simulation device or function used
         to issue commands and collect response to and from the SS7
         MTP2-User Peer-to-Peer Adaptation Layer [M2PA] implementation
         at position "SP A".

   (4)   M2PA Monitor -- A device or function used to monitor, capture,
         record and analyze the exchange of M2PA messages between the PT
         and IUT across the IP network in SCTP associations.

   (5)   IP Network -- An intervening IP network used to form SCTP
         associations between PT and IUT and to exchange messages.

   (6)   SCTP Associations -- An single SCTP connection formed between
         the PT and IUT for the exchange of M2PA messages.

    For this configuration, the interface between the Implementation
  Under Test (IUT) and the MTP Level 3 Simulator is that described in
  the SS7 Test Specification [Q.780].  This is the normal configuration
  for SS7 MTP Level 2 testing [Q.781] with the exception that an M2PA
  [M2PA] signalling link has been interposed for an SS7 signalling link

B. Bidulock                    Version 0.7                        Page 6

Internet Draft                  M2PA-TEST                  June 18, 2006

  [Q.703].

    All test cases in this document should be executed when performing
  Validation testing.

2.1.2.  Compatibility Test Configuration

   ___________________________________________________________________
  |                                                                   |
  | TEST ENVIRONMENT                                                  |
  |                                                                   |
  |        MTP Level 3                              MTP Level 3       |
  |         Simulator                                Simulator        |
  |             :                                        :            |
  |         ____:____                                ____:____        |
  |        |         |          M2PA Link           |         |       |
  |        |   IUT   |______________________________|   IUT   |       |
  |        |         |      |                       |         |       |
  |        |_________|      |         SCTP          |_________|       |
  |                         |      Association                        |
  |           SP B      ____|____                      SP A           |
  |                    |         |                                    |
  |                    |   M2PA  |                                    |
  |                    | Monitor |                                    |
  |                    |_________|                                    |
  |                                                                   |
  |___________________________________________________________________|

            Figure 2.1.2-1.  Compatibility Test Configuration

    Figure 2.1.2-1 illustrates the Compatibility Test Configuration.
  The Compatibility Test environment contains the following essential
  components:

   (1)   Implementation Under Test (IUT) -- An implementation for
         compatibility testing acting as "SP A".

   (2)   Implementation Under Test (IUT) -- An implementation for
         compatibility testing acting as "SP B".

   (3)   MTP Level 3 Simulator -- A simulation device or function used
         to issue commands and collect responses to and from the SS7
         MTP2-User Peer-to-Peer Adaptation Layer [M2PA] implementation
         at position "SP A".

   (4)   MTP Level 3 Simulator -- A simulation device or function used
         to issue commands and collect responses to and from the SS7
         MTP2-User Peer-to-Peer Adaptation Layer [M2PA] implementation
         at position "SP B".

   (5)   M2PA Monitor -- A device or function used to monitor, capture,
         record and analyze the exchange of M2PA messages between the

B. Bidulock                    Version 0.7                        Page 7

Internet Draft                  M2PA-TEST                  June 18, 2006

         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.

    For this configuration, the interface between each Implementation
  Under Test (IUT) and the MTP Level 3 Simulator is that described in
  the SS7 Test Specifications [Q.780].  Tihs is the normal configuration
  to SS7 MTP Level 2 testing [Q.781] with the exception that an M2PA
  [M2PA] signalling link has been interposed for an SS7 signalling link
  [Q.703].

    Only select test case apply to Compatibility testing in accordance
  with the SS7 MTP Level 2 Test Specification [Q.781].

2.1.3.  Interoperability Test Configuration

    The interoperability test configuration closely resembles that for
  compatibility testing as illustrated in Figure 2.1.2-1, above, with
  the exception that the MTP Level 3 Simulator typically has more
  capabilities for controlling the implementation during testing.  For
  example, the MTP Level 3 Simulator can in some instances be capable of
  closely controlling the sequence of messages generated by the
  implementation and may even be able to inject or withhold messages
  during testing.

2.2.  Testing Methodology

    The normal methodology for testing SS7 MTP Level 2 [Q.781] is to
  perform Validation testing on an IUT before performing Compatibility
  testing.  The tests presented in this document test functionality the
  the M2PA MTP Level 2 state machines; however, they do not adequately
  test the M2PA L2 to L3 interface.

    To complete Validation and Compatibility testing of M2PA, the
  Validation and Compatibility tests present in the SS7 MTP Level 3 Test
  Specification [Q.782] SHOULD be performed with M2PA links in the test
  environment to assure that the M2PA IUT has properly implemented the
  L2 to L3 interface.

2.3.  Recommended IUT Settings

    The following settings are recommended<1> for use with both
  Validation and Compatibility testing, in the absence of other
  recommended values to be adopted by the PT and IUT.

2.3.1.  Timer Values

    It is recommended<1> that the timer values listed in Table 2.3.1-1
  be configured at the IUT for the purposes of performing both

B. Bidulock                    Version 0.7                        Page 8

Internet Draft                  M2PA-TEST                  June 18, 2006

  validation and compatibility tests.

              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.7                        Page 9

Internet Draft                  M2PA-TEST                  June 18, 2006

            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.7                       Page 10

Internet Draft                  M2PA-TEST                  June 18, 2006

2.3.5.  Labeling of Sequence Numbers

    Messages containing significant sequence numbers have the sequence
  numbered labeled in the test diagram.  An example is illustrated
  below.

   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                           BSN      FSN                            |
  |                                                                   |
  |              DATA-ACK  --FFFFFF, 000000->                         |
  |                           FSN      BSN                            |
  |                                                                   |
  |                        <-FFFFFF, 000001--  DATA [   35 bytes]     |
  |                           BSN      FSN                            |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000000, 000000->                         |
  |                           FSN      BSN                            |
  |                                                                   |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |              DATA-ACK  --000000, 000001->                         |
  |                           FSN      BSN                            |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-FFFFFF, 000001--  PROCESSOR-RECOVERED    |
  |                           BSN      FSN                            |
  |                                                                   |
  |                 READY  --FFFFFF, 000001->                         |
  |                           FSN      BSN                            |
  |                                            :msu                   |
  |                        <-FFFFFF, 000002--  DATA [   35 bytes]     |
  |                           BSN      FSN                            |
  |                                                                   |
  |              DATA-ACK  --FFFFFF, 000002->                         |
  |                           FSN      BSN                            |
  |                                                                   |
  |___________________________________________________________________|

    Figure 2.3.5-0 illustrates the labeling of sequence numbers.  The
  Forward Sequence Number (FSN) is always labeled closest to the SP
  originating the message.  The Backward Sequence Number (BSN) is always
  labeled closest to the SP receiving the message.

B. Bidulock                    Version 0.7                       Page 11

Internet Draft                  M2PA-TEST                  June 18, 2006

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

B. Bidulock                    Version 0.7                       Page 12

Internet Draft                  M2PA-TEST                  June 18, 2006

  No.      Title                                        VAT   CPT   IOT
  ----------------------------------------------------------------------
  3.1.18   Set and cease emergency                      VAT    -     -
           prior to "start alignment"
  3.1.19   Set emergency while in "not aligned" state   VAT   CPT   IOT
  3.1.20   Set emergency when "aligned"                 VAT    -    IOT
  3.1.21   Both ends set emergency.                     VAT    -    IOT
  3.1.22   Individual end sets emergency                VAT    -    IOT
  3.1.23   Set emergency during normal proving          VAT    -    IOT
  3.1.24   No status "Alignment" sent                   VAT    -     -
           during emergency alignment
  3.1.25   Deactivation during initial alignment        VAT   CPT   IOT
  3.1.26   Deactivation during aligned state            VAT    -     -
  3.1.27   Deactivation during aligned not ready        VAT    -    IOT
  3.1.28   Status "alignment" received                  VAT    -     -
           during link in service
  3.1.29   Status "out of service" received             VAT   CPT   IOT
           during link in service
  3.1.30   Deactivation during LPO                      VAT    -    IOT
  3.1.31   Deactivation during RPO                      VAT    -    IOT
  3.1.32   Deactivation during the proving period       VAT   CPT   IOT
  3.1.33   Status "Alignment" received                  VAT    -     -
           instead of status "Ready"
  3.1.34   Status "Out of Service" received             VAT    -     -
           instead of status "Ready"
  3.1.35   Status "Processor Outage" received           VAT    -    IOT
           instead of status "Ready"
  3.2.1    Unexpected signal units/orders               VAT    -     -
           in "Out of service" state
  3.2.2    Unexpected signal units/orders               VAT    -     -
           in "Not Aligned" state
  3.2.3    Unexpected signal units/orders               VAT    -     -
           in "Aligned" state
  3.2.4    Unexpected signal units/orders               VAT    -     -
           in "Proving" state
  3.2.5    Unexpected signal units/orders               VAT    -     -
           in "Aligned Ready" state
  3.2.6    Unexpected signal units/orders               VAT    -     -
           in "Aligned Not Ready" state
  3.2.7    Unexpected signal units/orders               VAT    -     -
           in "In Service" state
  3.2.8    Unexpected signal units/orders               VAT    -     -
           in "Processor Outage" state
  3.3.1    Link aligned ready (Abort)                   VAT    -     -
  3.3.2    Link aligned ready (Corrupt FIBs)             -     -     -
  3.3.3    Link aligned not ready (Abort)               VAT    -     -
  3.3.4    Link aligned not ready (Corrupt FIBs)         -     -     -
  3.3.5    Link in service (Abort)                      VAT   CPT   IOT
  3.3.6    Link in service (Corrupt FIBs)                -     -     -
  3.3.7    Link in processor outage (Abort)             VAT    -    IOT
  3.3.8    Link in processor outage (Corrupt FIBs)       -     -     -
  3.4.1    Set and clear LPO while link in service      VAT    -    IOT

B. Bidulock                    Version 0.7                       Page 13

Internet Draft                  M2PA-TEST                  June 18, 2006

  No.      Title                                        VAT   CPT   IOT
  ----------------------------------------------------------------------
  3.4.2    RPO during LPO                               VAT    -    IOT
  3.4.3    Clear LPO when "Both processor outage"       VAT    -    IOT
  3.5.1    More than 7 ones between MSU opening and      -     -     -
           closing flags
  3.5.2    Greater than maximum signal unit length       -     -     -
  3.5.3    Below minimum signal unit length             VAT    -     -
  3.5.4    Reception of single and multiple              -     -     -
           flags between FISUs
  3.5.5    Reception of single and multiple              -     -     -
           flags between MSUs
  3.6.1    Error rate of 1 in 256                        -     -     -
           - Link remains in service
  3.6.2    Error rate of 1 in 254                        -     -     -
           - Link out of service
  3.6.3    Consecutive corrupt SUs                       -     -     -
  3.6.4    Time controlled break of the link             -     -     -
  3.7.1    Error rate below the normal threshold         -     -     -
  3.7.2    Error rate at the normal threshold            -     -     -
  3.7.3    Error rate above the normal threshold         -     -     -
  3.7.4    Error rate at the emergency threshold         -     -     -
  3.8.1    Data transmission and reception              VAT   CPT   IOT
  3.8.2    Negative acknowledgments of an MSU            -     -     -
  3.8.3    Check RTB full                               VAT    -     -
  3.8.4    Single invalid Ack                           VAT    -     -
  3.8.5    Duplicated FSN                               VAT    -     -
  3.8.6    Erroneous retransmission - Single MSU         -     -     -
  3.8.7    Erroneous retransmission - Multiple FISUs     -     -     -
  3.8.8    Single FISU with corrupt FIB                 VAT    -     -
  3.8.9    In Service prior to RPO being set            VAT    -    IOT
  3.8.10   Abnormal BSN - single Data message           VAT    -     -
  3.8.11   Abnormal BSN - two consecutive messages      VAT    -     -
  3.8.12   Excessive delay of acknowledgments           VAT    -     -
  3.8.13   Level 3 Stop command                         VAT    -    IOT
  3.9.1    MSU transmission and reception                -     -     -
  3.9.2    Priority control                              -     -     -
  3.9.3    Forced retransmission with the value N1       -     -     -
  3.9.4    Forced retransmission with the value N2       -     -     -
  3.9.5    Forced retransmission cancel                  -     -     -
  3.9.6    Reception of forced retransmission            -     -     -
  3.9.7    MSU transmission while RPO set                -     -     -
  3.9.8    Abnormal BSN - Single MSU                     -     -     -
  3.9.9    Abnormal BSN - Two MSUs                       -     -     -
  3.9.10   Unexpected FSN                                -     -     -
  3.9.11   Excessive delay of acknowledgments            -     -     -
  3.9.12   FISU with FSN expected for MSU                -     -     -
  3.9.13   Level 3 Stop command                          -     -     -
  3.10.1   Congestion abatement                         VAT    -    IOT
  3.10.2   Timer T7                                     VAT    -     -
  3.10.3   Timer T6                                     VAT    -     -

B. Bidulock                    Version 0.7                       Page 14

Internet Draft                  M2PA-TEST                  June 18, 2006

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.7                       Page 15

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 16

Internet Draft                  M2PA-TEST                  June 18, 2006

                        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.7                       Page 17

Internet Draft                  M2PA-TEST                  June 18, 2006

                        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

B. Bidulock                    Version 0.7                       Page 18

Internet Draft                  M2PA-TEST                  June 18, 2006

  events is illustrated in Figure 3.1.4-1.

                        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.

B. Bidulock                    Version 0.7                       Page 19

Internet Draft                  M2PA-TEST                  June 18, 2006

   (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.

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.)

B. Bidulock                    Version 0.7                       Page 20

Internet Draft                  M2PA-TEST                  June 18, 2006

   (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.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.

B. Bidulock                    Version 0.7                       Page 21

Internet Draft                  M2PA-TEST                  June 18, 2006

   (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
  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.7                       Page 22

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 23

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 1.6
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                        <-000000, FFFFFF--  DATA-ACK               |
  |                                            !in service            |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

     Figure 3.1.6-1.  Normal alignment procedure (Data) with proving

  Test Description:

   (1)   The test begins with the link "Out of Service" and the IUT set
         to perform proving.

   (2)   The Level 3 "Start" command is issued at the IUT and the PT.

   (3)   Check that the IUT sends the message sequence illustrated in
         Figure 3.1.6-1.  (Note that the IUT may send additional status
         "Out of Service," status "Alignment" or status "Proving Normal"
         messages.)

   (4)   Check that the IUT sends a status "Ready" message and indicates
         "In Service" to Level 3.

   (5)   Check that the IUT acknowledges the Data message with a "Data
         Ack" message.

   (6)   The IUT should maintain the "In Service" state.

3.1.6.2.  Correct Procedure (Data) without Proving

    This test is performed with the IUT set to disable proving.  This
  test is only applicable if the IUT supports suppression of the proving
  period.  The expected sequence of events is illustrated in Figure
  3.1.6-2.

B. Bidulock                    Version 0.7                       Page 24

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 1.6
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  READY                  |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                        <-000000, FFFFFF--  DATA-ACK               |
  |                                            !in service            |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

    Figure 3.1.6-2.  Normal alignment procedure (Data) without proving

  Test Description:

   (1)   The test begins with the link "Out of Service" and the IUT set
         to not perform proving.

   (2)   The Level 3 "Start" command is issued at the IUT and the PT.

   (3)   Check that the IUT sends the message sequence illustrated in
         Figure 3.1.6-2.

   (4)   Check that the IUT sends a status "Ready" message and indicates
         "In Service" to Level 3.

   (5)   Check that the IUT acknowledges the Data message with a "Data
         Ack" message.

   (6)   The IUT should maintain the "In Service" state.

3.1.7.  Status "Alignment" received during normal proving period

    This test case validates that the IUT restarts the alignment and
  proving procedure when receiving a status "Alignment" message in the
  "Proving" state.  The expected sequence of events is illustrated in
  Figure 3.1.7-1.

B. Bidulock                    Version 0.7                       Page 25

Internet Draft                  M2PA-TEST                  June 18, 2006

                        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.7                       Page 26

Internet Draft                  M2PA-TEST                  June 18, 2006

3.1.8.1.  Forward Direction with Proving

    The test is performed in the forward direction.  The expected
  sequence of events is illustrated in Figure 3.1.8-1.

                      Reference:  Q.781/Test 1.8(a)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                 READY  ----------------->                         |
  |                  !rpo                                             |
  |                                                                   |
  |___________________________________________________________________|

              Figure 3.1.8-1.  Normal alignment with PO set

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state and
         SP A set to perform proving.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Start"
         commands at SP A and the "Start" command at SP B.

   (3)   Check that SP A sends the message sequence illustrated in
         Figure 3.1.8-1.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   Check that SP A sends status "Processor Outage" message.

   (5)   Check that the link maintains the "Processor Outage" state at
         SP A.

3.1.8.2.  Reverse Direction with Proving

    This case is the same test in the reverse direction.  The expected
  sequence of events is illustrated in Figure 3.1.8-2.

B. Bidulock                    Version 0.7                       Page 27

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 1.8(b)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |              :set lpo                                             |
  |                :start                                             |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            !rpo                   |
  |                                                                   |
  |___________________________________________________________________|

              Figure 3.1.8-2.  Normal alignment with PO set

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state and
         SP A set to perform proving.

   (2)   Issue the Level 3 "Local Processor Outage" and "Start" command
         at SP B and the "Start" command at SP A.

   (3)   Check that SP A sends the message sequence illustrated in
         Figure 3.1.8-2.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   Check that SP A sends status "Ready" message and indicates
         "Remote Processor Outage" indication to Level 3.

   (5)   Check that the link maintains the "Processor Outage" state at
         SP A.

3.1.8.3.  Forward Direction without Proving

    The test is performed in the forward direction with the IUT set to
  not perform proving.  This test is only applicable if the IUT supports
  suppression of the proving period.  The expected sequence of events is
  illustrated in Figure 3.1.8-3.

B. Bidulock                    Version 0.7                       Page 28

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 1.8(a)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                 READY  ----------------->                         |
  |                  !rpo                                             |
  |                                                                   |
  |___________________________________________________________________|

              Figure 3.1.8-3.  Normal alignment with PO set

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state and
         SP A set to not perform proving.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Start"
         commands at SP A and the "Start" command at SP B.

   (3)   Check that SP A sends the message sequence illustrated in
         Figure 3.1.8-3.

   (4)   Check that SP A sends status "Processor Outage" message.

   (5)   Check that the link maintains the "Processor Outage" state at
         SP A.

3.1.8.4.  Reverse Direction without Proving

    This case is the same test in the reverse direction. with the IUT
  set to not perform proving.  This test is only applicable if the IUT
  supports suppression of the proving period.  The expected sequence of
  events is illustrated in Figure 3.1.8-4.

B. Bidulock                    Version 0.7                       Page 29

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 1.8(b)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |              :set lpo                                             |
  |                :start                                             |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  READY                  |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            !rpo                   |
  |                                                                   |
  |___________________________________________________________________|

              Figure 3.1.8-4.  Normal alignment with PO set

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state and
         SP A set to not perform proving.

   (2)   Issue the Level 3 "Local Processor Outage" and "Start" command
         at SP B and the "Start" command at SP A.

   (3)   Check that SP A sends the message sequence illustrated in
         Figure 3.1.8-4.

   (4)   Check that SP A sends status "Ready" message and indicates
         "Remote Processor Outage" indication to Level 3.

   (5)   Check that the link maintains the "Remote Processor Outage"
         state at SP A.

3.1.9.  Normal alignment with PO set (Data)

    This test case validates the normal alignment procedure at the IUT
  in the "Processor Outage" state when a Data message is used instead of
  an "Ready" message to complete the alignment procedure.

3.1.9.1.  Forward Direction with Proving

    The test is performed in the forward direction.  The expected
  sequence of events is illustrated in Figure 3.1.9-1.

B. Bidulock                    Version 0.7                       Page 30

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 31

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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

B. Bidulock                    Version 0.7                       Page 32

Internet Draft                  M2PA-TEST                  June 18, 2006

  illustrated in Figure 3.1.9-3.

                      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.7                       Page 33

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 34

Internet Draft                  M2PA-TEST                  June 18, 2006

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.7                       Page 35

Internet Draft                  M2PA-TEST                  June 18, 2006

                       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.7                       Page 36

Internet Draft                  M2PA-TEST                  June 18, 2006

                       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.7                       Page 37

Internet Draft                  M2PA-TEST                  June 18, 2006

                       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.7                       Page 38

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 39

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 40

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 41

Internet Draft                  M2PA-TEST                  June 18, 2006

                      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.7                       Page 42

Internet Draft                  M2PA-TEST                  June 18, 2006

                       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.7                       Page 43

Internet Draft                  M2PA-TEST                  June 18, 2006

                       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.7                       Page 44

Internet Draft                  M2PA-TEST                  June 18, 2006

                       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.7                       Page 45

Internet Draft                  M2PA-TEST                  June 18, 2006

3.1.15.1.  Forward Direction with Proving

    This test is performed in the forward direction with the IUT set to
  perform proving.  The expected sequence of events is illustrated in
  Figure 3.1.15-1.

                       Reference:  Q.781/Test 1.15
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |                                            :set lpo               |
  |                 READY  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                                            :clear lpo             |
  |                        <-----------------  PROCESSOR-RECOVERED    |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.1.15-1.  Set and clear LPO when "Aligned ready"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue the Level 3 "Start" command at both the IUT and the PT.

   (3)   Check that the IUT follows the normal alignment procedure and
         sequence of events illustrated in Figure 3.1.15-1.  (Note that
         the IUT may send additional status "Out of Service,"
         "Alignment" or "Proving Normal" messages.)

   (4)   When the IUT has completed the initial alignment procedure,
         issues the Level 3 "Set Local Processor Outage" command at the
         IUT.

   (5)   Check that the IUT sends a status "Processor Outage" message.

   (6)   Send a status "Ready" message to the IUT.

B. Bidulock                    Version 0.7                       Page 46

Internet Draft                  M2PA-TEST                  June 18, 2006

   (7)   Check that the IUT indicates "In Service" to Level 3 at the
         IUT.

   (8)   Issue the Level 3 "Clear Local Processor Outage" command at the
         IUT.

   (9)   Check that the IUT sends a status "Processor Recovered"
         message.

   (10)  Send a status "Ready" message to the IUT on the data stream.

   (11)  Check that the IUT enters the "In Service" state.

   (12)  Check that the

3.1.15.2.  Forward Direction without Proving

    This test is performed in the forward direction with the IUT set to
  disable proving.  This test is only applicable if the IUT supports
  suppression of the proving period.  The expected sequence of events is
  illustrated in Figure 3.1.15-2.

                       Reference:  Q.781/Test 1.15
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  READY                  |
  |                                            :set lpo               |
  |                 READY  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                                            :clear lpo             |
  |                        <-----------------  PROCESSOR-RECOVERED    |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.1.15-2.  Set and clear LPO when "Aligned ready"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to not perform proving.

B. Bidulock                    Version 0.7                       Page 47

Internet Draft                  M2PA-TEST                  June 18, 2006

   (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.

   (7)   Check that the IUT sends a status "Processor Recovered"
         message.

   (8)   Send a status "Ready" message to the IUT on the data stream.

   (9)   Check that the IUT indicates "In Service" to Level 3 at the
         IUT.

3.1.16.  Timer T1 in "Aligned not ready" state

    This test case validates the T1 timer and procedures at the IUT when
  the IUT is in the "Aligned Not Ready" state.

3.1.16.1.  Forward Direction with Proving

    This test is performed in the forward direction with the IUT set to
  perform proving.  The expected sequence of events is illustrated in
  Figure 3.1.16-1.

B. Bidulock                    Version 0.7                       Page 48

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.16
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                        <-----------------  PROCESSOR-OUTAGE (Note)|
  |                              !                                    |
  |                              !  T1         40.0 <= T1 <= 50.0     |
  |                              !                                    |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(T1)    |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.1.16-1.  Timer T1 in "Aligned not ready" state

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Start"
         commands at SP A and "Start" command at SP B.

   (3)   Check that SP A follows the sequence of events illustrated in
         Figure 3.1.16-1 while completing the initial alignment
         procedure.  (Note that SP A or B may send additional status
         "Out of Service," "Alignment" or "Proving Normal" messages.)
         (Note that SP A may send additional status "Processor Outage"
         messages before sending the status "Out of Service" message.)

   (4)   Check that SP A sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 with reason "T1 Timeout".

   (5)   Check that T1 is between 40.0 seconds and 50.0 seconds in
         duration.

3.1.16.2.  Forward Direction without Proving

    This test is performed in the forward direction with the IUT set to
  disable proving.  This test is only applicable if the IUT supports

B. Bidulock                    Version 0.7                       Page 49

Internet Draft                  M2PA-TEST                  June 18, 2006

  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.  <Note that SP A may send additional status
         "Processor Outage" messages before sending the status "Out of
         Service" message.)

   (4)   Check that SP A sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 with reason "T1 Timeout".

   (5)   Check that T1 is between 40.0 seconds and 50.0 seconds in
         duration.

3.1.17.  No status "Alignment" sent during normal proving period

    This test validates that the normal alignment procedure completes at
  the IUT when no status "Alignment" message is sent.  The expected

B. Bidulock                    Version 0.7                       Page 50

Internet Draft                  M2PA-TEST                  June 18, 2006

  sequence of events is illustrated in Figure 3.1.17-1.

                       Reference:  Q.781/Test 1.17
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |                              !                                    |
  |                              !  T3+T4(Pn)  7.5 <= T3+T4 <= 11.0   |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

      Figure 3.1.17-1.  No "Alignment" during normal proving period

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue the Level 3 "Start" command at both the IUT and the PT.

   (3)   Respond to status "Alignment" message sent by the IUT with a
         status "Proving Normal" message and continue proving.  (Note
         that the IUT may send additional status "Out of Service,"
         "Alignment" or "Proving Normal" messages.)

   (4)   Check that the IUT sends a status "Ready" message within T4(Pn)
         plus T3.

   (5)   Check that the delay from the start of the proving period to
         the status "Ready" message T4(Pn)+T3 is between 7.5 seconds and
         11.0 seconds in duration.

3.1.18.  Set and cease emergency prior to "start alignment"

    This test case validates the behavior of the IUT when the Level 3
  "Set Emergency" and "Clear Emergency" commands are issued prior to the
  Level 3 "Start" command at the IUT.  The expected sequence of events
  is illustrated in Figure 3.1.18-1.

B. Bidulock                    Version 0.7                       Page 51

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.18
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set emergency         |
  |                                            :clear emergency       |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                              !                                    |
  |                              !  T4(Pn)     7.5 <= T4 <= 10.0      |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

       Figure 3.1.18-1.  Toggle emergency before "start alignment"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue the Level 3 "Set Emergency," "Clear Emergency" then
         "Start" commands at the IUT and "Start" command at the PT.

   (3)   Check that the sequence of events are as illustrated in Figure
         3.1.18-1.  Check that the IUT sends a status "Proving Normal"
         message in response to the "Alignment" message.  (Note that the
         IUT may send additional status "Out of Service," "Alignment" or
         "Proving Normal" messages.)

   (4)   Check that the IUT sends a status "Ready" message.

   (5)   Check that the IUT uses a normal proving period by timing the
         delay from the status "Proving Normal" message to the status
         "Ready" message sent by the IUT.

   (6)   Check that T4 is between 7.5 seconds and 10.0 seconds in
         duration.

3.1.19.  Set emergency while in "not aligned" state

    This test case validates the behavior of the IUT when the Level 3
  "Set Emergency" command is issued at the IUT immediately after the
  Level 3 "Start" command (when the IUT is in the "Not Aligned" state).

B. Bidulock                    Version 0.7                       Page 52

Internet Draft                  M2PA-TEST                  June 18, 2006

  The expected sequence of events is illustrated in Figure 3.1.19-1.

                       Reference:  Q.781/Test 1.19
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                                            :set emergency         |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-EMERGENCY      |
  |     PROVING-EMERGENCY  ----------------->                         |
  |                              !                                    |
  |                              !  T4(Pe)     0.4 <= T4 <= 0.6       |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.1.19-1.  Set emergency in "not aligned" state

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Start" and "Set Emergency" commands at SP A
         and "Start" command at SP B.

   (3)   Check that the sequence of events are as illustrated in Figure
         3.1.19-1.  Check that SP A sends a status "Proving Emergency"
         message in response to the "Alignment" message.  (Note that SP
         A or B may send additional status "Out of Service," "Alignment"
         or "Proving Emergency" messages.)

   (4)   Check that SP A sends a status "Ready" message.

   (5)   Check that SP A uses an emergency proving period by timing the
         delay from the status "Proving Emergency" message to the status
         "Ready" message sent by SP A.

   (6)   Check that T4 is between 0.4 seconds and 0.6 seconds in
         duration.

B. Bidulock                    Version 0.7                       Page 53

Internet Draft                  M2PA-TEST                  June 18, 2006

3.1.20.  Set emergency when "aligned"

    This test case validates the response of the IUT to the Level 3 "Set
  Emergency" command when issued in the "Aligned" state at the IUT.  The
  expected sequence of events is illustrated in Figure 3.1.20-1.

                       Reference:  Q.781/Test 1.20
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                                            :set emergency         |
  |                        <-----------------  PROVING-EMERGENCY      |
  |                              !                                    |
  |                              !  T4(Pe)     0.4 <= T4 <= 0.6       |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

              Figure 3.1.20-1.  Set emergency when "aligned"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Start" command at SP A and SP B.

   (3)   Check that the normal alignment procedure starts as illustrated
         in Figure 3.1.20-1.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   Before the normal proving period completes, issue the Level 3
         "Set Emergency" command at SP A.

   (5)   Check that SP A sends a status "Proving Emergency" message and
         later follows with a status "Ready" message.  (Note that SP A
         may send additional status "Proving Emergency" messages.)

   (6)   Check that SP A begins an emergency proving period by timing
         the delay from the status "Proving Emergency" message to the

B. Bidulock                    Version 0.7                       Page 54

Internet Draft                  M2PA-TEST                  June 18, 2006

         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 in
  Figure 3.1.21-1.

                       Reference:  Q.781/Test 1.21
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set emergency         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-EMERGENCY      |
  |     PROVING-EMERGENCY  ----------------->                         |
  |                              !                                    |
  |                              !  T4(Pe)     0.4 <= T4 <= 0.6       |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

                Figure 3.1.21-1.  Both ends set emergency

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Set Emergency" and "Start" commands at SP A
         and the "Start" command at SP B.

   (3)   Check that SP A starts the emergency alignment procedure by
         sending a status "Proving Emergency" message.

   (4)   Check that SP A follows the sequence of events as illustrated
         in Figure 3.1.21-1.  Check that SP A completes the alignment
         procedure and sends a status "Ready" message.  (Note that SP A
         or B may send additional status "Out of Service," "Alignment"
         or "Proving Emergency" messages.)

B. Bidulock                    Version 0.7                       Page 55

Internet Draft                  M2PA-TEST                  June 18, 2006

   (5)   Check that SP A uses an emergency proving period by timing the
         delay between sending the status "Proving Normal" message and
         the status "Ready" message.

   (6)   Check that T4 is between 0.4 seconds and 0.6 seconds in
         duration.

3.1.22.  Individual end sets emergency

    This test case validates the behavior of the IUT when emergency is
  individually set at the PT before the initial alignment procedure
  begins.  The expected sequence of events is illustrated in Figure
  3.1.22-1.

                       Reference:  Q.781/Test 1.22
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |            :set emerg                                             |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |     PROVING-EMERGENCY  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |                              !                                    |
  |                              !  T4(Pe)     0.4 <= T4 <= 0.6       |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

             Figure 3.1.22-1.  Individual end sets emergency

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Set Emergency" and "Start" commands at SP B
         and the "Start" command at SP A.

   (3)   Check that the sequence of events follows that illustrated in
         Figure 3.1.22-1.

   (4)   Check that SP A uses the emergency proving period by timing the
         delay between the status "Proving Normal" message and the
         status "Ready" message.  (Note that SP B may send additional

B. Bidulock                    Version 0.7                       Page 56

Internet Draft                  M2PA-TEST                  June 18, 2006

         status "Out of Service," "Alignment" or "Proving Emergency"
         messages.)  (Note that SP A may send additional status "Out of
         Service," "Alignment" or "Proving Normal" messages.)

   (5)   Check that T4 is between 0.4 seconds and 0.6 seconds in
         duration.

3.1.23.  Set emergency during normal proving

    This test case validates the IUT behavior when it receives a Level 3
  "Set Emergency" command after it has already commenced normal proving.
  The expected sequence of events is illustrated in Figure 3.1.23-1.

                       Reference:  Q.781/Test 1.23
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                                            :set emergency         |
  |                        <-----------------  PROVING-EMERGENCY      |
  |                              !                                    |
  |                              !  T4(Pe)     0.4 <= T4 <= 0.6       |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.1.23-1.  Set emergency during normal proving

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Start" command at SP A and SP B.

   (3)   Check that the sequence of events follows that illustrated in
         Figure 3.1.23-1.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   Before the normal proving period completes at SP A, issue the
         Level 3 "Set Emergency" command at SP A.

B. Bidulock                    Version 0.7                       Page 57

Internet Draft                  M2PA-TEST                  June 18, 2006

   (5)   Check that SP A sends a status "Proving Emergency" message and
         continues proving.  (Note that SP A may send additional status
         "Proving Emergency" messages.)

   (6)   Check that SP A sends a status "Ready" message.

   (7)   Check that SP A uses an emergency proving period by timing the
         delay between the status "Proving Emergency" message and the
         status "Ready" message.

   (8)   Check that T4 is between 0.4 seconds and 0.6 seconds in
         duration.

3.1.24.  No status "Alignment" sent during emergency alignment

    This test case validates the response of the IUT to receiving a
  status "Proving Normal" without a status "Alignment" during initial
  alignment using an emergency proving period.  The expected sequence of
  events is illustrated in Figure 3.1.24-1.

                       Reference:  Q.781/Test 1.24
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set emergency         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |     PROVING-EMERGENCY  ----------------->                         |
  |                        <-----------------  PROVING-EMERGENCY      |
  |                              !                                    |
  |                              !  T4(Pe)     0.4 <= T4 <= 0.6       |
  |                              !                                    |
  |                        <-----------------  READY                  |
  |                                                                   |
  |___________________________________________________________________|

       Figure 3.1.24-1.  No "Alignment" during emergency alignment

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue the Level 3 "Set Emergency" and "Start" commands at both
         the IUT and PT.

   (3)   Check that the IUT sends a status "Proving Emergency" message
         and starts proving.  (Note that the IUT may send additional

B. Bidulock                    Version 0.7                       Page 58

Internet Draft                  M2PA-TEST                  June 18, 2006

         status "Out of Service," "Alignment" or "Proving Emergency"
         messages.)

   (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 in Figure
  3.1.25-1.

                       Reference:  Q.781/Test 1.25
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.1.25-1.  Deactivate during initial alignment

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state.

   (2)   Issue the Level 3 "Start" command at SP A.

   (3)   Before timer T2 expires, issue the Level 3 "Stop" command at
         the IUT.

   (4)   Check that SP A sends a status "Out of Service" message and
         stays in the "Out of Service" state.

B. Bidulock                    Version 0.7                       Page 59

Internet Draft                  M2PA-TEST                  June 18, 2006

3.1.26.  Deactivation during aligned state

    This test case validates the behavior of the IUT in response to the
  Level 3 "Stop" command issued during "Aligned" state at the IUT.  The
  expected sequence of events is illustrated in Figure 3.1.26-1.

                       Reference:  Q.781/Test 1.26
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.1.26-1.  Deactivate during aligned state

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue the Level 3 "Start" command at the IUT and the PT.

   (3)   Check that the IUT follows the sequence of events illustrated
         in Figure 3.1.26-1.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   Issue the Level 3 "Stop" command at the IUT.

   (5)   Check that the IUT sends a status "Out of Service" message and
         stays in the "Out of Service" state.

3.1.27.  Deactivation during aligned not ready

    This test case validates the behavior of the IUT in response to the
  Level 3 "Stop" command issued during the "Aligned Not Ready" state at
  the IUT.

3.1.27.1.  Forward Direction with Proving

    This test is performed in the forward direction with the IUT set to
  perform proving.  The expected sequence of events is illustrated in

B. Bidulock                    Version 0.7                       Page 60

Internet Draft                  M2PA-TEST                  June 18, 2006

  Figure 3.1.27-1.

                       Reference:  Q.781/Test 1.27
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.1.27-1.  Deactivate during aligned not ready

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Start"
         commands at SP A and the "Start" command at the PT.

   (3)   Check that SP A follows the sequence of events illustrated in
         Figure 3.1.27-1 and sends a status "Processor Outage" message.
         (Note that SP A or B may send additional status "Out of
         Service," "Alignment" or "Proving Normal" messages.)

   (4)   Issue the Level 3 "Stop" command at SP A.

   (5)   Check that SP A sends a status "Out of Service" message and
         stays in the "Out of Service" state.

3.1.27.2.  Forward Direction without Proving

    This test is performed in the forward direction with the IUT set to
  disable proving.  This test is only applicable if the IUT supports
  suppression of the proving period.  The expected sequence of events is
  illustrated in Figure 3.1.27-2.

B. Bidulock                    Version 0.7                       Page 61

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.27
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.1.27-2.  Deactivate during aligned not ready

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to not perform proving.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Start"
         commands at SP A and the "Start" command at SP B.

   (3)   Check that SP A follows the sequence of events illustrated in
         Figure 3.1.27-2 and sends a status "Processor Outage" message.

   (4)   Issue the Level 3 "Stop" command at SP A.

   (5)   Check that SP A sends a status "Out of Service" message and
         stays in the "Out of Service" state.

3.1.28.  Status "alignment" received during link in service

    This test case validates the IUT response to receiving a status
  "Alignment" message in the "In Service" state.  The expected sequence
  of events is illustrated in Figure 3.1.28-1.

B. Bidulock                    Version 0.7                       Page 62

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.28
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(SIO)   |
  |                                                                   |
  |___________________________________________________________________|

           Figure 3.1.28-1.  "Alignment" during link in service

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send a status "Alignment" to the IUT.

   (3)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 with reason "Received
         SIO".

3.1.29.  Status "out of service" received during link in service

    This test case validates the response of the IUT to sending or
  receiving a status "Out of Service" message in the "In Service" state.

3.1.29.1.  Forward Direction

    The test case is performed in the forward direction.  The expected
  sequence of events is illustrated in Figure 3.1.29-1.

                      Reference:  Q.781/Test 1.29(a)
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                 :stop                                             |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(SIOS)  |
  |                                                                   |
  |___________________________________________________________________|

        Figure 3.1.29-1.  "Out of service" during link in service

  Test Description:

B. Bidulock                    Version 0.7                       Page 63

Internet Draft                  M2PA-TEST                  June 18, 2006

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Stop" command at SP B and send a status "Out
         of Service" message to SP A.

   (3)   Check that SP A sends a status "Out of Service" message and
         indicates "Out of Service" to the Level 3 at SP A with reason
         "Received SIOS".

3.1.29.2.  Reverse Direction

    The test case is repeated in the reverse direction.  The expected
  sequence of events is illustrated in Figure 3.1.29-2.

                      Reference:  Q.781/Test 1.29(b)
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                                                   |
  |___________________________________________________________________|

        Figure 3.1.29-2.  "Out of service" during link in service

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Stop" command at SP A.

   (3)   Check that SP A sends a status "Out of Service" message and
         stays in the "Out of Service" state.

3.1.30.  Deactivation during LPO

    These test cases validate the response of the IUT to sending a
  status "Out of Service" message while in the "Processor Outage" state
  with LPO set, or receiving an "Out of Service" message from an M2PA
  peer in the "Processor Outage" state with RPO set.

3.1.30.1.  Forward Direction

    The test is performed in the forward direction.  The expected
  sequence of events is illustrated in Figure 3.1.30-1.

B. Bidulock                    Version 0.7                       Page 64

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 1.30(a)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                                                   |
  |___________________________________________________________________|

                Figure 3.1.30-1.  Deactivation during LPO

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Set Local Processor Outage" command at SP A.

   (3)   Check that SP A sends a status "Processor Outage" message.

   (4)   Issue the Level 3 "Stop" command at SP A.

   (5)   Check that SP A sends a status "Out of Service" message and
         stays in the "Out of Service" state.

3.1.30.2.  Reverse Direction

    The test is repeated in the reverse direction.  The expected
  sequence of events is illustrated in Figure 3.1.30-2.

                      Reference:  Q.781/Test 1.30(b)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |              :set lpo                                             |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                 :stop                                             |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !rpo                   |
  |                                            !out of service(SIOS)  |
  |                                                                   |
  |___________________________________________________________________|

                Figure 3.1.30-2.  Deactivation during LPO

B. Bidulock                    Version 0.7                       Page 65

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Stop"
         commands at SP B.

   (3)   Check that SP A sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at SP A with reason
         "Received SIOS".

3.1.31.  Deactivation during RPO

    These test cases validate the response of the IUT to sending a
  status "Out of Service" message while in the "Processor Outage" state
  with RPO set, or receiving an "Out of Service" message from an M2PA
  peer in the "Processor Outage" state with LPO set.

3.1.31.1.  Forward Direction

    The test is performed in the forward direction.  The expected
  sequence of events is illustrated in Figure 3.1.31-1.

                      Reference:  Q.781/Test 1.31(a)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                                                   |
  |___________________________________________________________________|

                Figure 3.1.31-1.  Deactivation during RPO

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Set Local Processor Outage" command at SP B
         and send a status "Processor Outage" message to SP A.

   (3)   Issue the Level 3 "Stop" command at SP A.

   (4)   Check that SP A sends the status "Out of Service" message and
         remains in the "Out of Service" state.

B. Bidulock                    Version 0.7                       Page 66

Internet Draft                  M2PA-TEST                  June 18, 2006

3.1.31.2.  Reverse Direction

    The test is repeated in the reverse direction.  The expected
  sequence of events is illustrated in Figure 3.1.31-2.

                      Reference:  Q.781/Test 1.31(b)
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |                 :stop                                             |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                                                   |
  |___________________________________________________________________|

                Figure 3.1.31-2.  Deactivation during RPO

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Set Local Processor Outage" command at SP A.

   (3)   Check that SP A sends a status "Processor Outage" message.

   (4)   Issue the Level 3 "Stop" command at SP B and send the status
         "Out of Service" message.

   (5)   Check that SP A does not indicate "Out of Service" until the
         local processor outage condition recovers.

3.1.32.  Deactivation during the proving period

    These test cases validate the response of the IUT to deactivation
  (sending or receiving a status "Out of Service" message) during the
  proving period.

3.1.32.1.  Forward Direction

    The test is performed in the forward direction.  The expected
  sequence of events is illustrated in Figure 3.1.32-1.

B. Bidulock                    Version 0.7                       Page 67

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 1.32(a)
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                 :stop                                             |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(AERM)  |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.1.32-1.  Deactivation during the proving period

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Start" command at SP A and SP B.

   (3)   Check that SP A follows the sequence of events illustrated in
         Figure 3.1.32-1.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   During the proving period, issue the Level 3 "Stop" command at
         SP B and send status "Out of Service" to SP A.

   (5)   Check that SP A sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at SP A with reason
         "Alignment Not Possible".

3.1.32.2.  Reverse Direction

    The test is repeated in the reverse direction.  The expected
  sequence of events is illustrated in Figure 3.1.32-2.

B. Bidulock                    Version 0.7                       Page 68

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 1.32(b)
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                :start                                             |
  |                                            :start                 |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                        <-----------------  ALIGNMENT              |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.1.32-2.  Deactivation during the proving period

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue the Level 3 "Start" command at SP B and SP A.

   (3)   Check that the sequence of events follows that illustrated in
         Figure 3.1.32-2.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   During the proving period, issue a Level 3 "Stop" command at SP
         A.

   (5)   Check that SP A sends a status "Out of Service" message and
         remains in the "Out of Service" state.

3.1.33.  Status "Alignment" received instead of status "Ready"

    This test case validates the response of the IUT to receiving a
  status "Alignment" message instead of a status "Ready" or "Processor
  Outage" message at the completion of initial alignment.  The expected
  sequence of events is illustrated in Figure 3.1.33-1.

B. Bidulock                    Version 0.7                       Page 69

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.33
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(SIO)   |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.1.33-1.  "Alignment" instead of "In Service"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue a Level 3 "Start" command at the IUT and the PT.

   (3)   Check that the sequence of events follows that illustrated in
         Figure 3.1.33-1.  (Note that the IUT may send additional status
         "Out of Service," "Alignment" or "Proving Normal" messages.)

   (4)   When the IUT sends a status "Ready" message, send a status
         "Alignment" message to the IUT.

   (5)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at the IUT with reason
         "Received SIO".

3.1.34.  Status "Out of Service" received instead of status "Ready"

    This test case validates the response of the IUT to receiving a
  status "Out of Service" message instead of a status "Ready" or
  "Processor Outage" message at the completion of initial alignment.
  The expected sequence of events is illustrated in Figure 3.1.34-1.

B. Bidulock                    Version 0.7                       Page 70

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.34
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |                 :stop                                             |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(SIOS)  |
  |                                                                   |
  |___________________________________________________________________|

        Figure 3.1.34-1.  "Out of Service" instead of "In Service"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with the IUT set to perform proving.

   (2)   Issue a Level 3 "Start" command at the IUT and the PT.

   (3)   Check that the sequence of events follows that illustrated in
         Figure 3.1.34-1.  (Note that the IUT may send additional status
         "Out of Service," "Alignment" or "Proving Normal" messages.)

   (4)   When the IUT sends a status "Ready" message, send a status "Out
         of Service" message to the IUT.

   (5)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at the IUT with reason
         "Received SIOS".

3.1.35.  Status "Processor Outage" received instead of status "Ready"

    This test case validates the response of the IUT to receiving a
  status "Processor Outage" message instead of a status "Ready" message
  at the completion of initial alignment.  The expected sequence of
  events is illustrated in Figure 3.1.35-1.

B. Bidulock                    Version 0.7                       Page 71

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 1.35
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |              :set lpo                                             |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            !rpo                   |
  |                                                                   |
  |___________________________________________________________________|

       Figure 3.1.35-1.  "Processor Outage" instead of "In Service"

  Test Description:

   (1)   The test begins with the link in the "Out of Service" state
         with SP A set to perform proving.

   (2)   Issue a Level 3 "Start" command at SP A and SP B.

   (3)   Check that the sequence of events follows that illustrated in
         Figure 3.1.35-1.  (Note that SP A or B may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   When SP A sends a status "Ready" message, issue a Level 3 "Set
         Local Processor Outage" command at SP B and send a status
         "Processor Outage" message to SP A.

   (5)   Check that SP A indicates "Remote Processor Outage" to Level 3
         at SP A.

3.2.  Link State Control - Unexpected signal units/orders

    This suite of test cases test the response of the Implementation
  Under Test to unexpected sequences Level 3 requests and received M2PA
  messages in various states.  These test cases validates the robustness
  of the implementation in responding to unusual circumstances.

B. Bidulock                    Version 0.7                       Page 72

Internet Draft                  M2PA-TEST                  June 18, 2006

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 in Figure 3.2.1-1.

                        Reference:  Q.781/Test 2.1
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |             ALIGNMENT  ----------------->                         |
  |        PROVING-NORMAL  ----------------->                         |
  |     PROVING-EMERGENCY  ----------------->                         |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |                 READY  ----------------->                         |
  |              DATA-ACK  --FFFFFF, FFFFFF->                         |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :stop                  |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

     Figure 3.2.1-1.  Unexpected events in the "Out of Service" State

  Test Description:

   (1)   The test begins with both M2PA peers in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Out of Service"
           - Status "Alignment"

B. Bidulock                    Version 0.7                       Page 73

Internet Draft                  M2PA-TEST                  June 18, 2006

           - Status "Proving Normal"
           - Status "Proving Emergency"
           - Status "Processor Recovered"
           - Status "Processor Outage"
           - Status "Busy Ended"
           - Status "Busy"
           - Status "Ready"
           - Status Invalid
           - Data Ack
           - Data
           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

   (3)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Stop" command

   (4)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (5)   The Level 3 "Start" command is then issued.

   (6)   Check that the link aligns normally.

   (7)   Check that link alignment uses normal alignment procedures.

   (8)   Check that the link goes in service and stays in service
         without local or remote processor outage indications to Level
         3.

3.2.2.  Unexpected signal units/orders in "Not Aligned" state

    This test case validates the response of the IUT to the receipt of
  unexpected Level 3 requests and receipt of unexpected M2PA messages
  while in the "Not Aligned" state.  All of the unexpected sequences in
  this test case MUST be ignored by the IUT.  The expected sequence of
  events is illustrated in Figure 3.2.2-1.

B. Bidulock                    Version 0.7                       Page 74

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 2.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |        OUT-OF-SERVICE  ----------------->                         |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |            BUSY_ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |                 READY  ----------------->                         |
  |              DATA-ACK  --FFFFFF, FFFFFF->                         |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :clear emergency       |
  |                                            :start                 |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.2.2-1.  Unexpected events while "not aligned"

  Test Description:

   (1)   The test begins with both M2PA peers in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   The Level 3 "Start" command is issued to IUT to place the IUT
         in the "Not Aligned" state.

   (3)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Out of Service"
           - Status "Processor Recovered"
           - Status "Processor Outage"
           - Status "Busy Ended"
           - Status "Busy"
           - Status "Ready"
           - Status Invalid
           - Data Ack

B. Bidulock                    Version 0.7                       Page 75

Internet Draft                  M2PA-TEST                  June 18, 2006

           - Data
           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

   (4)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Clear Emergency" command
           - Level 3 "Start" command

   (5)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (6)   A status "Alignment" is then sent to the IUT.

   (7)   Check that the IUT aligns as usual and performs the normal
         alignment procedures.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (8)   Check that the IUT places the link in service and that no local
         or remote processor outage indications are given to Level 3 at
         the IUT.

3.2.3.  Unexpected signal units/orders in "Aligned" state

    This case validates the response of the IUT to the receipt of
  unexpected Level 3 request and receipt of unexpected M2PA messages
  while in the "Aligned" state.  All of the unexpected sequences in this
  test case MUST be ignored by the IUT.  The expected sequence of events
  is illustrated in Figure 3.2.3-1.

B. Bidulock                    Version 0.7                       Page 76

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 2.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |             ALIGNMENT  ----------------->                         |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |                 READY  ----------------->                         |
  |              DATA-ACK  --FFFFFF, FFFFFF->                         |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :clear emergency       |
  |                                            :start                 |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.2.3-1.  Unexpected events while "aligned"

  Test Description:

   (1)   The test begins with both IUT and PT in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   The IUT is brought to the "Aligned" state using normal
         procedures.

   (3)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Alignment"
           - Status "Processor Recovered"
           - Status "Processor Outage"
           - Status "Busy Ended"
           - Status "Busy"
           - Status "Ready"
           - Status Invalid

B. Bidulock                    Version 0.7                       Page 77

Internet Draft                  M2PA-TEST                  June 18, 2006

           - Data Ack
           - Data
           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

   (4)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Clear Emergency" command
           - Level 3 "Start" command

   (5)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (6)   Check that the IUT aligns as usual and performs the normal
         alignment procedure.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (7)   Check that the IUT places the link in service and that no local
         or remote processor outage indications are given to Level 3 at
         the IUT.

3.2.4.  Unexpected signal units/orders in "Proving" state

    This case validates the response of the IUT to the receipt of
  unexpected Level 3 request and receipt of unexpected M2PA messages
  while in the "Proving" state.  All of the unexpected sequences in this
  test case MUST be ignored by the IUT.  The expected sequence of events
  is illustrated in Figure 3.2.4-1.

B. Bidulock                    Version 0.7                       Page 78

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 2.4
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |                 READY  ----------------->                         |
  |              DATA-ACK  --FFFFFF, FFFFFF->                         |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :clear emergency       |
  |                                            :start                 |
  |                        <-----------------  READY                  |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.2.4-1.  Unexpected events while "proving"

  Test Description:

   (1)   The test begins with both IUT and PT in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   The IUT is brought to the "Proving" state using normal
         procedures.

   (3)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Processor Recovered"
           - Status "Processor Outage"
           - Status "Busy Ended"
           - Status "Busy"
           - Status "Ready"
           - Status Invalid
           - Data Ack
           - Data

B. Bidulock                    Version 0.7                       Page 79

Internet Draft                  M2PA-TEST                  June 18, 2006

           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

   (4)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Clear Emergency" command
           - Level 3 "Start" command

   (5)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (6)   Check that the IUT aligns as usual and performs the normal
         alignment procedure.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (7)   Check that the IUT places the link in service and that no local
         or remote processor outage indications are given to Level 3 at
         the IUT.

3.2.5.  Unexpected signal units/orders in "Aligned Ready" state

    This case validates the response of the IUT to the receipt of
  unexpected Level 3 request and receipt of unexpected M2PA messages
  while in the "Aligned Ready" state.  All of the unexpected sequences
  in this test case MUST be ignored by the IUT.  The expected sequence
  of events is illustrated in Figure 3.2.5-1.

B. Bidulock                    Version 0.7                       Page 80

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 2.5
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :set emergency         |
  |                                            :clear emergency       |
  |                                            :clear lpo             |
  |                                            :start                 |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.2.5-1.  Unexpected events while "aligned ready"

  Test Description:

   (1)   The test begins with both IUT and PT in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   The IUT is brought to the "Aligned Ready" state using normal
         procedures.

   (3)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Processor Recovered"
           - Status "Busy Ended"
           - Status "Busy"
           - Status Invalid
           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

   (4)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

B. Bidulock                    Version 0.7                       Page 81

Internet Draft                  M2PA-TEST                  June 18, 2006

           - Level 3 "Set Emergency" command
           - Level 3 "Clear Emergency" command
           - Level 3 "Clear Local Processor Outage" command
           - Level 3 "Start" command

   (5)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (6)   Check that the IUT aligns as usual and performs the normal
         alignment procedure.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (7)   Check that the IUT places the link in service and that no local
         or remote processor outage indications are given to Level 3 at
         the IUT.

3.2.6.  Unexpected signal units/orders in "Aligned Not Ready" state

    This case validates the response of the IUT to the receipt of
  unexpected Level 3 request and receipt of unexpected M2PA messages
  while in the "Aligned Not Ready" state.  All of the unexpected
  sequences in this test case MUST be ignored by the IUT.  The expected
  sequence of events is illustrated in Figure 3.2.6-1.

B. Bidulock                    Version 0.7                       Page 82

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 2.6
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :set emergency         |
  |                                            :clear emergency       |
  |                                            :set lpo               |
  |                                            :start                 |
  |                 READY  ----------------->                         |
  |                                            !in service            |
  |                                                                   |
  |___________________________________________________________________|

       Figure 3.2.6-1.  Unexpected events while "aligned not ready"

  Test Description:

   (1)   The test begins with both IUT and PT in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   The IUT is brought to the "Aligned Not Ready" state using
         normal procedures.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (3)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Processor Recovered"
           - Status "Busy Ended"
           - Status "Busy"
           - Status Invalid
           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

B. Bidulock                    Version 0.7                       Page 83

Internet Draft                  M2PA-TEST                  June 18, 2006

   (4)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Set Emergency" command
           - Level 3 "Clear Emergency" command
           - Level 3 "Set Local Processor Outage" command
           - Level 3 "Start" command

   (5)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (6)   Check that the IUT places the link in service.

3.2.7.  Unexpected signal units/orders in "In Service" state

    This case validates the response of the IUT to the receipt of
  unexpected Level 3 request and receipt of unexpected M2PA messages
  while in the "In Service" state.  All of the unexpected sequences in
  this test case MUST be ignored by the IUT.  The expected sequence of
  events is illustrated in Figure 3.2.7-1.

                        Reference:  Q.781/Test 2.7
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :set emergency         |
  |                                            :clear emergency       |
  |                                            :clear lpo             |
  |                                            :start                 |
  |                                                                   |
  |___________________________________________________________________|

          Figure 3.2.7-1.  Unexpected events while "in service"

  Test Description:

   (1)   The test begins with both IUT and PT in the "In Service" state.

   (2)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Processor Recovered"
           - Status "Busy Ended"
           - Status Invalid
           - M2PA Message with Invalid Message Class

B. Bidulock                    Version 0.7                       Page 84

Internet Draft                  M2PA-TEST                  June 18, 2006

           - M2PA Message with Invalid Message Type

   (3)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Set Emergency" command
           - Level 3 "Clear Emergency" command
           - Level 3 "Clear Local Processor Outage" command
           - Level 3 "Start" command

   (4)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (5)   Check that the IUT retains the link in the in service state and
         that no local or remote processor outage indications are given
         to Level 3 at the IUT.

3.2.8.  Unexpected signal units/orders in "Processor Outage" state

    This case validates the response of the IUT to the receipt of
  unexpected Level 3 request and receipt of unexpected M2PA messages
  while in the "Processor Outage" state.  All of the unexpected
  sequences in this test case MUST be ignored by the IUT.  The expected
  sequence of events is illustrated in Figure 3.2.8-1.

                        Reference:  Q.781/Test 2.8
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                  BUSY  ----------------->                         |
  |      {INVALID-STATUS}  ----------------->                         |
  |       {INVALID-CLASS}  ----------------->                         |
  |        {INVALID-TYPE}  ----------------->                         |
  |                                            :set emergency         |
  |                                            :clear emergency       |
  |                                            :start                 |
  |                 READY  ----------------->                         |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |            BUSY-ENDED  ----------------->                         |
  |                                                                   |
  |___________________________________________________________________|

       Figure 3.2.8-1.  Unexpected events while "processor outage"

B. Bidulock                    Version 0.7                       Page 85

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   The test begins with both IUT and PT in the "In Service" state.

   (2)   The IUT is brought to the "Processor Outage" state using normal
         procedures.

   (3)   A sequence of unexpected M2PA messages are sent to the IUT.
         These unexpected messages are:

           - Status "Processor Recovered"
           - Status "Busy Ended"
           - Status "Busy"
           - Status "Ready"
           - Status Invalid
           - M2PA Message with Invalid Message Class
           - M2PA Message with Invalid Message Type

   (4)   A sequence of unexpected Level 3 commands are issued at the
         IUT.  These unexpected Level 3 commands are:

           - Level 3 "Set Emergency" command
           - Level 3 "Clear Emergency" command
           - Level 3 "Start" command

   (5)   Check that the IUT ignores the unexpected M2PA messages/Level 3
         commands.

   (6)   Check that the IUT keeps the link in service and that no local
         or remote processor outage indications are given to Level 3 at
         the IUT.

3.3.  Transmission Failure

    This set of test cases validate specific transmission path failures
  and anomalies.  Specifically transmission path failures, corrupt
  acknowledgments and invalid sequencing.  Because SCTP does not have a
  transmission path that is separate from a receive path, the Q.781
  tests that validate response to breaking the transmission path are
  simulated by aborting the association.  Because M2PA does not have
  forward indicator bits, the Q.781 tests that validate response to
  abnormal forward indicator bits are simulated by invalid "Data Ack"
  messages.

3.3.1.  Link aligned ready (Abort)

    This case validates the response of the IUT to aborting the SCTP
  association when the IUT is in the "Aligned Ready" state.  The
  expected sequence of events is illustrated in Figure 3.3.1-1.

B. Bidulock                    Version 0.7                       Page 86

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 3.1
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  READY                  |
  |             :tx break                                             |
  |                                            !out of service(SUERM) |
  |                                                                   |
  |___________________________________________________________________|

               Figure 3.3.1-1.  Link aligned ready (Abort)

  Test Description:

   (1)   The test begins with both IUT and PT in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   Issue a Level 3 "Start" command at the IUT and the PT.

   (3)   Check that the IUT follows the sequence of events illustrated
         in Figure 3.3.1-1.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   When the IUT sends a status "Ready" message, abort the SCTP
         association.

   (5)   Check that the IUT indicates "Out of Service" to Level 3 at the
         IUT with reason "Excessive error rate SUERM" and stays in the
         "Out of Service" state.

3.3.2.  Link aligned ready (Corrupt FIBs)

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.3.2-1.

B. Bidulock                    Version 0.7                       Page 87

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 3.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.3.2-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.3.3.  Link aligned not ready (Abort)

    This test case validates the response of the IUT to aborting the
  SCTP association when the IUT is in the "Aligned Not Ready" state.
  The expected sequence of events is illustrated in Figure 3.3.3-1.

                        Reference:  Q.781/Test 3.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                                            :set lpo               |
  |                                            :start                 |
  |                        <-----------------  ALIGNMENT              |
  |                :start                                             |
  |             ALIGNMENT  ----------------->                         |
  |                        <-----------------  PROVING-NORMAL         |
  |        PROVING-NORMAL  ----------------->                         |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |             :tx break                                             |
  |                                            !out of service(SUERM) |
  |                                                                   |
  |___________________________________________________________________|

             Figure 3.3.3-1.  Link aligned not ready (Abort)

  Test Description:

   (1)   The test begins with both  PT and IUT in the "Out of Service"
         state with the IUT set to perform proving.

   (2)   Issue the Level 3 "Set Local Processor Outage" and "Start"
         commands at the IUT and the "Start" command at the PT.

B. Bidulock                    Version 0.7                       Page 88

Internet Draft                  M2PA-TEST                  June 18, 2006

   (3)   Check that the IUT follows the sequence of events illustrated
         in Figure 3.3.3-1.  (Note that the IUT may send additional
         status "Out of Service," "Alignment" or "Proving Normal"
         messages.)

   (4)   When the IUT sends a status "Processor Outage" message, abort
         the SCTP association.

   (5)   Check that the IUT indicates "Out of Service" to Level 3 at the
         IUT with reason "Excessive Error Rate/SUERM" and stays in the
         "Out of Service" state.

3.3.4.  Link aligned not ready (Corrupt FIBs)

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.3.4-1.

                        Reference:  Q.781/Test 3.4
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.3.4-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.3.5.  Link in service (Abort)

    The expected sequence of events is illustrated in Figure 3.3.5-1.

                        Reference:  Q.781/Test 3.5
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |             :tx break                                             |
  |                                            !out of service(SUERM) |
  |                                                                   |
  |___________________________________________________________________|

                 Figure 3.3.5-1.  Link in service (Abort)

  Test Description:

B. Bidulock                    Version 0.7                       Page 89

Internet Draft                  M2PA-TEST                  June 18, 2006

   (1)   The test begins with the link in the "In Service" state.

   (2)   Abort the SCTP association.

   (3)   Check that SP A indicates "Out of Service" to Level 3 at SP A
         with reason "Excessive Error Rate/SUERM" and stays in the "Out
         of Service" state.

3.3.6.  Link in service (Corrupt FIBs)

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.3.6-1.

                        Reference:  Q.781/Test 3.6
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.3.6-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.3.7.  Link in processor outage (Abort)

    This test case validates the response of the IUT to aborting the
  SCTP association when the IUT is in the "Processor Outage" state.  The
  expected sequence of events is illustrated in Figure 3.3.7-1.

                        Reference:  Q.781/Test 3.7
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |             :tx break                                             |
  |                                            !out of service(SUERM) |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.3.7-1.  Link in processor outage (Abort)

  Test Description:

B. Bidulock                    Version 0.7                       Page 90

Internet Draft                  M2PA-TEST                  June 18, 2006

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issues the Level 3 "Set Local Processor Outage" command at SP
         A.

   (3)   Check that SP A sends a status "Processor Outage" message.

   (4)   Abort the SCTP association.

   (5)   Check that SP A indicates "Out of Service" to Level 3 at SP A
         with reason "Excessive Error Rate/SUERM" and stays in the "Out
         of Service" state.

3.3.8.  Link in processor outage (Corrupt FIBs)

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.3.8-1.

                        Reference:  Q.781/Test 3.8
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.3.8-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.4.  Processor Outage Control

3.4.1.  Set and clear LPO while link in service

    This test case validates the response of the IUT to a local
  processor outage condition and recovery with buffer clearing.

3.4.1.1.  Forward Direction

    This test is in the forward direction, where the IUT suffers local
  processor outage.  The expected sequence of events is illustrated in
  Figure 3.4.1-1.

B. Bidulock                    Version 0.7                       Page 91

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000000->                         |
  |                        <-000000, 000001--  PROCESSOR-OUTAGE       |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                                            !msu                   |
  |                                            :clear buffers         |
  |                                            :clear lpo             |
  |                                            :msu                   |
  |                        <-000000, 000001--  PROCESSOR-RECOVERED    |
  |  [ 35 bytes]     DATA  --000003, 000000->                         |
  |                 READY  --000000, 000000->                         |
  |  [ 35 bytes]     DATA  --000001, 000000->                         |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000001->                         |
  |                        <-000001, 000001--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.4.1-1.  Set and clear LPO while link in service

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send one data mesage from SP B to SP A.

   (3)   Send two MSUs from SP A, issue a Level 3 "Set Local Processor
         Outage" command at SP A, and send another MSU from SP A.

   (4)   Send another data message from SP B to SP A and acknowledge the
         first data message sent from SP A.

   (5)   Check that SP A sends two Data messages and acknowledges one
         data message before sending a status "Processor Outage"
         message.

   (6)   Check that the second data message sent after "Set Local
         Processor Outage" was asserted is not acknowledged or

B. Bidulock                    Version 0.7                       Page 92

Internet Draft                  M2PA-TEST                  June 18, 2006

         indicated.

   (7)   Upon receiving a status "Processor Outage" message from SP A,
         send another data message to SP A from SP B.

   (8)   Check that this last message is neither acknolwedged by nor
         indicated at SP A.

   (9)   Issue Level 3 "Clear Buffers" and Level 3 "Clear Local
         Processor Outage" commands at SP A and send another MSU from SP
         A.

   (10)  Check that SP A sends a statu "Processor Outage Ended" message.

   (11)  Send another data message to SP A and send a status "Ready"
         message from SP B to SP A with the appropriate sequence
         numbers.

   (12)  Check that the message sent before status "Ready" is neither
         acknolwedged by nor indicated at SP A.

   (13)  Send another data message to SP A.

   (14)  Check that SP A and SP B exchange this last set of data
         messages and acknowledgements.

3.4.1.2.  Reverse Direction

    This test is in the reverse direction, where the IUT suffers remote
  processor outage.  The expected sequence of events is illustrated in
  Figure 3.4.1-2.

B. Bidulock                    Version 0.7                       Page 93

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 4.1
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                        <-000000, 000000--  DATA-ACK               |
  |                        <-000000, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000000, 000000->                         |
  |      PROCESSOR-OUTAGE  --000001, 000000->                         |
  |  [ 35 bytes]     DATA  --000001, 000000->                         |
  |                                            :msu                   |
  |                        <-000001, 000001--  DATA-ACK               |
  |                                            !msu                   |
  |                                            !rpo                   |
  |                                            !msu                   |
  |   PROCESSOR-RECOVERED  --000001, 000000->                         |
  |  [ 35 bytes]     DATA  --000002, 000000->                         |
  |                        <-000001, 000000--  READY                  |
  |                        <-000001, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --000001, 000001->                         |
  |                        <-000002, 000001--  DATA-ACK               |
  |                                            !rpr                   |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.4.1-2.  Set and clear LPO while link in service

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send two data messages from SP A to SP B and one data message
         from SP B to SP A.

   (3)   Check that SP A acknowledges the data message sent from SP B to
         SP A.

   (4)   Send a "Data Ack" message from SP B to SP A acknolwedging the
         first data message and send a status "Processor Outage"
         message.

   (5)   Send another data message from SP B to SP A and send another
         MSU from SP A to SP B (during the processor outage period).

   (6)   Check that SP A acknolwedges the data message sent to it during
         the processor outage period.

B. Bidulock                    Version 0.7                       Page 94

Internet Draft                  M2PA-TEST                  June 18, 2006

   (7)   Check that SP A does not issue a data message for the MSU
         requested at SP A after receipt of status "Processor Outage".

   (8)   Check that SP A indicates both MSUs and "Remote Processor
         Outage" to Level 3.

   (9)   Wait for T7 to ensure that SP A does not require
         acknowledgement to the data message sent before processor
         outage was invoked.

   (10)  Send a status "Processor Recovered" message to SP A.

   (11)  Check that SP A responds with a status "Ready" message and
         indicates "Remote Processor Recovered" to Level 3.

   (12)  Check that SP A sends a data message for the MSU that was
         requested during processor outage.

   (13)  Send a "Data Ack" message to SP A to acknowledge the data
         message.

   (14)  Send a data message to SP A.

   (15)  Check that SP A acknolwedges the data message with a "Data Ack"
         message with the appropriate sequence numbers.

3.4.2.  RPO during LPO

    This test case validates the response of the IUT to receiving a
  status "Processor Outage" message and status "Processor Recovered"
  message while in the "Processor Outage" state with LPO set at the IUT.
  The expected sequence of events is illustrated in Figure 3.4.2-1.

                        Reference:  Q.781/Test 4.2
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |              set lpo:                                             |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            !rpo                   |
  |            clear lpo:                                             |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |                        <-----------------  READY                  |
  |                                            !rpr                   |
  |                                                                   |
  |___________________________________________________________________|

                     Figure 3.4.2-1.  RPO during LPO

B. Bidulock                    Version 0.7                       Page 95

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue a Level 3 "Set Local Processor Outage" command at SP A.

   (3)   Check that SP A sends a status "Processor Outage" message.

   (4)   Issue a Level 3 "Set Local Processor Outage" command at SP B
         and send a status "Processor Outage" message to SP A.

   (5)   Check that SP A indicates "Remote Processor Outage" to Level 3
         at SP A.

   (6)   Issue a level 3 "Clear Local Processor Outage" command at SP B
         and send a status "Processor Recovered" message to SP A.

   (7)   Check that SP A sends a status "Ready" message in the data
         stream and indicates "Remote Processor Recovered" to Level 3 at
         SP A.

3.4.3.  Clear LPO when "Both processor outage"

    This test case validates the response of the IUT to the receipt of a
  Level 3 "Clear Local Processor Outage" command when the IUT is in the
  "Processor Outage" state with both processors marked PO.  The expected
  sequence of events is illustrated in Figure 3.4.3-1.

                        Reference:  Q.781/Test 4.3
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |              :set lpo                                             |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            !rpo                   |
  |                                            :clear lpo             |
  |                        <-----------------  PROCESSOR-RECOVERED    |
  |                 READY  ----------------->                         |
  |                                            !rpo                   |
  |            :clear lpo                                             |
  |   PROCESSOR-RECOVERED  ----------------->                         |
  |                        <-----------------  READY                  |
  |                                            !rpr                   |
  |                                                                   |
  |___________________________________________________________________|

         Figure 3.4.3-1.  Clear LPO when "Both processor outage"

B. Bidulock                    Version 0.7                       Page 96

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Issue a Level 3 "Set Local Processor Outage" command at SP A.

   (3)   Check that SP A sends a status "Processor Outage" message.

   (4)   Issue a Level 3 "Set Local Processor Outage" command at SP B
         and send a status "Processor Outage" message to SP A.

   (5)   Check that SP A indicates "Remote Processor Outage" to Level 3
         at SP A.

   (6)   Issue a Level 3 "Clear Local Processor Outage" command at SP A.

   (7)   Check that SP A sends a status "Processor Ended" message and SP
         B sends a status "Ready" message.

   (8)   Issue a Level 3 "Clear Local Processor Outage" command at SP B
         and send a status "Processor Recovered" message to SP A.

   (9)   Check that SP A sends a status "Ready" message, indicates
         "Remote Processor Recovered" to Level 3 at SP A and remains in
         the "In Service" state.

3.5.  SU delimitation, alignment, error detection and correction

    Most of the test cases in this section are not applicable to M2PA
  operation.

3.5.1.  More than 7 ones between MSU opening and closing flags

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.5.1-1.

                        Reference:  Q.781/Test 5.1
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.5.1-1.  Not applicable

  Test Description:

   (1)   Not applicable.

B. Bidulock                    Version 0.7                       Page 97

Internet Draft                  M2PA-TEST                  June 18, 2006

3.5.2.  Greater than maximum signal unit length

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.5.2-1.

                        Reference:  Q.781/Test 5.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.5.2-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.5.3.  Below minimum signal unit length

    This test case validates the IUT response to a Data message with a
  payload below the minimum MSU length.  The expected sequence of events
  is illustrated in Figure 3.5.3-1.

                        Reference:  Q.781/Test 5.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |  [  1 bytes]     DATA  --000000, FFFFFF->                         |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.5.3-1.  Below minimum signal unit length

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send a Data message with one byte of payload to the IUT.

   (3)   Check that the IUT does not acknowledge the Data message and
         remains in the "In Service" state.

3.5.4.  Reception of single and multiple flags between FISUs

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.5.4-1.

B. Bidulock                    Version 0.7                       Page 98

Internet Draft                  M2PA-TEST                  June 18, 2006

                      Reference:  Q.781/Test 5.4(a)
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.5.4-1.  Not applicable

  Test Description:

   (1)   Not applicable.

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.5.4-2.

                      Reference:  Q.781/Test 5.4(b)
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.5.4-2.  Not applicable

  Test Description:

   (1)   Not applicable.

3.5.5.  Reception of single and multiple flags between MSUs

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.5.5-1.

                      Reference:  Q.781/Test 5.5(a)
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.5.5-1.  Not applicable

B. Bidulock                    Version 0.7                       Page 99

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   Not applicable.

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.5.5-2.

                      Reference:  Q.781/Test 5.5(b)
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.5.5-2.  Not applicable

  Test Description:

   (1)   Not applicable.

3.6.  SUERM check

    The test cases in this section are not applicable to M2PA.  These
  tests might have corresponding tests at the SCTP layer, however, that
  is the topic of an SCTP test specification rather than an M2PA test
  specification.

3.6.1.  Error rate of 1 in 256 - Link remains in service

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.6.1-1.

                        Reference:  Q.781/Test 6.1
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.6.1-1.  Not applicable

  Test Description:

   (1)   Not applicable.

B. Bidulock                    Version 0.7                      Page 100

Internet Draft                  M2PA-TEST                  June 18, 2006

3.6.2.  Error rate of 1 in 254 - Link out of service

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.6.2-1.

                        Reference:  Q.781/Test 6.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.6.2-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.6.3.  Consecutive corrupt SUs

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.6.3-1.

                        Reference:  Q.781/Test 6.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.6.3-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.6.4.  Time controlled break of the link

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.6.4-1.

B. Bidulock                    Version 0.7                      Page 101

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 6.4
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.6.4-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.7.  AERM check

    The test cases in this section are not applicable to M2PA.  These
  test might have corresponding test at the SCTP layer, however, that is
  the topic of an SCTP test specification rather than an M2PA test
  specification.

3.7.1.  Error rate below the normal threshold

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.7.1-1.

                        Reference:  Q.781/Test 7.1
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.7.1-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.7.2.  Error rate at the normal threshold

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.7.2-1.

B. Bidulock                    Version 0.7                      Page 102

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 7.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.7.2-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.7.3.  Error rate above the normal threshold

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.7.3-1.

                        Reference:  Q.781/Test 7.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.7.3-1.  Not applicable

  Test Description:

   (1)   Not applicable.

3.7.4.  Error rate at the emergency threshold

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.7.4-1.

                        Reference:  Q.781/Test 7.4
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.7.4-1.  Not applicable

B. Bidulock                    Version 0.7                      Page 103

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   Not applicable.

3.8.  Transmission and reception control (Basic)

    A number of test cases in this section are not applicable to M2PA.
  Some may be the topic of a test specification for SCTP but are not
  applicable to M2PA.  Test cases that are applicable in this section
  validate the basic transmission, reception and acknowledgments of Data
  messages with status "Data Ack" messages.

3.8.1.  Data transmission and reception

    This test case validates the IUT response to the sending and receipt
  of Data and "Data Ack" messages.  The expected sequence of events is
  illustrated in Figure 3.8.1-1.

                        Reference:  Q.781/Test 8.1
   ___________________________________________________________________
  |                                                                   |
  | CPT: IOT:        SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                        <-000000, FFFFFF--  DATA-ACK               |
  |                                            !msu                   |
  |                                            :msu                   |
  |                        <-000000, 000000--  DATA [   35 bytes]     |
  |              DATA-ACK  --000000, 000000->                         |
  |                                                                   |
  |___________________________________________________________________|

             Figure 3.8.1-1.  Data transmission and reception

  Test Description:

   (1)   This test begins with the link in the "In Service" state.

   (2)   Send a Data message to SP A.

   (3)   Check that SP A sends a "Data Ack" message acknowledging the
         received Data message and delivers the received MSU to Level 3
         at SP A.

   (4)   Issue a Level 3 MSU to SP A.

   (5)   Check that SP A sends a Data message.

   (6)   Send a "Data Ack" message to SP A acknowledging the data
         message.

B. Bidulock                    Version 0.7                      Page 104

Internet Draft                  M2PA-TEST                  June 18, 2006

   (7)   Check that SP A receives the acknowledgments by waiting longer
         than time T7 and ensuring that SP A stays in the "In Service"
         state.

3.8.2.  Negative acknowledgments of an MSU

    M2PA does not perform negative acknowledgments at the M2PA layer.
  Negative acknowledgments are performed as necessary by the underlying
  SCTP transport.  As such, test cases involving negative
  acknowledgments are not applicable.  The expected sequence of events
  is illustrated in Figure 3.8.2-1.

                        Reference:  Q.781/Test 8.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.8.2-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.8.3.  Check RTB full

    This test case validates the IUT response to an RTB full condition
  at the IUT.  The expected sequence of events is illustrated in Figure
  3.8.3-1.

B. Bidulock                    Version 0.7                      Page 105

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 8.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                                            :msu                   |
  |                                            :msu                   |
  |                                                    .              |
  |                                                    .              |
  |                                                    .              |
  |                                                    Ct=  254       |
  |                                                                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                        <-FFFFFF, 000001--  DATA [   35 bytes]     |
  |                        <-FFFFFF, 000002--  DATA [   35 bytes]     |
  |                                                    .              |
  |                                                    .              |
  |                                                    .              |
  |                                                    Ct=  127       |
  |              DATA-ACK  --FFFFFF, 00007F->                         |
  |                        <-FFFFFF, 000080--  DATA [   35 bytes]     |
  |                        <-FFFFFF, 000081--  DATA [   35 bytes]     |
  |                        <-FFFFFF, 000082--  DATA [   35 bytes]     |
  |                                                    .              |
  |                                                    .              |
  |                                                    .              |
  |                                                    Ct=  127       |
  |              DATA-ACK  --FFFFFF, 0000FE->                         |
  |                                                                   |
  |___________________________________________________________________|

                     Figure 3.8.3-1.  Check RTB full

  Test Description:

   (1)   This test begins with the link in the "In Service" state.

   (2)   Send 2 x N2 MSUs at the IUT.

   (3)   Check that the IUT sends N2 Data messages and then stops
         sending Data messages (RTB Full condition).

   (4)   Acknowledge the N2 Data messages in a single "Data Ack"
         message.

   (5)   Check that the IUT sends another N2 Data messages.

   (6)   Acknowledge the N2 Data messages in a single "Data Ack"
         message.

B. Bidulock                    Version 0.7                      Page 106

Internet Draft                  M2PA-TEST                  June 18, 2006

   (7)   Check that the IUT remains in the "In Service" state longer
         than time T7.

3.8.4.  Single invalid Ack

    This test case validates the response of the IUT to a single invalid
  "Data Ack" message.  The expected sequence of events is illustrated in
  Figure 3.8.4-1.

                        Reference:  Q.781/Test 8.4
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |              DATA-ACK  --FFFFFF, FFFFFF->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |              DATA-ACK  --FFFFFF, 000000->                         |
  |  [ 35 bytes]     DATA  --000000, 000000->                         |
  |                        <-000000, 000000--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

                   Figure 3.8.4-1.  Single invalid Ack

  Test Description:

   (1)   This test begins with the link in the "In Service" state.

   (2)   Send an invalid "Data Ack" message to the IUT.

   (3)   Send an MSU at the IUT.

   (4)   Check that the IUT sends a Data message.

   (5)   Acknowledge the Data message with a "Data Ack" message to the
         IUT

   (6)   Send an Data message to the IUT.

   (7)   Check that the IUT acknowledges the Data message with a "Data
         Ack" message and delivers an MSU to Level 3 at the IUT.

3.8.5.  Duplicated FSN

    This test validates the response of the IUT to a single Data message
  which has a repeated Forward Sequence Number.  The expected sequence
  of events is illustrated in Figure 3.8.5-1.

B. Bidulock                    Version 0.7                      Page 107

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 8.5
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                        <-000000, FFFFFF--  DATA-ACK               |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                                            !msu                   |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000001, FFFFFF--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

                     Figure 3.8.5-1.  Duplicated FSN

  Test Description:

   (1)   This test begins with the link in the "In Service" state.

   (2)   Send an valid Data message to the IUT.

   (3)   Check that the IUT acknowledges the Data message and delivers
         an M3U to Level 3 at the IUT.

   (4)   Send an invalid Data message that contains the same FSN as the
         previous Data message to the IUT.

   (5)   Check that the IUT does not deliver an MSU to Level 3 at the
         IUT.

   (6)   Send a valid Data message to the IUT.

   (7)   Check that the IUT acknowledges the Data message and delivers
         an M3U to Level 3 at the IUT.

   (8)   Check that the IUT maintains the "In Service" state.

3.8.6.  Erroneous retransmission - Single MSU

    Retransmission of DATA messages is performed by SCTP for M2PA and as
  such the related Q.781 tests are not applicable.  The expected
  sequence of events is illustrated in Figure 3.8.6-1.

B. Bidulock                    Version 0.7                      Page 108

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 8.6
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.8.6-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.8.7.  Erroneous retransmission - Multiple FISUs

    Retransmission of DATA messages is performed by SCTP for M2PA and as
  such the related Q.781 tests are not applicable.  The expected
  sequence of events is illustrated in Figure 3.8.7-1.

                        Reference:  Q.781/Test 8.7
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.8.7-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.8.8.  Single FISU with corrupt FIB

    The expected sequence of events is illustrated in Figure 3.8.8-1.

                        Reference:  Q.781/Test 8.8
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.8.8-1.  Not Applicable

B. Bidulock                    Version 0.7                      Page 109

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   Not applicable.

3.8.9.  In Service prior to RPO being set

3.8.9.1.  Forward Direction

    This test is for the forward direction where the PT suffers local
  processor outage.  The expected sequence of events is illustrated in
  Figure 3.8.9-1.

                        Reference:  Q.781/Test 8.9
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                  :msu                                             |
  |              :set lpo                                             |
  |      PROCESSOR-OUTAGE  ----------------->                         |
  |                                            !rpo                   |
  |  [ 35 bytes]     DATA  --000000, FFFFFF->                         |
  |                        <-000000, FFFFFF--  DATA-ACK               |
  |                                            !msu                   |
  |            :clear lpo                                             |
  |   PROCESSOR-RECOVERED  --000000, FFFFFF->                         |
  |                        <-000000, FFFFFF--  READY                  |
  |                                            !rpr                   |
  |                  :msu                                             |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000001, FFFFFF--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.8.9-1.  In service prior to RPO being set

  Test Description:

   (1)   The test beings with the link in the "In Service" state.

   (2)   Issue a Level 3 "Set Local Processor Outage" command at SP B
         and send a status "Processor Outage" message to SP A.

   (3)   Check that SP A indicates "Remote Processor Outage" to Level 3
         at SP A.

   (4)   Send one User Data message to SP A.

   (5)   Check that SP A acknowledges the Data message with a "Data Ack"
         within timer T7 and that the MSU is delivered ot Level 3 at SP

B. Bidulock                    Version 0.7                      Page 110

Internet Draft                  M2PA-TEST                  June 18, 2006

         A.

   (6)   Issue a Level 3 "Clear Local Processor Outage" command at SP B
         and send a status "Processor Recovered" message to SP A.

   (7)   Check that SP A sends a status "Ready" message in the data
         stream and indicates "Remote Processor Recovered" to Level 3 at
         SP A.

   (8)   Send one User Data message to SP A.

   (9)   Check that SP A acknowledges the Data message with a "Data Ack"
         and that the MSU is delivered to Level 3 at SP A.

   (10)  Check that SP A remains in the "In Service" state.

3.8.9.2.  Reverse Direction

    This test is for the reverse direction where the IUT suffers local
  processor outage.  The expected sequence of events is illustrated in
  Figure 3.8.9-2.

                        Reference:  Q.781/Test 8.9
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                                            :set lpo               |
  |                        <-----------------  PROCESSOR-OUTAGE       |
  |              DATA-ACK  --FFFFFF, 000000->                         |
  |                                            :clear lpo             |
  |                        <-FFFFFF, 000000--  PROCESSOR-RECOVERED    |
  |                 READY  --FFFFFF, 000001->                         |
  |                                            :msu                   |
  |                        <-FFFFFF, 000001--  DATA [   35 bytes]     |
  |              DATA-ACK  --FFFFFF, 000001->                         |
  |                                                                   |
  |___________________________________________________________________|

            Figure 3.8.9-2.  In service prior to RPO being set

  Test Description:

   (1)   The test beings with the link in the "In Service" state.

   (2)   Issue one MSU at SP A and then issue a Level 3 "Set Local
         Processor Outage" command at SP A.

B. Bidulock                    Version 0.7                      Page 111

Internet Draft                  M2PA-TEST                  June 18, 2006

   (3)   Check that SP A sends a User Data message followed by a status
         "Processor Outage" message.

   (4)   Send a "Data Ack" message from SP B acknowledging the User Data
         message from SP A and issue a Level 3 "Clear Local Processor
         Outage" command at SP A.

   (5)   Check that SP A sends a status "Processor Recovered" message
         and that the FSN of the status "Processor Recovered" message is
         the FSN of the acknowledged User Data message.

   (6)   Send a status "Ready" message to the IUT on the data stream.

   (7)   Issue one MSU at SP A.

   (8)   Check that SP A sends a User Data message and that the FSN of
         the user data message is incremented by one from the FSN of the
         status "Processor Recovered" message.

   (9)   Send a "Data Ack" message from SP B acknowledging the User Data
         message from SP A.

   (10)  Check that SP A remains in the "In Service" state.

3.8.10.  Abnormal BSN - single Data message

    This test validates the behavior of the IUT to receiving a single
  abnormal Backward Sequence Number in a Data message.  The expected
  sequence of events is illustrated in Figure 3.8.10-1.

                       Reference:  Q.781/Test 8.10
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |  [ 35 bytes]     DATA  --000000, 7FFFFF->                         |
  |                        <-000000, FFFFFF--  DATA-ACK               |
  |                                            !msu                   |
  |  [ 35 bytes]     DATA  --000001, FFFFFF->                         |
  |                        <-000001, FFFFFF--  DATA-ACK               |
  |                                            !msu                   |
  |                                                                   |
  |___________________________________________________________________|

           Figure 3.8.10-1.  Abnormal BSN - single Data message

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send a Data message to the IUT with an abnormal Backward
         Sequence Number.

B. Bidulock                    Version 0.7                      Page 112

Internet Draft                  M2PA-TEST                  June 18, 2006

   (3)   Check that the IUT acknowledges the Data message delivers an
         MSU to Level 3 at the IUT.

   (4)   Send a Data message to the IUT with an normal Backward Sequence
         Number.

   (5)   Check that the IUT acknowledges the Data message delivers an
         MSU to Level 3 at the IUT.

   (6)   Check that the IUT maintains the "In Service" state.

3.8.11.  Abnormal BSN - two consecutive messages

    This test validates the reponse of the IUT to receiving two
  consecutive abnormal Backward Sequence Numbers.  The expected sequence
  of events is illustrated in Figure 3.8.11-1.

                       Reference:  Q.781/Test 8.11
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |              DATA-ACK  --FFFFFF, 7FFFFF->                         |
  |              DATA-ACK  --FFFFFF, 7FFFFF->                         |
  |              DATA-ACK  --FFFFFF, FFFFFF->                         |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service        |
  |                                                                   |
  |___________________________________________________________________|

        Figure 3.8.11-1.  Abnormal BSN - two consecutive messages

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send two "Data Ack" messages with an abnormal Backward Sequence
         Number.

   (3)   Send a "Data Ack" message with an normal Backward Sequence
         Number.

   (4)   Check that the IUT responds with a status "Out of Service"
         message and indicates "Out of Service" to Level 3 at the IUT.

3.8.12.  Excessive delay of acknowledgments

    This test case validates the IUT response to a excessively delayed
  acknowledgment.

B. Bidulock                    Version 0.7                      Page 113

Internet Draft                  M2PA-TEST                  June 18, 2006

3.8.12.1.  Excessive delay of acknowledgment (single Data)

    This test checks excessive delay of acknowledgment where a single
  User Data message is sent.  The expected sequence of events is
  illustrated in Figure 3.8.12-1.

                       Reference:  Q.781/Test 8.12
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                              !                                    |
  |                              !  T7         0.5 <= T7 <= 2.0       |
  |                              !                                    |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(T7)    |
  |                                                                   |
  |___________________________________________________________________|

           Figure 3.8.12-1.  Excessive delay of acknowledgments

  Test Description:

   (1)   This test case begins with the link in the "In Service" state.

   (2)   Send an MSU from the IUT.

   (3)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at the IUT with reason
         "T7 Timeout" and that the link remains in the "Out of Service"
         state.

   (4)   Check that the T7 is between 0.5 seconds and 2.0 seconds in
         duration.

3.8.12.2.  Excessive delay of acknowledgment (multiple Data)

    This test checks excessive delay of acknowledgment where a multiple
  User Data messages are sent.  Unlike MTP2 [Q.703], [T1.111] requires
  that the excessive delay of acknowledgment timer T7 expire when the
  oldest unacknowledged User Data message is over T7 old.  This test
  sends User Data messages while T7 is running to ensure that the IUT
  does not restart T7 on the receipt of User Data.  The expected
  sequence of events is illustrated in Figure 3.8.12-2.

B. Bidulock                    Version 0.7                      Page 114

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 8.12
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                              !                                    |
  |                              !  T7         0.5 <= T7 <= 2.0       |
  |                              !                                    |
  |                        <-FFFFFF, 000001--  DATA [   35 bytes]     |
  |                              !                                    |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(T7)    |
  |                                                                   |
  |___________________________________________________________________|

           Figure 3.8.12-2.  Excessive delay of acknowledgments

  Test Description:

   (1)   This test case begins with the link in the "In Service" state.

   (2)   Send an MSU from the IUT.

   (3)   Wait a short period less than T7 and then send another MSU from
         the IUT.

   (4)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at the IUT with reason
         "T7 Timeout" and that the link remains in the "Out of Service"
         state.

   (5)   Check that the T7 is between 0.5 seconds and 2.0 seconds in
         duration starting from the oldest unacknowledged DATA message.

3.8.13.  Level 3 Stop command

    This test case validates the response of the IUT to the Level 3
  "Stop" command while in the "In Service" state.  The expected sequence
  of events is illustrated in Figure 3.8.13-1.

B. Bidulock                    Version 0.7                      Page 115

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 8.13
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :stop                  |
  |                        <-----------------  OUT-OF-SERVICE         |
  |        OUT-OF-SERVICE  ----------------->                         |
  |                        <-----------------  OUT-OF-SERVICE (Note)  |
  | (Note) OUT-OF-SERVICE  ----------------->                         |
  |                                                                   |
  |___________________________________________________________________|

                  Figure 3.8.13-1.  Level 3 Stop command

  Test Description:

   (1)   This test begins with the link in the "In Service" state.

   (2)   Issue the Level 3 "Stop" command at SP A.

   (3)   Check that SP A sends a status "Out of Service" message and
         remains in the "Out of Service" state.  (Note that SP A or B
         may send additional status "Out of Service" messages.)

3.9.  Transmission and Reception Control (PCR)

    M2PA does not perform Preventative Cyclic Retransmission and,
  therefore, the test cases in this section are not applicable to M2PA.

3.9.1.  MSU transmission and reception

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.1-1.

                        Reference:  Q.781/Test 9.1
   ___________________________________________________________________
  |                                                                   |
  | CPT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.1-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

B. Bidulock                    Version 0.7                      Page 116

Internet Draft                  M2PA-TEST                  June 18, 2006

3.9.2.  Priority control

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.2-1.

                        Reference:  Q.781/Test 9.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.2-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.3.  Forced retransmission with the value N1

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.3-1.

                        Reference:  Q.781/Test 9.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.3-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.4.  Forced retransmission with the value N2

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.4-1.

B. Bidulock                    Version 0.7                      Page 117

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 9.4
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.4-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.5.  Forced retransmission cancel

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.5-1.

                        Reference:  Q.781/Test 9.5
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.5-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.6.  Reception of forced retransmission

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.6-1.

                        Reference:  Q.781/Test 9.6
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.6-1.  Not Applicable

B. Bidulock                    Version 0.7                      Page 118

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   Not applicable.

3.9.7.  MSU transmission while RPO set

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.7-1.

                        Reference:  Q.781/Test 9.7
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.7-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.8.  Abnormal BSN - Single MSU

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.8-1.

                        Reference:  Q.781/Test 9.8
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.8-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.9.  Abnormal BSN - Two MSUs

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.9-1.

B. Bidulock                    Version 0.7                      Page 119

Internet Draft                  M2PA-TEST                  June 18, 2006

                        Reference:  Q.781/Test 9.9
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.9-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.10.  Unexpected FSN

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.10-1.

                       Reference:  Q.781/Test 9.10
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.10-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.11.  Excessive delay of acknowledgments

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.11-1.

                       Reference:  Q.781/Test 9.11
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.11-1.  Not Applicable

B. Bidulock                    Version 0.7                      Page 120

Internet Draft                  M2PA-TEST                  June 18, 2006

  Test Description:

   (1)   Not applicable.

3.9.12.  FISU with FSN expected for MSU

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.12-1.

                       Reference:  Q.781/Test 9.12
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.12-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.9.13.  Level 3 Stop command

    This test case is not applicable to M2PA.  The expected sequence of
  events is illustrated in Figure 3.9.13-1.

                       Reference:  Q.781/Test 9.13
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                                                   |
  |                          NOT APPLICABLE                           |
  |___________________________________________________________________|

                     Figure 3.9.13-1.  Not Applicable

  Test Description:

   (1)   Not applicable.

3.10.  Congestion Control

3.10.1.  Congestion abatement

    This test case validates the response of the IUT to the Level 3
  "Congestion" and "Congestion Ceases" conditions.  The expected
  sequence of events is illustrated in Figure 3.10.1-1.

B. Bidulock                    Version 0.7                      Page 121

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 10.1
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :make cong discard     |
  |                        <-----------------  BUSY                   |
  |                        <-----------------  BUSY (Note)            |
  |                                            :clear congestion      |
  |                        <-----------------  BUSY-ENDED             |
  |                                                                   |
  |___________________________________________________________________|

                  Figure 3.10.1-1.  Congestion abatement

  Test Description:

   (1)   This test begins with the link in the "In Service" state.

   (2)   Generate a local Level 3 "Congestion" condition at the IUT.

   (3)   Check that the IUT sends a status "Busy" message.  (Note that
         the IUT may send additional status "Busy" messages before
         sending a status "Busy Ended" message.)

   (4)   Generate a local Level 3 "Congestion Ceases" condition at the
         IUT.

   (5)   Check that the IUT sends a status "Busy Ended" message.

3.10.2.  Timer T7

    This test case validates timer T7 and procedures at the IUT.

3.10.2.1.  Timer T7 during Receive Congestion

    This test case validates that timer T7 will not expire during
  receive congestion period.  The expected sequence of events is
  illustrated in Figure 3.10.2-1.

B. Bidulock                    Version 0.7                      Page 122

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 10.2
   ___________________________________________________________________
  |                                                                   |
  | IOT:             SP B                      SP A                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                  BUSY  ----------------->                         |
  |                              !                                    |
  |                              !  T7         0.5 <= T7 <= 2.0       |
  |                              !                                    |
  |            BUSY-ENDED  ----------------->                         |
  |              DATA-ACK  --FFFFFF, 000000->                         |
  |                                                                   |
  |___________________________________________________________________|

                        Figure 3.10.2-1.  Timer T7

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send an MSU at SP A.

   (3)   Wait for longer than T7 (but less than T6) and then send a Link
         Status "Busy Ended" message and acknowledge the User Data
         message with a "Data Ack" message to SP A.

   (4)   Check that SP A sends no further status messages and remains in
         the "In Service" state.

3.10.2.2.  Timer T7 expiry after Receive Congestion

    This test case validates that timer T7 will expire after receive
  congestion period.  The expected sequence of events is illustrated in
  Figure 3.10.2-2.

B. Bidulock                    Version 0.7                      Page 123

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 10.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                  BUSY  ----------------->                         |
  |                              !                                    |
  |                              !  T6         3.0 <= T6 <= 6.0       |
  |                              !                                    |
  |            BUSY-ENDED  ----------------->                         |
  |                              !                                    |
  |                              !  T7         0.5 <= T7 <= 2.0       |
  |                              !                                    |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(T7)    |
  |                                                                   |
  |___________________________________________________________________|

                        Figure 3.10.2-2.  Timer T7

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send an MSU at the IUT.

   (3)   Wait for a period less than T6 (but longer than T7) and then
         send a "Link Status Busy Ended" message not acknowledging the
         User Data.

   (4)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 at the IUT with reason
         "T7 Timeout" and that the link remains in the "Out of Service"
         state.

   (5)   Check that the T7 is between 0.5 seconds and 2.0 seconds in
         duration.

3.10.2.3.  Timer T7 after Receive Congestion

    This test case validates timer T7 after the receive congestion
  period.  The expected sequence of events is illustrated in Figure
  3.10.2-3.

B. Bidulock                    Version 0.7                      Page 124

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 10.2
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                  BUSY  ----------------->                         |
  |                              !                                    |
  |                              !  T6         3.0 <= T6 <= 6.0       |
  |                              !                                    |
  |            BUSY-ENDED  ----------------->                         |
  |                              !                                    |
  |                              !  T7         0.5 <= T7 <= 2.0       |
  |                              !                                    |
  |              DATA-ACK  --FFFFFF, 000000->                         |
  |                                                                   |
  |___________________________________________________________________|

                        Figure 3.10.2-3.  Timer T7

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send an MSU at the IUT.

   (3)   Wait for a period less than T6 (but longer than T7) and then
         send a "Link Status Busy Ended" message not acknowledging the
         User Data.

   (4)   Wait for less than T7 and then acknowledge the Data message to
         the IUT with a "Data Ack" message.

   (5)   Check that the IUT sends no further status messages and remains
         in the "In Service" state.

3.10.3.  Timer T6

    This case validates timer T6 and procedures at the IUT.  The
  expected sequence of events is illustrated in Figure 3.10.3-1.

B. Bidulock                    Version 0.7                      Page 125

Internet Draft                  M2PA-TEST                  June 18, 2006

                       Reference:  Q.781/Test 10.3
   ___________________________________________________________________
  |                                                                   |
  | VAT:               PT                      IUT                    |
  |                                                                   |
  |                                            :msu                   |
  |                        <-FFFFFF, 000000--  DATA [   35 bytes]     |
  |                  BUSY  ----------------->                         |
  |                              !             :msu                   |
  |                              !                                    |
  |                              !  T6         3.0 <= T6 <= 6.0       |
  |                              !                                    |
  |                        <-----------------  OUT-OF-SERVICE         |
  |                                            !out of service(T6)    |
  |                                                                   |
  |___________________________________________________________________|

                        Figure 3.10.3-1.  Timer T6

  Test Description:

   (1)   The test begins with the link in the "In Service" state.

   (2)   Send an MSU at the IUT.

   (3)   Send a status "Busy" messages to the IUT.

   (4)   Request another MSU at the IUT.

   (5)   Check that the IUT sends a status "Out of Service" message and
         indicates "Out of Service" to Level 3 with reason "T6 Timeout"
         and remains in the "Out of Service" state.

   (6)   Check that T6 is between 3.0 seconds and 6.0 seconds in
         duration.

   (7)   Check that the IUT does not send the second MSU during the busy
         period.

Security Considerations

    Although this document does not introduce new security
  considerations for M2PA, mention of the role of M2PA security measure
  during tested is in order.

    When the Validation, Compatibility and Interoperability tests in
  this document are being performed, the test environment and
  Implementations Under Test (IUT) MUST use the security measures
  required in the Security section of the M2PA specification [M2PA]
  while the tests are being performed.  Test results without the
  required security measures in place during testing will be of little
  value for validating the behavior of an implementation for later

B. Bidulock                    Version 0.7                      Page 126

Internet Draft                  M2PA-TEST                  June 18, 2006

  operation.

IANA Considerations

    There are no IANA considerations for this draft.

0.  Change History

    This section provides historical information on the changes made to
  this draft.  This section will be removed from the document when the
  document is finalized.

0.7.  Changes from Version 0.6 to Version 0.7

   (1)   updated version numbers and resubmitted

0.6.  Changes fron Version 0.5 to Version 0.6

   (1)   The test specification has been updated to the M2PA RFC [M2PA].

   (2)   Updated first page and last page IETF boiler plates.

0.5.  Changes fron Version 0.4 to Version 0.5

   (1)   The test specification has been updated to M2PA Draft Revision
         11 [M2PA11].

   (2)   Corrected error in test case 3.1.8: SP A should maintain the
         "Processor Outage" state and not the "In Service" state.

   (3)   Added status "Ready" response to receipt of state "Processor
         Recovered".

   (4)   Added sequence numbers to status "Ready" and status "Processor
         Recovered" message because these status values are now
         significant.

   (5)   Removed test case 3.8.14 because out of order FSNs are just
         discarded instead of taking the link out of service.

   (6)   Made test case 3.3.2, 3.3.4, 3.3.6 and 3.3.8 not applicable
         because out of order FSNs are discarded and invalid acks cannot
         be generated.

   (7)   Some corrections to labeling.

   (8)   Added disclaimer to "Conventions" section.

   (9)   Minor spelling and typo corrections.

   (10)  Added description of the labeling of sequence numbers.

B. Bidulock                    Version 0.7                      Page 127

Internet Draft                  M2PA-TEST                  June 18, 2006

   (11)  Reworked test case 3.4.1(a) and 3.4.1(b) to test new sequence
         number synchronization, acknowledgement and sending rules for
         processor outage.

0.4.  Changes from Version 0.3 to Version 0.4

   (1)   The test specification has been updated to M2PA Draft Revision
         9 [M2PA09].

   (2)   Split references into Normative and Informative.

   (3)   Updated acknowledgments to include those making comments on the
         draft.

   (4)   Added section describing labeling of messages and primitives in
         the diagrams.

   (5)   Expanded test environment description.  Tests have been
         identified for compatibility and interoperability testing.

   (6)   Added a test list showing which tests are applicable to
         Validation, Compatibility and Interoperability testing.

   (7)   Added a Security section describing that M2PA security measures
         must be in place during testing.

   (8)   M2PA Draft Revision 9 [M2PA09] uses normal initial sequence
         numbers.  Sequence numbers on all tests have been updated to
         match.

   (9)   M2PA Draft Revision 9 [M2PA09] makes proving configurable.
         Test cases have been added to 3.1.5, 3.1.6, 3.1.8, 3.1.9,
         3.1.10, 3.1.11, 3.1.12, 3.1.13, 3.1.15, 3.1.16 and 3.1.27 to
         test also the situation where the link is not configured for
         proving.

   (10)  M2PA Draft Revision 9 [M2PA09] uses a flexible T7 timer that
         times the age of the oldest unacknowledged data message in the
         retransmission buffer.  This is slightly different that MTP2
         [Q.703], [T1.111] behavior.  A test case was added to 3.8.12
         (Excessive delay of acknowledgment) to test this variation from
         MTP2.

   (11)  M2PA Draft Revision 9 [M2PA09] has some problems with T6 and T7
         timer handling.  It is anticipated that changes will be made to
         the T6 and T7 timer handling.  Additions to test case 3.10.2
         have been made in anticipation of these changes.

   (12)  PROCESSOR-OUTAGE-ENDED renamed to PROCESSOR-RECOVERED.

   (13)  M2PA Draft Revision 9 [M2PA09] has some problems with processor
         outage handing.  It is anticipated that changes will be made to
         the processor outage handling on both sides.  Addition or

B. Bidulock                    Version 0.7                      Page 128

Internet Draft                  M2PA-TEST                  June 18, 2006

         changes to test cases 3.4.1 and 3.8.9 have been made in
         anticipation of these changes.

   (14)  Link Status "Out of Service," "Alignment," "Ready," and
         "Processor Outage" messages can be repeated until the condition
         that caused them to be sent has cleared.  Comments have been
         added to test cases 3.1.1, 3.1.2, 3.1.4, 3.1.16, 3.8.13 and
         3.10.1 to accommodate for this.

   (15)  Link Status "Proving Normal" and "Proving Emergency" messages
         are repeated at the proving interval.  Notes have been added to
         test cases performing proving to indicate that these messages
         may be repeated.

   (16)  Added Link Status "Busy Ended" and "Processor Recovered" as
         well as M2PA messages with invalid message class and message
         type to test cases 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6,
         3.2.7 and 3.2.8 to fully test unexpected message sequences.

   (17)  Added new test case 3.8.14 to test the situation where the IUT
         receives an out of order forward sequence number.

    For the most part, however, there have been few changes to the
  actual test cases.

0.3.  Changes from Version 0.2 to Version 0.3

   (1)   The test specification has been updated to M2PA Draft Revision
         7 [M2PA07], with anticipated changes for M2PA Draft Revision 8
         [M2PA08].

0.2.  Changes from Version 0.1 to Version 0.2

   (1)   The test specification has been updated to M2PA Draft Revision
         6 [M2PA06], with anticipated changes for M2PA Draft Revision 7
         [M2PA07].

   (2)   M2PA Draft Revision 6 [M2PA06] provides for acknowledgment of
         DATA messages using a special DATA message which contains no
         data payload.  This message has been labeled "DATA-ACK" in the
         diagrams.

         This has resulted in changes to test cases 1.6, 2.1, 2.2, 2.3,
         2.4, 3.2, 3.4, 3.6, 3.8, 4.1, 8.1, 8.3, 8.4, 8.5, 8.9, 8.10,
         8.11, 10.2

   (3)   Although M2PA Draft Revision 6 [M2PA06] specifies that the
         DATA-ACK message should have its Forward Sequence Number (FSN)
         incremented as with any other normal DATA message, this causes
         problems in that the DATA-ACK MUST then be acknowledged.  This
         test specification anticipates M2PA Draft Revision 7 by not
         incrementing FSN for DATA-ACK messages.

B. Bidulock                    Version 0.7                      Page 129

Internet Draft                  M2PA-TEST                  June 18, 2006

   (4)   M2PA Draft Revision 6 [M2PA06] provides FSN and BSN sequence
         numbers in STATUS messages as well as DATA messages.  It has
         been proposed that STATUS messages not contain FSN and BSN
         because they should essentially be ignored because of mis-
         ordering possibilities.  Therefore, FSN and BSN of STATUS
         messages are ignored in this version of the test specification
         in anticipation of M2PA Draft Revision 7.

0.1.  Changes from Version 0.0 to Version 0.1

   (1)   The test specification has been updated to M2PA Draft Revision
         4 [M2PA04], with anticipated changes for M2PA Draft Revision 5
         [M2PA05].

   (2)   M2PA Draft Revision 4 [M2PA04] no longer contains a special
         proving message.  Status PROVING-NORMAL or PROVING-EMERGENCY
         messages are padded and sent repeatedly to accomplish proving
         during the proving period.  The occurrence of PROVING messages
         has been removed from the test cases to update this draft to
         match the M2PA draft revision 4 [M2PA04].

   (3)   M2PA Draft Revision 4 [M2PA04] contains both forward and
         backward sequence numbers (FSN, BSN).  The test cases were
         updated to include the sequence numbers (where other than zero)
         and test cases were added for abnormal backward sequence
         numbers.

   (4)   M2PA Draft Revision 4 [M2PA04] has no formal method for
         acknowledging the receipt of a DATA message when there are no
         other messages to send (DATA or STATUS).  The Status of "In
         Service", for which no other use has been specified in the
         current draft [M2PA04], is used as such an explicit
         acknowledgment.  Another possibility would have been to send a
         DATA message with no data in it.  The old "ACK" message is now
         labeled "IN-SERVICE".

   (5)   The status message previously labeled "IN-SERVICE" has been
         relabeled "READY" to better reflect the name of that status
         message in the draft and to not conflict with the new [M2PA04]
         "IN-SERVICE" status message.

B. Bidulock                    Version 0.7                      Page 130

Internet Draft                  M2PA-TEST                  June 18, 2006

R.  References

R.1.  Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels," RFC 2119 - BCP 14, The Internet Society
       (March 1997).

  [M2PA]  George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
       Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 2
       (MTP2)-User Peer-to-Peer Adaptation Layer (M2PA)," RFC 4165,
       Internet Engineering Task Force - Signalling Transport Working
       Group (September 2005).

  [Q.781]  ITU, "Signalling System No. 7 - MTP Level 2 Test
       Specification," ITU-T Recommendation Q.781, ITU-T
       Telecommunication Standardization Sector of ITU, Geneva (March
       1993).  (Previously "CCITT Recommendation")

  [Q.703]  ITU, "Signalling System No. 7 - Signalling Link," ITU-T
       Recommendation Q.703, ITU-T Telecommunication Standardization
       Sector of ITU, Geneva (March 1993).  (Previously "CCITT
       Recommendation")

  [Q.780]  ITU, "Signalling System No. 7 Test Specification -- General
       Description," ITU-T Recommendation Q.780, ITU-T Telecommunication
       Standardization Sector of ITU, Geneva (October 1995).
       (Previously "CCITT Recommendation")

  [Q.782]  ITU, "Specifications of Signalling System No. 7 -- Test
       Specification -- MTP Level 3 Test Specification," ITU-T
       Recommendation Q.782, ITU-T Telecommunication Standardization
       Sector of ITU, Geneva (July 1996).  (Previously "CCITT
       Recommendation")

R.2.  Informative References

  [T1.111]  ANSI, "Signalling System No. 7 - Message Transfer Part,"
       ANSI T1.111, American National Standards Institue (1992).

  [EN 300 008-1]  ETSI, "Integrated Services Digital Network (ISDN);
       Signalling System No. 7; Protocol Specification," ETSI EN 300
       008-1 V1.3.1 [REN/SPAN-01074-1], European Telecommunications
       Standards Institute, Cedex (September 2000).  (ITU-T
       Recommendations Q.701, Q.702, Q.703, Q.704, Q.705, Q.706, Q.707
       and Q.708, modified)

  [JT-Q.703]  TTC, "Message Transfer Part - Signalling Link," TTC
       Standard JT-Q.703, Telecommunication Technology Committee (TTC)
       (April 28, 1992).

  [Q.2140]  ITU, "B-ISDN ATM Adaptation Layer - Service Specific

B. Bidulock                    Version 0.7                      Page 131

Internet Draft                  M2PA-TEST                  June 18, 2006

       Coordination Function for Signalling at the Network Node
       Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T
       Telecommunication Standardization Sector of ITU, Geneva (February
       1996).  (Previously "CCITT Recommendation")

  [T1.637]  "Service Specific Connection-Oriented Protocol (SSCOP),"
       ANSI T1.637/2000, American National Standards Institute (2000).

  [ETS 300 336]  ETSI, "Integrated Services Digital Network (ISDN);
       Signalling System No. 7; Message Transfer Part (MTP); Test
       Specification," ETSI ETS 300 336, European Telecommunications
       Standards Institute, Valbonne (September 1996).  (ITU-T
       Recommendations Q.781 and Q.782 (1993), modified)

  [Q.704]  ITU, "Message Transfer Part - Signalling Network Functions
       and Messages," ITU-T Recommendation Q.704, ITU-T
       Telecommunication Standardization Sector of ITU, Geneva (March
       1993).  (Previously "CCITT Recommendation")

  [M2PA11]  George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
       Morneault, K., "SS7 MTP2-User Peer-to-Peer Adaptation Layer,"
       <draft-ietf-sigtran-m2pa-11.txt>, Internet Engineering Task Force
       - Signalling Transport Working Group (January 29, 2004).  Work In
       Progress.

  [M2PA09]  George, T., Bidulock, B., Dantu, R., Kalla, M.,
       Schwarzbauer, H. J. and Morneault, K., "SS7 MTP2-User Peer-to-
       Peer Adaptation Layer," <draft-ietf-sigtran-m2pa-09.txt>,
       Internet Engineering Task Force - Signalling Transport Working
       Group (June 29, 2003).  Work In Progress.

  [M2PA07]  George, T., Bidulock, B., Dantu, R., Kalla, M.,
       Schwarzbauer, H. J., Sidebottom, G. and Morneault, K., "SS7
       MTP2-User Peer-to-Peer Adaptation Layer," <draft-ietf-sigtran-
       m2pa-07.txt>, Internet Engineering Task Force - Signalling
       Transport Working Group (January 17, 2003).  Work In Progress.

  [M2PA08]  George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and
       Morneault, K., "SS7 MTP2-User Peer-to-Peer Adaptation Layer,"
       <draft-ietf-sigtran-m2pa-08.txt>, Internet Engineering Task Force
       - Signalling Transport Working Group (April 22, 2003).  Work In
       Progress.

  [M2PA06]  George, T., Dantu, R., Kalla, M., Schwarzbauer, H. J.,
       Sidebottom, G., Morneault, K. and Bidulock, B., "SS7 MTP2-User
       Peer-to-Peer Adaptation Layer," <draft-ietf-sigtran-m2pa-06.txt>,
       Internet Engineering Task Force - Signalling Transport Working
       Group (August 28, 2002).  Work In Progress.

  [M2PA04]  George, T., Dantu, R., Kalla, M., Schwarzbauer, H. J.,
       Sidebottom, G. and Morneault, K., "SS7 MTP2-User Peer-to-Peer
       Adaptation Layer," <draft-ietf-sigtran-m2pa-04.txt>, Internet
       Engineering Task Force - Signalling Transport Working Group

B. Bidulock                    Version 0.7                      Page 132

Internet Draft                  M2PA-TEST                  June 18, 2006

       (February 28, 2002).  Work In Progress.

  [M2PA05]  George, T., Dantu, R., Kalla, M., Schwarzbauer, H. J.,
       Sidebottom, G., Morneault, K. and Bidulock, B., "SS7 MTP2-User
       Peer-to-Peer Adaptation Layer," <draft-ietf-sigtran-m2pa-05.txt>,
       Internet Engineering Task Force - Signalling Transport Working
       Group (May 3, 2002).  Work In Progress.

Acknowledgments

    The author would like to thank Jeffrey Craig, Tom George and Tolga
  Aversen for their valuable comments and suggestions.

Author's Addresses

  Brian Bidulock
  OpenSS7 Corporation
  1469 Jeffreys Crescent
  Edmonton, AB  T6L 6T1
  Canada

  Phone: +1-780-490-1141
  Email: bidulock@openss7.org
  URL: http//www.openss7.org/

  This draft expires December 2006.

B. Bidulock                    Version 0.7                      Page 133

Internet Draft                  M2PA-TEST                  June 18, 2006

                            List of Tables

  Table 2.3.1-1. Recommended<1> IUT Timer Values ..................    9
  Table 2.3.2-1. Recommended IUT Buffer Threshold Values ..........    9
  Table 2.3.4-1. Labeling of Messages and Primitives ..............   10
  Table 3-1. Test Case Applicability ..............................   12

                        List of Illustrations

  Figure 2.1.1-1. Validation Test Configuration ...................    6
  Figure 2.1.2-1. Compatibility Test Configuration ................    7
  Figure 3.1.1-1. Initialization (Power-up) .......................   15
  Figure 3.1.1-2. Initialization (Power-up) .......................   16
  Figure 3.1.2-1. Timer T2 ........................................   17
  Figure 3.1.3-1. Timer T3 ........................................   18
  Figure 3.1.4-1. Timer T1 & Timer T4 (Normal) ....................   19
  Figure 3.1.5-1. Normal alignment procedure ......................   20
  Figure 3.1.5-2. Normal alignment procedure ......................   21
  Figure 3.1.5-3. Normal alignment procedure (without proving)
    ...............................................................   22
  Figure 3.1.5-4. Normal alignment procedure (without proving)
    ...............................................................   23
  Figure 3.1.6-1. Normal alignment procedure (Data) with proving
    ...............................................................   24
  Figure 3.1.6-2. Normal alignment procedure (Data) without
    proving .......................................................   25
  Figure 3.1.7-1. "Alignment" during normal proving ...............   26
  Figure 3.1.8-1. Normal alignment with PO set ....................   27
  Figure 3.1.8-2. Normal alignment with PO set ....................   28
  Figure 3.1.8-3. Normal alignment with PO set ....................   29
  Figure 3.1.8-4. Normal alignment with PO set ....................   30
  Figure 3.1.9-1. Normal alignment with PO set (Data) .............   31
  Figure 3.1.9-2. Normal alignment with PO set (Data) .............   32
  Figure 3.1.9-3. Normal alignment with PO set (Data) .............   33
  Figure 3.1.9-4. Normal alignment with PO set (Data) .............   34
  Figure 3.1.10-1. Normal alignment with PO set and cleared .......   35
  Figure 3.1.10-2. Normal alignment with PO set and cleared .......   36
  Figure 3.1.11-1. Set RPO when "Aligned Not Ready" ...............   37
  Figure 3.1.11-2. Set RPO when "Aligned Not Ready" ...............   38
  Figure 3.1.12-1. "Out of Service" when "Aligned not ready" ......   39
  Figure 3.1.12-2. "Out of Service" when "Aligned not ready" ......   40
  Figure 3.1.12-3. "Out of Service" when "Aligned not ready" ......   41
  Figure 3.1.12-4. "Out of Service" when "Aligned not ready" ......   42
  Figure 3.1.13-1. "Alignment" when "Aligned not ready" ...........   43
  Figure 3.1.13-2. "Alignment" when "Aligned not ready" ...........   44
  Figure 3.1.14-1. Set and clear LPO when "Initial Alignment" .....   45
  Figure 3.1.15-1. Set and clear LPO when "Aligned ready" .........   46
  Figure 3.1.15-2. Set and clear LPO when "Aligned ready" .........   47
  Figure 3.1.16-1. Timer T1 in "Aligned not ready" state ..........   49
  Figure 3.1.16-2. Timer T1 in "Aligned not ready" state ..........   50
  Figure 3.1.17-1. No "Alignment" during normal proving period
    ...............................................................   51

B. Bidulock                    Version 0.7                      Page 134

Internet Draft                  M2PA-TEST                  June 18, 2006

  Figure 3.1.18-1. Toggle emergency before "start alignment" ......   52
  Figure 3.1.19-1. Set emergency in "not aligned" state ...........   53
  Figure 3.1.20-1. Set emergency when "aligned" ...................   54
  Figure 3.1.21-1. Both ends set emergency ........................   55
  Figure 3.1.22-1. Individual end sets emergency ..................   56
  Figure 3.1.23-1. Set emergency during normal proving ............   57
  Figure 3.1.24-1. No "Alignment" during emergency alignment ......   58
  Figure 3.1.25-1. Deactivate during initial alignment ............   59
  Figure 3.1.26-1. Deactivate during aligned state ................   60
  Figure 3.1.27-1. Deactivate during aligned not ready ............   61
  Figure 3.1.27-2. Deactivate during aligned not ready ............   62
  Figure 3.1.28-1. "Alignment" during link in service .............   63
  Figure 3.1.29-1. "Out of service" during link in service ........   63
  Figure 3.1.29-2. "Out of service" during link in service ........   64
  Figure 3.1.30-1. Deactivation during LPO ........................   65
  Figure 3.1.30-2. Deactivation during LPO ........................   65
  Figure 3.1.31-1. Deactivation during RPO ........................   66
  Figure 3.1.31-2. Deactivation during RPO ........................   67
  Figure 3.1.32-1. Deactivation during the proving period .........   68
  Figure 3.1.32-2. Deactivation during the proving period .........   69
  Figure 3.1.33-1. "Alignment" instead of "In Service" ............   70
  Figure 3.1.34-1. "Out of Service" instead of "In Service" .......   71
  Figure 3.1.35-1. "Processor Outage" instead of "In Service" .....   72
  Figure 3.2.1-1. Unexpected events in the "Out of Service"
    State .........................................................   73
  Figure 3.2.2-1. Unexpected events while "not aligned" ...........   75
  Figure 3.2.3-1. Unexpected events while "aligned" ...............   77
  Figure 3.2.4-1. Unexpected events while "proving" ...............   79
  Figure 3.2.5-1. Unexpected events while "aligned ready" .........   81
  Figure 3.2.6-1. Unexpected events while "aligned not ready" .....   83
  Figure 3.2.7-1. Unexpected events while "in service" ............   84
  Figure 3.2.8-1. Unexpected events while "processor outage" ......   85
  Figure 3.3.1-1. Link aligned ready (Abort) ......................   87
  Figure 3.3.2-1. Not applicable ..................................   88
  Figure 3.3.3-1. Link aligned not ready (Abort) ..................   88
  Figure 3.3.4-1. Not applicable ..................................   89
  Figure 3.3.5-1. Link in service (Abort) .........................   89
  Figure 3.3.6-1. Not applicable ..................................   90
  Figure 3.3.7-1. Link in processor outage (Abort) ................   90
  Figure 3.3.8-1. Not applicable ..................................   91
  Figure 3.4.1-1. Set and clear LPO while link in service .........   92
  Figure 3.4.1-2. Set and clear LPO while link in service .........   94
  Figure 3.4.2-1. RPO during LPO ..................................   95
  Figure 3.4.3-1. Clear LPO when "Both processor outage" ..........   96
  Figure 3.5.1-1. Not applicable ..................................   97
  Figure 3.5.2-1. Not applicable ..................................   98
  Figure 3.5.3-1. Below minimum signal unit length ................   98
  Figure 3.5.4-1. Not applicable ..................................   99
  Figure 3.5.4-2. Not applicable ..................................   99
  Figure 3.5.5-1. Not applicable ..................................   99
  Figure 3.5.5-2. Not applicable ..................................  100
  Figure 3.6.1-1. Not applicable ..................................  100
  Figure 3.6.2-1. Not applicable ..................................  101

B. Bidulock                    Version 0.7                      Page 135

Internet Draft                  M2PA-TEST                  June 18, 2006

  Figure 3.6.3-1. Not applicable ..................................  101
  Figure 3.6.4-1. Not applicable ..................................  102
  Figure 3.7.1-1. Not applicable ..................................  102
  Figure 3.7.2-1. Not applicable ..................................  103
  Figure 3.7.3-1. Not applicable ..................................  103
  Figure 3.7.4-1. Not applicable ..................................  103
  Figure 3.8.1-1. Data transmission and reception .................  104
  Figure 3.8.2-1. Not Applicable ..................................  105
  Figure 3.8.3-1. Check RTB full ..................................  106
  Figure 3.8.4-1. Single invalid Ack ..............................  107
  Figure 3.8.5-1. Duplicated FSN ..................................  108
  Figure 3.8.6-1. Not Applicable ..................................  109
  Figure 3.8.7-1. Not Applicable ..................................  109
  Figure 3.8.8-1. Not Applicable ..................................  109
  Figure 3.8.9-1. In service prior to RPO being set ...............  110
  Figure 3.8.9-2. In service prior to RPO being set ...............  111
  Figure 3.8.10-1. Abnormal BSN - single Data message .............  112
  Figure 3.8.11-1. Abnormal BSN - two consecutive messages ........  113
  Figure 3.8.12-1. Excessive delay of acknowledgments .............  114
  Figure 3.8.12-2. Excessive delay of acknowledgments .............  115
  Figure 3.8.13-1. Level 3 Stop command ...........................  116
  Figure 3.9.1-1. Not Applicable ..................................  116
  Figure 3.9.2-1. Not Applicable ..................................  117
  Figure 3.9.3-1. Not Applicable ..................................  117
  Figure 3.9.4-1. Not Applicable ..................................  118
  Figure 3.9.5-1. Not Applicable ..................................  118
  Figure 3.9.6-1. Not Applicable ..................................  118
  Figure 3.9.7-1. Not Applicable ..................................  119
  Figure 3.9.8-1. Not Applicable ..................................  119
  Figure 3.9.9-1. Not Applicable ..................................  120
  Figure 3.9.10-1. Not Applicable .................................  120
  Figure 3.9.11-1. Not Applicable .................................  120
  Figure 3.9.12-1. Not Applicable .................................  121
  Figure 3.9.13-1. Not Applicable .................................  121
  Figure 3.10.1-1. Congestion abatement ...........................  122
  Figure 3.10.2-1. Timer T7 .......................................  123
  Figure 3.10.2-2. Timer T7 .......................................  124
  Figure 3.10.2-3. Timer T7 .......................................  125
  Figure 3.10.3-1. Timer T6 .......................................  126

                          Table of Contents

  Status of this Memo .............................................    1
  Copyright .......................................................    1
  Abstract ........................................................    1
  Contents ........................................................    2
  1 Introduction ..................................................    2
  1.1 Scope .......................................................    2
  1.2 Terminology .................................................    2
  1.3 Abbreviations ...............................................    3
  1.4 Conventions .................................................    4
  Notes for Section 1 .............................................    4
  2 Test Environment ..............................................    4

B. Bidulock                    Version 0.7                      Page 136

Internet Draft                  M2PA-TEST                  June 18, 2006

  2.1 Test Configurations .........................................    5
  2.1.1 Validation Test Configuration .............................    5
  2.1.2 Compatibility Test Configuration ..........................    7
  2.1.3 Interoperability Test Configuration .......................    8
  2.2 Testing Methodology .........................................    8
  2.3 Recommended IUT Settings ....................................    8
  2.3.1 Timer Values ..............................................    8
  2.3.2 Buffer Threshold Values ...................................    9
  2.3.3 MSU Length ................................................    9
  2.3.4 Labeling of Messages and Primitives .......................    9
  2.3.5 Labeling of Sequence Numbers ..............................   11
  Notes for Section 2 .............................................   12
  3 Tests .........................................................   12
  3.1 Link State Control - Expected signal units/orders ...........   15
  3.1.1 Initialization (Power-up) .................................   15
  3.1.2 Timer T2 ..................................................   16
  3.1.3 Timer T3 ..................................................   17
  3.1.4 Timer T1 & Timer T4 (Normal) ..............................   18
  3.1.5 Normal alignment procedure ................................   20
  3.1.6 Normal alignment procedure - correct procedure (Data) .....   23
  3.1.7 Status "Alignment" received during normal proving period
    ...............................................................   25
  3.1.8 Normal alignment with PO set ..............................   26
  3.1.9 Normal alignment with PO set (Data) .......................   30
  3.1.10 Normal alignment with PO set and cleared .................   34
  3.1.11 Set RPO when "Aligned not ready" .........................   36
  3.1.12 Status "Out of Service" received when "Aligned not
    ready" ........................................................   38
  3.1.13 Status "Alignment" received when "Aligned not ready" .....   42
  3.1.14 Set and clear LPO when "Initial alignment" ...............   44
  3.1.15 Set and clear LPO when "Aligned ready" ...................   45
  3.1.16 Timer T1 in "Aligned not ready" state ....................   48
  3.1.17 No status "Alignment" sent during normal proving period
    ...............................................................   50
  3.1.18 Set and cease emergency prior to "start alignment" .......   51
  3.1.19 Set emergency while in "not aligned" state ...............   52
  3.1.20 Set emergency when "aligned" .............................   54
  3.1.21 Both ends set emergency.  ................................   55
  3.1.22 Individual end sets emergency ............................   56
  3.1.23 Set emergency during normal proving ......................   57
  3.1.24 No status "Alignment" sent during emergency alignment
    ...............................................................   58
  3.1.25 Deactivation during initial alignment ....................   59
  3.1.26 Deactivation during aligned state ........................   60
  3.1.27 Deactivation during aligned not ready ....................   60
  3.1.28 Status "alignment" received during link in service .......   62
  3.1.29 Status "out of service" received during link in service
    ...............................................................   63
  3.1.30 Deactivation during LPO ..................................   64
  3.1.31 Deactivation during RPO ..................................   66
  3.1.32 Deactivation during the proving period ...................   67
  3.1.33 Status "Alignment" received instead of status "Ready"
    ...............................................................   69

B. Bidulock                    Version 0.7                      Page 137

Internet Draft                  M2PA-TEST                  June 18, 2006

  3.1.34 Status "Out of Service" received instead of status
    "Ready" .......................................................   70
  3.1.35 Status "Processor Outage" received instead of status
    "Ready" .......................................................   71
  3.2 Link State Control - Unexpected signal units/orders .........   72
  3.2.1 Unexpected signal units/orders in "Out of service" state
    ...............................................................   73
  3.2.2 Unexpected signal units/orders in "Not Aligned" state .....   74
  3.2.3 Unexpected signal units/orders in "Aligned" state .........   76
  3.2.4 Unexpected signal units/orders in "Proving" state .........   78
  3.2.5 Unexpected signal units/orders in "Aligned Ready" state
    ...............................................................   80
  3.2.6 Unexpected signal units/orders in "Aligned Not Ready"
    state .........................................................   82
  3.2.7 Unexpected signal units/orders in "In Service" state ......   84
  3.2.8 Unexpected signal units/orders in "Processor Outage"
    state .........................................................   85
  3.3 Transmission Failure ........................................   86
  3.3.1 Link aligned ready (Abort) ................................   86
  3.3.2 Link aligned ready (Corrupt FIBs) .........................   87
  3.3.3 Link aligned not ready (Abort) ............................   88
  3.3.4 Link aligned not ready (Corrupt FIBs) .....................   89
  3.3.5 Link in service (Abort) ...................................   89
  3.3.6 Link in service (Corrupt FIBs) ............................   90
  3.3.7 Link in processor outage (Abort) ..........................   90
  3.3.8 Link in processor outage (Corrupt FIBs) ...................   91
  3.4 Processor Outage Control ....................................   91
  3.4.1 Set and clear LPO while link in service ...................   91
  3.4.2 RPO during LPO ............................................   95
  3.4.3 Clear LPO when "Both processor outage" ....................   96
  3.5 SU delimitation, alignment, error detection and correction
    ...............................................................   97
  3.5.1 More than 7 ones between MSU opening and closing flags
    ...............................................................   97
  3.5.2 Greater than maximum signal unit length ...................   98
  3.5.3 Below minimum signal unit length ..........................   98
  3.5.4 Reception of single and multiple flags between FISUs ......   98
  3.5.5 Reception of single and multiple flags between MSUs .......   99
  3.6 SUERM check .................................................  100
  3.6.1 Error rate of 1 in 256 - Link remains in service ..........  100
  3.6.2 Error rate of 1 in 254 - Link out of service ..............  101
  3.6.3 Consecutive corrupt SUs ...................................  101
  3.6.4 Time controlled break of the link .........................  101
  3.7 AERM check ..................................................  102
  3.7.1 Error rate below the normal threshold .....................  102
  3.7.2 Error rate at the normal threshold ........................  102
  3.7.3 Error rate above the normal threshold .....................  103
  3.7.4 Error rate at the emergency threshold .....................  103
  3.8 Transmission and reception control (Basic) ..................  104
  3.8.1 Data transmission and reception ...........................  104
  3.8.2 Negative acknowledgments of an MSU ........................  105
  3.8.3 Check RTB full ............................................  105
  3.8.4 Single invalid Ack ........................................  107

B. Bidulock                    Version 0.7                      Page 138

Internet Draft                  M2PA-TEST                  June 18, 2006

  3.8.5 Duplicated FSN ............................................  107
  3.8.6 Erroneous retransmission - Single MSU .....................  108
  3.8.7 Erroneous retransmission - Multiple FISUs .................  109
  3.8.8 Single FISU with corrupt FIB ..............................  109
  3.8.9 In Service prior to RPO being set .........................  110
  3.8.10 Abnormal BSN - single Data message .......................  112
  3.8.11 Abnormal BSN - two consecutive messages ..................  113
  3.8.12 Excessive delay of acknowledgments .......................  113
  3.8.13 Level 3 Stop command .....................................  115
  3.9 Transmission and Reception Control (PCR) ....................  116
  3.9.1 MSU transmission and reception ............................  116
  3.9.2 Priority control ..........................................  117
  3.9.3 Forced retransmission with the value N1 ...................  117
  3.9.4 Forced retransmission with the value N2 ...................  117
  3.9.5 Forced retransmission cancel ..............................  118
  3.9.6 Reception of forced retransmission ........................  118
  3.9.7 MSU transmission while RPO set ............................  119
  3.9.8 Abnormal BSN - Single MSU .................................  119
  3.9.9 Abnormal BSN - Two MSUs ...................................  119
  3.9.10 Unexpected FSN ...........................................  120
  3.9.11 Excessive delay of acknowledgments .......................  120
  3.9.12 FISU with FSN expected for MSU ...........................  121
  3.9.13 Level 3 Stop command .....................................  121
  3.10 Congestion Control .........................................  121
  3.10.1 Congestion abatement .....................................  121
  3.10.2 Timer T7 .................................................  122
  3.10.3 Timer T6 .................................................  125
  Security Considerations .........................................  126
  IANA Considerations .............................................  127
  0 Change History ................................................  127
  0.7 Changes from Version 0.6 to Version 0.7 .....................  127
  0.6 Changes fron Version 0.5 to Version 0.6 .....................  127
  0.5 Changes fron Version 0.4 to Version 0.5 .....................  127
  0.4 Changes from Version 0.3 to Version 0.4 .....................  128
  0.3 Changes from Version 0.2 to Version 0.3 .....................  129
  0.2 Changes from Version 0.1 to Version 0.2 .....................  129
  0.1 Changes from Version 0.0 to Version 0.1 .....................  130
  R References ....................................................  131
  R.1 Normative References ........................................  131
  R.2 Informative References ......................................  131
  Acknowledgments .................................................  133
  Author's Addresses ..............................................  133
  List of Tables ..................................................  134
  List of Illustrations ...........................................  134
  Table of Contents ...............................................  136

B. Bidulock                    Version 0.7                      Page 139

Internet Draft                  M2PA-TEST                  June 18, 2006

Intellectual Property

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at ietf-
  ipr@ietf.org.

Disclaimer of Validity

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Full Copyright Statement

  Copyright (C) The Internet Society (2006).  This document is subject
  to the rights, licenses and restrictions contained in BCP 78, and
  except as set forth therein, the authors retain all their rights.

Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.

B. Bidulock                    Version 0.7                      Page 140


OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-bidulock-sigtran-m2pa-test-07
Last modified: Wed, 07 Jan 2009 09:41:10 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.