Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

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-hss-test-spec-m3ua-00

Description: Request For Comments

You can download source copies of the file as follows:

draft-hss-test-spec-m3ua-00.txt in text format.

Listed below is the contents of file draft-hss-test-spec-m3ua-00.txt.



INTERNET-DRAFT                                        Sunil Mahajan
								      Prashant Singh
                                                      Ashok.K.Singh
                                              Hughes Software Systems

                                                            Feb, 2001
expires: Aug, 2001                                   

              Test Specification for MTP3 User Adaptation
                 <draft-hss-test-spec-m3ua-00.txt>

Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

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.

Sunil-Prashant-Ashok, HSS                                 [Page  1]

Internet Draft          Test Specs for M3UA                 Feb 2001

Abstract

This document presents the test specification for M3UA (MTP3 User 
Adaptation) protocol (ver 05), which can be used to test M3UA 
implementations for conformance to the protocol definition. The list 
of test is exhaustive and covers almost all the categories of test.
This draft can also be used in conjunction with M3UA specification by
implementers of protocol as implementers guide, as the pictorial 
representation of various scenarios help easy understanding of the 
protocol.

Next revision of the draft will cover the additions done to the
protocol revision and any subsequent RFC published by IETF.

Table of Contents

1	Introduction------------------------------------------------4
1.1	Terms Used--------------------------------------------------4
2	General Principles of m3ua Tests----------------------------6
2.1	Presentation of Test Descriptions---------------------------6
2.1.1	Pre-Test Condition------------------------------------------7
3	Test Configurations-----------------------------------------7
3.1	Configuration for Testing the m3ua at SG--------------------7
3.2	Configuration for Testing The m3ua at AS--------------------11
4	Test Cases--------------------------------------------------14
4.1   Test cases for testing m3ua at SG---------------------------14 
4.1.1 Send and Receive transfer primitive in AS Active state------14
4.1.2	Stream selection--------------------------------------------15
4.1.3	AS Management-----------------------------------------------16
4.1.4	MTP3 Management---------------------------------------------34
4.1.5	Invalid Message Handling------------------------------------40
4.1.6	Duplicate Message Handling----------------------------------49
4.1.7	ASPM messages when SG has locked out the ASP----------------58
4.1.8	Message Routing---------------------------------------------59

Sunil-Prashant-Ashok,  HSS                                  [Page  2]

Internet Draft          Test Specs for M3UA                 Feb 2001

4.1.9	 Mode of Traffic Handling by ASP in ASPAC message------------64
4.1.10 Mode of Traffic Handling by ASP in ASPIA message------------76
4.1.11 ERROR Message Handling--------------------------------------77
4.1.12 SCTP Connection Management----------------------------------78
4.1.13 SPMC management---------------------------------------------80
4.2	 Test Cases for Testing m3ua at AS---------------------------82
4.2.1	 Send and receive of transfer primitive in AS Active state---82
4.2.2	 Stream Selection--------------------------------------------83
4.2.3	 SCTP Connection Management----------------------------------84
4.2.4	 AS Management-----------------------------------------------86
4.2.5	 Invalid Message Handling------------------------------------90
4.2.6	 SSNM Message Handling---------------------------------------96
4.2.7	 Duplicate Message Handling---------------------------------105
4.2.8	 ERROR Handling---------------------------------------------107
4.2.9	 ASP in more than one AS------------------------------------108
4.2.10 SG Redundancy----------------------------------------------109
5      Acknowledgement--------------------------------------------111
6      Authors address--------------------------------------------111
7      References-------------------------------------------------111

 

Sunil-Prashant-Ashok, HSS                                 [Page  3]

Internet Draft          Test Specs for M3UA                 Feb 2001

1 Introduction
The M3UA is a protocol for the transport of any SS7 MTP3-User 
signaling (e.g. ISUP and SCCP messages) over IP using the Stream 
Control Transport Protocol (SCTP) or any other suitable transport 
protocol. This protocol would be used between a Signaling Gateway (SG) 
and an Application Service Provider (ASP) (e.g. Media Gateway 
Controller - MGC) or IP-resident Database.

1.1 Terms Used
Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element
handling all call processing for a unique range of PSTN trunks, 
identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual 
database element, handling all HLR transactions for a particular SS7 
DPC/OPC/SCCP_SSN combination.  The AS contains a set of one or more 
unique Application Server Processes, of which one or more is normally 
actively processing traffic.

Application Server Process (ASP) - A process instance of an Application
Server. An Application Server Process serves as an active or standby 
process of an Application Server (e.g., part of a distributed virtual 
switch or database element). Examples of ASPs are processes (or process
instances of) MGCs, IP SCPs or IP HLRs.  An ASP contains an SCTP 
end-point and may be configured to process signaling traffic within 
more than one Application server. 

Association - An association refers to an SCTP association.  The 
association provides the transport for the delivery of MTP3-User 
protocol data units and M3UA adaptation layer peer messages.

IP Server Process (IPSP) - A process instance of an IP-based 
application.  An IPSP is essentially the same as an ASP, except that  
it uses MU3A in a peer-to-peer fashion.  Conceptually, an IPSP does not 
use the services of a signalling gateway.

Signalling Gateway Process (SGP) - A process instance of a Signalling 
Gateway.  It serves as an active, standby or load-sharing process of a 
Signalling Gateway.

Signalling Process - A process instance that uses M3UA to communicate 
with other signalling process.  An ASP, a signalling gateway process 
and an IPSP are all signalling processes.

Sunil-Prashant-Ashok, HSS                                 [Page  4]

Internet Draft          Test Specs for M3UA                 Feb 2001

Routing Key: At the SG, the Routing Key describes a set of SS7 
parameter/parameter-ranges that uniquely defines the range of 
signaling traffic configured to be handled by a particular Application
Server. For example, where all traffic directed to a particular SS7 
DPC, OPC and ISUP CIC_range(s) or SCCP SSN is to be sent to a 
particular Application Server, that SS7 data defines the associated 
Routing Key.  Routing Keys are mutually exclusive in the sense that a 
received SS7 signaling message cannot be directed to more than one 
Routing Key.   Also, a Routing Key cannot extend across more than a

 
single SS7 DPC, in order to more easily support SS7 Management 
procedures.  It is not necessary for the parameter ranges within a 
particular Routing Key to be contiguous.  For example, an ASP could be 
configured to support call processing for multiple ranges of PSTN 
trunks that are not represented by contiguous CIC values.

Routing Context : An Application Server Process may be configured to 
process traffic within more than one Application Server.  In this case,
the Routing Context parameter is exchanged between the SG and the ASP, 
identifying the relevant Application Server.  From the perspective of 
an ASP, the Routing Context uniquely identifies the range of traffic 
associated with a particular Application Server, which the ASP is 
configured to receive from the SG.  There is a 1:1 relationship between
a Routing Context value and a Routing Key at an SG.  Therefore the 
Routing Context can be viewed as an index into an SG Table containing
the SG Routing Keys. 

Fail-over - The capability to re-route signaling traffic as required to
an alternate Application Server Process, or group of ASPs, within an
Application Server in the event of failure or unavailability of a 
currently used Application Server Process.  Fail-back may apply upon 
the return to service of a previously unavailable Application Server 
Process.
Signaling Point Management Cluster (SPMC): A complete set of 
Application Servers represented to the SS7 network under the same SS7 
Point Code.  SPMCs are used to sum the availability/congestion/
User_Part status of an SS7 destination point code that is distributed 
in the IP domain, for the purpose of supporting MTP3 management 
procedures at an SG.  In some cases, the SG itself may also be a member
of the SPMC.  In this case, the SG availability/congestion/User_Part 
status must also be taken into account when considering any supporting 
MTP3 management actions.  

MTP3-User - Any protocol normally using the services of the SS7 MTP3 
(e.g., ISUP, SCCP, TUP, etc.).

Sunil-Prashant-Ashok, HSS                                 [Page  5]

Internet Draft          Test Specs for M3UA                 Feb 2001

Network Appearance: The Network Appearance identifies an SS7 network 
context for the purposes of logically separating the signaling traffic 
between the SG and the Application Server Processes over a common SCTP 
Association.  An example is where an SG is logically partitioned to 
appear as an element in four separate national SS7 networks.  A Network
Appearance implicitly defines the SS7 Point Code(s), Network Indicator 
and MTP3 protocol type/variant/version used within a specific SS7 
network partition.  An physical SS7 route-set or link-set at an SG can 
appear in only one network appearance. The Network Appearance is not 
globally significant and requires coordination only between the SG and
the ASP.

Network Byte Order: Most significant byte first, a.k.a Big Endian.

Layer Management: Layer Management is a nodal function in an SG or ASP
that handles the inputs and outputs between the M3UA layer and a local 
management entity.  

Host - The computing platform that the ASP process is running on.

Stream - A stream refers to an SCTP stream.

2 General Principles of M3UA Tests
These tests aim to verify a given implementation of a protocol in 
accordance with the relevant draft. The specification is independent of
a given implementation and does not generally imply any modification of
the endpoint under test. However, it is recognized that certain tests 
require capabilities of the system that are not explicitly defined in 
the draft, and these capabilities may not be present in all 
implementations. As a consequence, certain tests may not be possible in
all implementations. 

2.1 Presentation of test descriptions
Each test description includes the environment in which the point under
test must be inserted in order to pass the test. Nine test 
configurations are defined (named A, B, C, D, E, F, G, H, I and J); 
they are presented in clause 3. 
Each test is precisely described. Nevertheless, some events not 
directly concerning the point under test, or without direct link with 
the test nature, are not explicitly described. In order to preserve the
test description implementation independence, certain flexibility has 
been left in the test descriptions. This is particularly the case when 
it is necessary to terminate the SCTP association (where it is only 
mentioned "Terminate" with no more precision). The operator will choose
according to the implementation particularities and the events expected
in the test description, the appropriate Termination means (MML- Man 
machine Language, provoked failure, etc.).

Sunil-Prashant-Ashok, HSS                                 [Page  6]

Internet Draft          Test Specs for M3UA                 Feb 2001

2.1.1 Pre Test Condition 
Before starting the test we need to get the setup into a condition from
where test can be started. These conditions are specified in Pre-Test 
condition in each test. 

Note: Routing Context and Routing Key has been used inter exchangably.
In case of message it is Routing Context and in the test configuration 
it is Routing Key.

Note: Where NIF has been written, it means that NIF+SM. In some 
implementation these may be two entities and in some, they may be 
implemented in single entity. 

3 Test Configurations:				 
The set of tests described in this Recommendation assumes that the 
point under test is inserted in a test environment called "test 
configuration".

3.1 Presentation of test configurations:
There are different configurations for testing the M3UA protocol. These
configurations and hence test cases have been divided on the basis of 
M3UA at SG and M3UA at AS.
 
3.2 Configuration for testing the M3UA at SG/IPSP:

3.2.1 Configuration A:
This simple configuration is used for all the procedures of tests 
concerning only one AS. Configuration A is shown in figure 1. AS is 
handling the traffic for routing context P and N/w Appearance A. AS is 
having only one ASP ASP1.Point Code of SG is Z. Routing Context P may 
be based on the following information:
1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN

  -------------                                 --------------
 | SG/IPSP     |                               | AS  DPC = X  | 
 | under Test  |                               |  -------     |
 | DPC = Z     |-------------------------------|--| ASP1 |    |
 |             |                               |  -------     |  
  -------------                                 --------------
                      Fig 1: Configuration A

Sunil-Prashant-Ashok, HSS                                 [Page  7]

Internet Draft          Test Specs for M3UA                 Feb 2001

3.2.2 Configuration B:
This configuration is used for all the procedures of tests concerning
one ASP in two AS which are handling traffic for both AS. Configuration 
B is shown in figure 2. AS1 is handling the traffic for routing context
P and N/w Appearance A. AS2 is handling the traffic for routing context 
Q and N/w Appearance A. ASP1 is in both AS. Point Code of SG/IPSP is Z.
Routing Context P and Q may be based on the following information:
1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN

                    
                                                 
                                                --------------
                                               | AS1 DPC  X   | 
  -------------                                |  -------     |
 |             |-------------------------------| | ASP1  |    |
 | SG/IPSP     |                               |  -------     |  
 | Under Test  |                                --------------
 | DPC Z       |                                --------------  
 |             |-------------------------------| AS2 DPC Y    | 
  -------------                                |   -------    |
                                               |  | ASP1  |   | 
                                               |   -------    | 
                                                --------------

                     Fig 2: Configuration B

Sunil-Prashant-Ashok, HSS                                 [Page  8]

Internet Draft          Test Specs for M3UA                 Feb 2001

3.2.3 Configuration C:
This configuration is used for all the procedures of tests concerning 
two or more ASP in one AS. Configuration C is shown in figure 3. AS is 
handling the traffic for routing context P and N/w Appearance A. ASP1 
and ASP2 can be in FAIL-OVER mode or LOADSHARE mode of traffic 
handling. Point Code of SG/IPSP is Z. Routing Context P may be based on
the following information:
1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN

                                                --------------
                                               | AS  DPC  X   | 
  -------------                                |  -------     |
 |             |-------------------------------|-| ASP1  |    |
 | SG/IPSP     |                               |  -------     |  
 | Under Test  |                               |  -------     |
 | DPC Z       |                               | | ASP2  |    | 
 |             |-------------------------------|- -------     | 
  -------------                                 --------------
                                                

                    Fig 3: Configuration C

   ( Note: In test case 1.9.3 it is assumed that as is containing 
     three ASPs) 

3.2.4 Configuration D:
This configuration is used for all the procedures of tests concerning 
two or more AS which are handling traffic for different network 
appearance and different routing context. Configuration D is shown in 
figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and 
AS3 is handling traffic for N/w appearance B. AS1 is handling traffic 
for Routing Context P, AS2 is handling traffic for Routing Context Q 
and AS3 is handling traffic for Routing Context R.

Sunil-Prashant-Ashok, HSS                                 [Page  9]

Internet Draft          Test Specs for M3UA                 Feb 2001

                                                --------------
                                               | AS1 DPC  X   | 
  -------------                                |  -------     |
 |             |-------------------------------| | ASP1  |    |
 | SG/IPSP     |                               |  -------     |  
 | Under Test  |                                --------------
 | DPC Z       |                                --------------  
 |             |-------------------------------| AS2 DPC Y    | 
  ------------- -------+                       |   -------    |
                       |                       |  | ASP2  |   | 
                       |                       |   -------    | 
                       |                        --------------
                       |                        --------------  
                       |                       | AS3 DPC T    | 
                       +-----------------------|-  -------    | 
                                               |  | ASP 3 |   |
                                               |   -------    |
                                                --------------

                       Fig 4: Configuration D

3.2.5 Configuration E:
This configuration is used for all the procedures of tests concerning 
two AS which are handling traffic for two Routing Contexts. 
Configuration E is shown in figure 5. AS1 is handling the traffic for 
routing context P. AS2 is handling the traffic for Routing Context Q. 
ASP1 is in AS1 and ASP2 is in AS2. Routing Contexts are sharing the 
point code. 
                                                --------------
                                               | AS1 DPC  X   | 
  -------------                                |  -------     |
 |             |-------------------------------| | ASP1  |    |
 | SG/IPSP     |                               |  -------     |  
 | Under Test  |                                --------------
 | DPC Z       |                                --------------  
 |             |-------------------------------| AS2 DPC X    | 
  -------------                                |   -------    |
                                               |  | ASP2  |   | 
                                               |   -------    | 
                                                --------------
                     Fig 5: Configuration E

3.2.6 Configuration F:
This configuration is used for all the procedures of tests concerning 
AS serving different SIO. Configuration F is shown in figure 6. AS1 is 
handling the traffic for routing context P, AS2 is handling for routing
context Q and AS3 for routing context R. All AS are handling traffic 
for N/w appearance A. Point Code of SG/IPSP is Z. AS1 and AS2 are 
serving the SIO ISUP but different CIC range and AS3 is serving the SIO
SCCP.
Sunil-Prashant-Ashok, HSS                                 [Page  10]

Internet Draft          Test Specs for M3UA                 Feb 2001

                                                --------------
                                               | AS1 DPC  X   | 
  -------------                                |  -------     |
 |             |-------------------------------| | ASP1  |    |
 | SG/IPSP     |                               |  -------     |  
 | Under Test  |                                --------------
 | DPC Z       |                                --------------  
 |             |-------------------------------| AS2 DPC X    | 
  ------------- -------+                       |   -------    |
                       |                       |  | ASP2  |   | 
                       |                       |   -------    | 
                       |                        --------------
                       |                        --------------  
                       |                       | AS3 DPC X    | 
                       +-----------------------|-  -------    | 
                                               |  | ASP 3 |   |
                                               |   -------    |
                                                --------------

                     Fig 6: Configuration F

3.3 Configuration for testing the M3UA at AS

3.3.1 Configuration G:
This simple configuration is used for all the procedures of tests 
concerning only one SG/IPSP. Configuration G is shown in figure 7. 
Point Code of SG is Z. ASP is handling the traffic for routing 
context P.
Routing Context P may be based on the following information:
1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN

  -------------                                 --------------
 | ASP1        |                               | SG/IPSP      | 
 | under Test  |                               | DPC = Z      |
 | DPC = X     |-------------------------------|              |
 |             |                               |              |  
  -------------                                 --------------

                    Fig 7: Configuration G

Sunil-Prashant-Ashok, HSS                                 [Page 11]

Internet Draft          Test Specs for M3UA                 Feb 2001

3.3.2 Configuration H:
This configuration is used for all the procedures of tests concerning 
two SGs/IPSPs connected to the same ASP and handling traffic for the 
same DPCin the SEP network. Configuration H is shown in figure 8. 
SG1/IPSP1 and SG2/IPSP2are handling the traffic for N/w Appearance A.   
Point Code of SG1/IPSP1 is Y and of SG2/IPSP2 is Z.  
Routing Context P may be based on the following 
information:
1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN

                                                --------------
                                               | SG1/IPSP1    | 
  -------------                                | DPC Y        |
 |             |-------------------------------|              |
 | ASP1        |                               |              |  
 | Under Test  |                                --------------
 | DPC X       |                                --------------  
 |             |-------------------------------| SG2/IPSP2    | 
  -------------                                | DPC Z        |
                                               |              | 
                                               |              | 
                                                --------------
                      Fig 8: Configuration H

3.3.3 Configuration I:
This simple configuration is used for all the procedures of tests 
concerning one ASP in two AS. Configuration I is shown in figure 9. 
Point Code of SG/IPSP is Z. ASP1 is in two AS, AS1 and AS2. AS1 is 
handling traffic for routing context P and AS2 is handling traffic for
routing context Q. Routing Context P and Q may be based on the  
following information:

1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN

Sunil-Prashant-Ashok, HSS                                 [Page  12]

Internet Draft          Test Specs for M3UA                 Feb 2001

   --------------
  |   Under Test |
  | AS1 DPC  X   | 
  |  -------     |                       ----------------
  | | ASP1  |    | ---------------------|                | 
  |  -------     |                      |  SG / IPSP     |
   --------------                       |                |
   --------------                       |  DPC Z         |
  | AS2 DPC Y    |                      |                |
  |   -------    | ---------------------|                |
  |  | ASP1  |   |                       ----------------
  |   -------    |                       
  | Under Test   |
   --------------

                    Fig 9: Configuration I

3.3.4 Configuration J:
This configuration is used for all the procedures of tests concerning 
two SGs/IPSPs connected to the same ASP.SG1 is handling trafic for 
Routing context P and SG2 is handling traffic for routing context P and
Q.  Configuration J is shown in figure 10. Point Code of SG1/IPSP1 is Y
and of SG2/IPSP2 is Z. Routing Context P may be based on the following 
information:
1.  DPC
2.  DPC+CIC+SIO
3.  DPC+SIO
4.  DPC+SSN
                                                --------------
                                               | SG1/IPSP1    | 
  -------------                                | DPC Y        |
 |             |-------------------------------|              |
 | ASP1        |                               |              |  
 | Under Test  |                                --------------
 | DPC X       |                                --------------  
 |             |-------------------------------| SG2/IPSP2    | 
  -------------                                | DPC Z        |
                                               |              | 
                                               |              | 
                                                --------------

                      Fig 10 : Configuration J

 

Sunil-Prashant-Ashok, HSS                                 [Page  13]

Internet Draft          Test Specs for M3UA                 Feb 2001

4    Test Cases

4.1  Test Cases for Testing M3UA at SG
     These test cases are used to test the M3UA at SG.

"Send and Receive Transfer Primitive in AS Active State"

+ TEST NUMBER : 1.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.3.1 and 1.6

+ TITLE :  MTP-Transfer Primitive

+ SUBTITLE : Send and Receive Transfer Primitive in AS Active State

+ PURPOSE: To check that on receiving Transfer primitive from NIF, DATA
           message is sent to the AS.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. ASP1 is active. Also arrange the data in SG such that upper 
  layers send MTP-Transfer indication primitive to M3UA with data to be
  sent to DPC X and N/w Appearance A.

 EXPECTED MESSAGE SEQUENCE :
    ASP                              SG              NIF
a)                                 ASP is Active
                                      <-----------  MTP-Transfer
               <-------------       DATA            N/w appearance A

b)

      DATA      -------------->
                                   MTP-Transfer --------->
TEST DESCRIPTION:
1. Send Transfer Request Primitive from the NIF at SG side to send 
   Protocol Data to the ASP1. 
2. Check A: DATA message should be received at the ASP1 containing the 
   data passed by the NIF and the Network Appearance.
3. Send DATA message from ASP containing Protocol Data and Network 
   Appearance A that is known to SG.
4. Check B: Transfer primitive is received at the NIF with the Protocol
   Data.
5. Repeat the test step 3 if N/w Appearance parameter is not present in
   the DATA message sent from ASP to SG.
Note:  Network Appearance is an optional parameter. In some 
       implementation this parameter will not be present in DATA 
       message sent from SG to ASP.

Sunil-Prashant-Ashok, HSS                                 [Page  14]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Stream Selection" 

+ TEST NUMBER : 1.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.7

+ TITLE :  Stream Selection

+ SUBTITLE : Stream Selection 

+ PURPOSE: To check that all the messages for the same call are sent on
           the same SCTP stream.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS with two or more streams. ASP1 is active. Also arrange the data in

  SG such that NIF send three or more Transfer indication primitive to 
  M3UA with  N/w Appearance A containing the Data with same CIC value 
  to be sent to DPC X. 

 EXPECTED MESSAGE SEQUENCE :
     ASP                              SG             NIF
                                     ASP is active
                                       <---------   MTP-Transfer
Check Stream id  <-------------      DATA           Data with CIC X  

                                       <---------   MTP-Transfer
Check Stream id  <-------------      DATA           Data with CIC X

                                       <---------   MTP-Transfer
Check Stream id  <-------------      DATA           Data with CIC X

TEST DESCRIPTION:
1. Send three or more Transfer Request Primitive from the NIF at SG  
   side to send Protocol Data to the ASP. In the Protocol Data CIC 
   values should be same in all Transfer Request primitive assuming 
   load sharing across streams is based on CIC.
2. Check A: DATA messages are received at the ASP1 containing the same 
   Stream Sequence number.
3. Repeat the above test with same SLS value in Protocol Data in all 
   Transfer Request primitive assuming load sharing across the streams
   is based on SLS.
4. Repeat the above test case with different CIC values and different 
   SLS values. DATA messages should be sent on different streams.
Note: How the messages will be distributed on different streams based 
      on CIC and SLS is implementation dependent.

Sunil-Prashant-Ashok, HSS                                 [Page  15]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Transfer Request Primitive from NIF in AS Inactive State"

+ TEST NUMBER : 1.3.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt   Clause  4.3.3.5

+ TITLE :  AS management

+ SUBTITLE : Transfer Request from NIF in AS Inactive State 

+ PURPOSE: To check that if AS is Inactive at SG and NIF sends Transfer
  Primitive to send to that AS then it receives a send failure.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP1 is active. Also arrange the data in ASP such that ASPIA 
  message is sent from ASP1 to SG on stream 0. The Type field in APSIA 
  can be any valid value which is equal to the traffic handling mode 
  for the AS at the SG and Routing Context should be P.

EXPECTED MESSAGE SEQUENCE :
  ASP                                 SG                NIF + SM
 
 ASPIA        --------------->
(ASP1)                              Status Ind  -------->

              <--------------        ASP-Inactive-Ack    
 
              <--------------       NTFY(AS-Pending)     

                                                <-------- MTP-Transfer  
                                    Send failure -------->
TEST DESCRIPTION:
1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to
   Inactive state at the SG. Send MTP-Transfer Primitive with N/w 
   Appearance A containing Protocol Data with DPC X.   
2. Check A: Send failure should be received at the NIF and DATA message
   should not be sent to ASP.
3. Repeat the above test if ASPIA message is sent without Routing 
   Context Parameter. ASP-Inactive-Ack and NTFY(AS-Pending) should be 
   received at the ASP with either all routing contexts configured at
   the SG or with no routing context for the ASP. 
4. Repeat the above test if instead of sending ASPIA message, SCTP 
   association between ASP and SG is removed.
Note: In some implementation there may be T(r) running on receiving 
      ASPDN or ASPIA message for the last ASP and for that time AS will
      be in AS-Pending state. In that case let the timer T(r) expire 
      before sending the Transfer primitive.
Sunil-Prashant-Ashok, HSS                                 [Page  16]

Internet Draft          Test Specs for M3UA                 Feb 2001

"MTP-Transfer Request Primitive from NIF in AS Down State"

+ TEST NUMBER : 1.3.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.1.1

+ TITLE :  AS management

+ SUBTITLE : MTP-Transfer Request from NIF in AS Down State 

+ PURPOSE: To check that if AS is down at SG and NIF sends MTP-Transfer 
  Primitive to send to that AS then it receives a send failure.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP1 is active. Also arrange the data in ASP such that ASPDN 
  message is sent from ASP1 to SG on stream 0. The Reason parameter in 
  ASPDN message can be any valid value.

EXPECTED MESSAGE SEQUENCE :
  ASP                                 SG                NIF + SM
 
 ASPIA        --------------->  
(ASP1)                              Status Ind ---------> 

              <--------------       ASP-Inactive-Ack    
 
              <--------------       NTFY(AS-Pending)      

 ASPDN        --------------->
(ASP1)                              Status Ind --------->
              <--------------        ASP-Down-Ack    
 
              <--------------       NTFY(AS-Down)     

                                            <--------   MTP-Transfer  
                                         Send failure -------->
TEST DESCRIPTION:
1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to
   Inactive state at the SG. 
2. Send ASPDN message from ASP to the SG. ASP will move to down state 
   at the SG. Send MTP-Transfer Primitive with N/w Appearance A 
   containing Protocol Data with DPC X.
3. Check A: Send failure should be received at the NIF and DATA message
   should not be sent to ASP.
Note: In some implementation there may be T(r) running on receiving 
      ASPDN message for the last ASP and for that time AS will
      be in AS-Pending state. In that case let the timer T(r) expire 
      before sending the MTP-Transfer primitive.
Sunil-Prashant-Ashok, HSS                                 [Page  17]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Timer T(r) Cancellation"

+ TEST NUMBER : 1.3.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.5

+ TITLE :  AS management

+ SUBTITLE : Timer T(r) Cancellation

+ PURPOSE: To check that after last ASP becomes inactive then SG 
  buffers the messages from NIF for time T(r) and if ASPAC comes before
  its expiry then all buffered messages are sent to the ASP.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP1 is active. Arrange the data in ASP such that ASPIA and 
  ASPAC messages are sent from ASP1 to SG on stream 0. The Type field 
  in APSIA and ASPAC can be any valid value and Routing Context should 
  be P. Let the value of Timer T(r) be z sec. 

EXPECTED MESSAGE SEQUENCE :
  ASP                              SG               SM + NIF
                                   ASP is active
ASPIA    -----------------> 
(ASP1)                             Status Ind  -------->
                                   
         <----------------         ASP-Inactive-Ack    
 
         <----------------         NTFY(AS-Pending)    
                |                  Timer T(r) is started
                |                 
                | Time < z sec.         <-------   MTP-Transfer  
                |                  Message will be buffered 
                |                       <-------   MTP-Transfer  
                |                  Message will be buffered 
ASPAC     --------------->
(ASP1)                             Status Ind  -------->
          <---------------         ASP-Active-Ack

          <---------------         NTFY(AS-Active)  
                                   
          <---------------         DATA
                                   
          <---------------         DATA
   

Sunil-Prashant-Ashok, HSS                                 [Page  18]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPIA Message from ASP1 to SG. ASP will become Inactive at the SG.
2. Send MTP-Transfer Primitive from NIF with N/w Appearance A  
   containing Protocol Data to be sent to DPC X.
3. Check A: DATA message will not be received at ASP.
4. Send ASPAC message containing N/w Appearance A before Timer T(r) 
   expires. 
5. Check B: DATA messages buffered at the SG will be sent to the AS.
Note: This case is implementation specific. In some implementation 
      there may not be any Timer T(r) running. In that case there is no
      need to run this test case.
Note1: NTFY message with AS status may come before the NTFY message 
       with ASP status.

Sunil-Prashant-Ashok, HSS                                 [Page  19]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Timer T(r) Expiry"

+ TEST NUMBER : 1.3.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.5

+ TITLE :  AS management

+ SUBTITLE : Timer T(r) Expiry

+ PURPOSE: To check that timer T(r) is cancelled on receiving ASPAC 
           message from the AS.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP1 is active. Arrange data in ASP such that ASPIA and ASPAC
  messages are sent from ASP1 to SG on stream 0. The Type field in 
  APSIA and ASPAC can be any valid value and Routing Context should be 
  P. Let the value of Timer T(r) is z sec.

 EXPECTED MESSAGE SEQUENCE :
  ASP                              SG               SM + NIF
                                   ASP is active

                                      <-------   MTP-Transfer 
                                   
          <---------------         DATA

                                     <-------   MTP-Transfer
 
          <---------------         DATA

ASPIA     ---------------->
                                   Status Ind  -------->
          <---------------         ASP-Inactive-Ack

          <---------------         NTFY(AS-Pending) 
                 | 
                 |Time = z sec     <-------   MTP-Transfer 
                 |
                 |                 <-------   MTP-Transfer 
                                    ( Data is buffered and after expiry 
                                      of timer it will be discarded)
                        Status Ind --------->

          <---------------         NTFY(AS-Down)
                                     <--------    MTP-Transfer
                                   Send Failure ------->
Sunil-Prashant-Ashok, HSS                                 [Page  20]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send MTP-Transfer Primitive with N/w appearance A containing  
   protocol Data to send to DPC X. Message will be buffered at SG. 
2. Send ASPIA message from ASP1 to the SG. ASP will become Inactive at
   SG. AS will be in AS-Pending state at the SG.
   
3. Check A: Timer T(r) is started.
4. Send MTP Tranfer Primitive with Network Appearance A containing 
   protocol data to send DPC X. Message will be buffered at SG.
5. TimerT(r) is expired, and the message buffered is discarded, also 
   after the expiry of T(r) AS will move to the AS-DOWN state. 
6. Send MTP-Transfer Primitive from NIF with N/w appearance A 
   containing protocol Data to send to DPC X. SG will send Send Failure.
7. Repeat the above test case if ASPDN message with any valid Reason 
   parameter is sent instead of ASPIA message.
Note: This case is implementation specific. In some implementation 
      there may not be any Timer T(r) running. In that case send 
      failure is notified by M3UA on receiving MTP-Transfer request.
Note1: NTFY message with AS status may come before the NTFY message 
       with ASP status.

Sunil-Prashant-Ashok, HSS                                 [Page  21]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Notify Message with AS Status"

+ TEST NUMBER : 1.3.5

+ Reference: draft-ietf-sigtran-m3ua-03.txt  Clause 4.3.3

+ TITLE :  AS management

+ SUBTITLE : Notify Message with AS status

+ PURPOSE: To check that if ASPDN, ASPUP, ASPAC and ASPIA messages are 
  received in ASP-Active, ASP-Down, ASP-Up and ASP-Active state 
  respectively then NTFY message with correct status is sent to ASP.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Also arrange the data in ASP such that ASPDN, 
  ASPUP, ASPAC and ASPIA messages are sent from ASP to SG for ASP and 
  these are sent on stream zero. The value of N/w Appearance is A and 
  Routing Context is P in all the messages and other parameters are 
  having valid values.

 EXPECTED MESSAGE SEQUENCE :
 ASP                              SG                       SM 
                                  ASP  is active 

 ASPDN   --------------->
 (ASP1)                           Status Ind ---------->

         <--------------          ASP-Down-Ack
 
         <--------------          NTFY(AS-Down)    

 ASPUP   --------------->       
 (ASP1)                           Status Ind ----------->

         <--------------          ASP-Up-Ack

         <--------------          NTFY (AS-Inactive)    

 ASPAC   --------------->       
 (ASP1)                           Status Ind ----------->

         <--------------          ASP-Active-Ack

         <--------------          NTFY (AS-Active)

Sunil-Prashant-Ashok, HSS                                 [Page  22]

Internet Draft          Test Specs for M3UA                 Feb 2001

 ASPIA   --------------->       
 (ASP1)                           Status Ind ----------->
         <--------------          ASP-Inactive-Ack

         <--------------          NTFY (AS-Pending)
  
TEST DESCRIPTION:
1. Send ASPDN message for ASP1 from ASP to the SG. 
2. Check A: ASPDN is acknowledged by ASP-Down-Ack and NTFY (AS-Down) 
   message at the ASP.  
3. Send ASPUP message to SG.
4. Check B: SG responds with ASP-UP-Ack message and NTFY (AS-Inactive). 
5. Send ASPAC message with Routing Context P and check SG responds with
   ASP-Active-Ack and NTFY with status AS-Active. Repeat the test case with
   Routing Context parameter not present in ASPAC message.
6. Send ASPIA message and check that SG responds with ASP Inactive-Ack and  
   NTFY with status AS-Pending.
7. Check E: NTFY message is received on stream 0. 
8. Repeat the above test case if all messages from ASP are sent on 
   stream other than zero.
Note1: NTFY message with AS status may come before the NTFY message 
       with ASP status.

           

Sunil-Prashant-Ashok, HSS                                 [Page  23]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Received DAUD Message "

+ TEST NUMBER : 1.3.6

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.3

+ TITLE :  AS management

+ SUBTITLE : Received DAUD message

+ PURPOSE: To check that if DAUD message is received from ASP then SG 
  sends Status Request primitive to the NIF and state of ASP is not 
  changed at SG.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP1 is active. Also arrange the data in ASP such that DAUD 
  message is sent to the SG with Network Appearance A and Affected DPC
  any value. 

EXPECTED MESSAGE SEQUENCE :
 ASP                              SG                 NIF + SM
                                  AS is active  
 DAUD    -------------> 
                                  Status Request ------>   
                                  
                                            <------ Pause/Resume/State
         <------------            DUNA/DAVA/SCON

TEST DESCRIPTION:
1. Send DAUD message with N/w appearance A and affected DPC any value 
   from ASP to the SG. 
2. Check A: Status Request Primitive is received at SM with the DPC and
   N/w appearance received in the DAUD message.
3. Check B: State of AS will not be changed at SG. Send Pause/Resume
   primitive with N/w appearance A and SG should send DUNA/DAVA message
   to the ASP1.
4. Repeat the above test case if DAUD message is sent without N/w 
   Appearance parameter. Response should be same as in the above case.
Note: DUNA/DAVA/SCON message may be sent by M3UA itself in response to 
      DAUD message depending upon the implementation. 
Note1: ASP auditing is an optional procedure and may not be supported 
      at ASP/SG.
       

Sunil-Prashant-Ashok, HSS                                 [Page  24]

Internet Draft          Test Specs for M3UA                 Feb 2001
                
"ASPAC message with more than one Routing Context"

+ TEST NUMBER : 1.3.7

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4

+ TITLE : AS management

+ SUBTITLE : ASPAC message with more than one Routing Context

+ PURPOSE: To check that if ASPAC message is received with more than 
  one Routing Context then status of ASP is active in all the AS to 
  which this ASP belongs. 

+ TEST CONFIGURATION: B

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1. ASP1 is belonging to two AS, AS1 and AS2. AS1 is handling 
  traffic for routing context P and AS2 is handling traffic for routing
  context Q. ASP1 is in Inactive state i.e. AS1 and AS2 are in the 
  AS-Iactive state at SG.Also arrange the data in ASP1 such that ASPAC
  message is sent from ASP1 to SG on stream 0 containing Routing 
  Context P and Q. Fill any valid value in the Type parameter which  
  is same as configured for AS1 and AS2 at the SG and it should be 
  same for both AS.
  

EXPECTED MESSAGE SEQUENCE :
 ASP                              SG              SM + NIF
                                 AS1 & AS2 is Inactive    
ASPAC     ------------------>  
Routing Context P and Q          Status Ind --------->

          <-----------------     ASP-Active-Ack    
          <-----------------     NTFY (AS-Active) 
         
                                   <--------     MTP-Transfer
                                                 for Routing Context P
          <-----------------     DATA
                                   <--------     MTP-Transfer
                                                 for Routing Context Q
          <-----------------     DATA  

TEST DESCRIPTION:
1. Send ASPAC Message with routing contexts P and Q to the SG. 
2. Check A: ASP-Active-Ack and NTFY message with status AS-Active 
   should be received at ASP with routing contexts P and Q.
3. Check B: Check that state of ASP is active in AS1 and AS2.  This can
   be checked by sending DATA messages containing protocol DATA for 
   both Routing Contexts. 
Sunil-Prashant-Ashok, HSS                                 [Page  25]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPAC message without any Routing Context"

+ TEST NUMBER : 1.3.8

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4

+ TITLE : AS management

+ SUBTITLE : ASPAC message without any Routing Context

+ PURPOSE: To check that if ASPAC message is received without any 
  Routing Context then status of ASP is active and it is kept in
  free pool.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  AS. Both ASP are having SCTP association with SG and are Inactive in 
  the AS. Arrange data in AS such that ASPAC messages are sent to the
  SG from ASP1 on stream 0. Dont fill any routing context parameter.
     
EXPECTED MESSAGE SEQUENCE :
 ASP                              SG              SM + NIF
                                 AS1 & AS2 is Inactive    
ASPAC     ------------------>  
No Routing Context               Status Ind --------->

          <-----------------     ASP-Active-Ack    
          <-----------------     NTFY (AS-Active) 
         

TEST DESCRIPTION:
1. Send ASPAC Message without any routing to the SG. 
2. Check A: ASP-Active-Ack and NTFY message with status AS-Active 
   should be received at ASP without any routing context.
3. Check B: Check that state of ASP is active and put in the spare pool.
Note: This is implementation dependent. Alternatively it may also send 
   a Protocol Error.

Sunil-Prashant-Ashok, HSS                                 [Page  26]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPIA message with more than one Routing Context"

+ TEST NUMBER : 1.3.9

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.5

+ TITLE :  AS management

+ SUBTITLE : ASPIA message with more than one Routing Context

+ PURPOSE: To check that if ASPIA message is received with more than 
  one Routing Context then status of ASP is Inactive in all the AS to 
  which this ASP belongs.   

+ TEST CONFIGURATION: B

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. ASP1 is belonging to two AS, AS1 and AS2. AS1 is handling traffic
  for routing context P and AS2 is handling traffic for routing context
  Q. ASP1 is in Active state i.e. AS1 and AS2 are in the AS-Active 
  state at SG. Also arrange the data in ASP1 such that ASPIA message is
  sent on stream 0 from ASP1 to SG containing Routing Context P and Q. 
  Fill any valid value in the Type parameter which is same as 
  configured for AS1 and AS2 in SG and it should be same for both AS.

EXPECTED MESSAGE SEQUENCE :
 ASP                        SG                  SM + NIF
                            AS1 & AS2 is Active    
ASPIA     ------------------> 
Routing Context P and Q          Status Ind --------->

          <-----------------     ASP-Inactive-Ack    

          <-----------------     NTFY(AS-Pending)

                                   <--------     MTP-Transfer
                                                 Routing Context P
                                Send Failure -------->
                 
                                   <--------     MTP-Transfer
                                                 Routing Context Q
                                Send Failure -------->

Sunil-Prashant-Ashok, HSS                                 [Page  27]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPIA Message containing routing contexts P and Q from ASP1 to
   the SG. 
2. Check A: ASP-Inactive-Ack and NTFY (AS-Pending) message should be  
   received at the ASP with routing contexts P and Q.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is Inactive in AS1 and AS2. This 
   can be checked by sending MTP-Transfer primitive from NIF at SG  
   containing protocol DATA for both Routing Contexts. 
Note: Routing Context is an optional parameter in the NTFY message. 
      Some implementation may not send this parameter in the NTFY 
      message. In that case two NTFY message with status 
      AS-Inactive/AS-Pending will be received one for AS1 and other for
      AS2.
Note1: NTFY message with AS status may come before the ASP-Inactive-Ack
      message. 
      

Sunil-Prashant-Ashok, HSS                                 [Page  28]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Notify Message with AS Status is sent only for AS State change -A"

+ TEST NUMBER : 1.3.10

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.1.2

+ TITLE :  AS management

+ SUBTITLE : Notify Message with AS Status is sent only for AS State 
  change

+ PURPOSE: To check that NTFY message with AS state change is not sent
  if there is no change in the state of the AS.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  AS. Both ASP are having SCTP association with SG and are active in 
  the AS. Arrange data in AS such that ASPUP, ASPAC, ASPIA and ASPDN
  messages are sent to the SG from ASP1 on stream 0. Fill the routing 
  contexts P and Type parameter any valid value which is same 
  configured for AS at the SG. 

 EXPECTED MESSAGE SEQUENCE :
 AS                               SG                        SM
                                Both ASPs are active 

ASPIA(ASP1)  ----------------->

             <----------------    ASP-Inactive-Ack    
Check: NTFY(AS-Pending) is not received
                                    Status Ind --------->
ASPDN(ASP1)  ----------------->

             <----------------    ASP-Down-Ack    
 Check: NTFY(AS-Down) is not received
                                    Status Ind --------->

ASPUP(ASP1)  ----------------->

             <----------------    ASP-Up-Ack    
 Check: NTFY(AS-Inactive) is not received
                                    Status Ind --------->
ASPAC(ASP1)  ----------------->

             <----------------    ASP-Active-Ack    
 Check: NTFY(AS-Active) is not received
                                    Status Ind --------->

Sunil-Prashant-Ashok, HSS                                 [Page  29]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPIA message for ASP1 from ASP to the SG with routing context
   P and Type parameter any valid value. 
2. Check A: ASP-Inactive-Ack messages is received at the AS and
   NTFY message with status AS-Inactive is not received.
3. Repeat the above test case for other messages like ASPDN, ASPUP and
   ASPAC for ASP1 from AS to SG. 

Sunil-Prashant-Ashok, HSS                                 [Page  30]

Internet Draft          Test Specs for M3UA                 Feb 2001                   

"Notify Message with AS Status is sent only for AS State change -B"

+ TEST NUMBER : 1.3.11

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.1.2

+ TITLE :  AS management

+ SUBTITLE : Notify Message with AS Status Change

+ PURPOSE: To check that NTFY message with AS state change is sent
  if AS state has changed.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  AS. Both ASP are having SCTP association with SG and are active in 
  the AS. Arrange data in AS such that ASPUP, ASPAC, ASPIA and ASPDN
  messages are sent to the SG from ASP1 and ASP2 on stream 0. Fill the 
  routing contexts P and Type parameter any valid value which is same 
  configured for AS at the SG. 

 EXPECTED MESSAGE SEQUENCE :
 AS                               SG                        SM
                                Both ASP are active 

ASPIA(ASP1)  ----------------->

             <----------------    ASP-Inactive-Ack    

                                    Status Ind --------->
ASPIA(ASP2)  ----------------->

             <----------------    ASP-Inactive-Ack    

             <----------------    NTFY(AS-Pending)    

                                    Status Ind --------->
ASPDN(ASP1)  ----------------->

             <----------------    ASP-Down-Ack    
                                    Status Ind --------->
ASPDN(ASP2)  ----------------->

             <----------------    ASP-Down-Ack    

             <----------------    NTFY( AS-Down)    
                                    Status Ind --------->

Sunil-Prashant-Ashok, HSS                                 [Page  31]

Internet Draft          Test Specs for M3UA                 Feb 2001

 ASPUP(ASP1)  ----------------->

             <----------------    ASP-Up-Ack 
   
             <----------------    NTFY( AS-Inactive)   

                                    Status Ind --------->
ASPUP(ASP2)  ----------------->

             <----------------    ASP-Up-Ack    
       
                                    Status Ind --------->

ASPAC(ASP1)  ----------------->

             <----------------    ASP-Active-Ack  

             <----------------    NTFY( AS-Active)  

                                    Status Ind --------->
ASPAC(ASP2)  ----------------->

             <----------------    ASP-Active-Ack    
                 
                                    Status Ind --------->

TEST DESCRIPTION:
1. Send ASPIA message for ASP1 and ASP2 from ASP to the SG with routing
   context P and Type parameter any valid value. 
2. Check A: ASP-Inactive-Ack and NTFY message with status AS-Pending is
   received at the AS. 
3. Check B: NTFY messages are received on stream 0.
4. Repeat the above test case for other messages like ASPDN, ASPUP and
   ASPAC for ASP1 from AS to SG. 
Note: NTFY message with AS status may come before the NTFY message with
      ASP status.

Sunil-Prashant-Ashok, HSS                                 [Page  32]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Heartbeat and HeartbeatAck"

+ TEST NUMBER : 1.3.12

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.1.2

+ TITLE :  AS management

+ SUBTITLE : Heartbeat 

+ PURPOSE: : To check that  an ASP sends Heartbeat messages (to ensure
  that the M3UA peers are still available to each other) and receives a
  Heartbeat Ack from the remote peer.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP1 is active. Also arrange the data in ASP such that BEAT 
  message is sent from ASP1 to SG.   

  EXPECTED MESSAGE SEQUENCE:
  AS                               SG                        SM

 a) BEAT (ASP1)   ----------------->
  Timer 2*T(beat)          |
  is started               |
                   <----------------   BEAT ACK

 b) BEAT (ASP1)   ----------------->
  Timer 2*T(beat)          |
  is started               |
                           |

  Timer 2*T(beat) is expired and no BEAT ACK is from SG.

                  

TEST DESCRIPTION:
1. Send BEAT Message for ASP1 from ASP to the SG.  
2. The beat message should be acknowledge by BEAT ACK before the Timer
   expires.
3. Send the Beat message again.
4. The timer expires and no beat ack message is received, the ASP will 
   consider remote M3UA peer as Down.Transmission of BEAT message is 
   stopped and ASP-Up procedures are used to re-establish communication
   with the SG M3UA peer. 

Sunil-Prashant-Ashok, HSS                                 [Page 33]

Internet Draft          Test Specs for M3UA                 Feb 2001

"MTP-Pause Indication Primitive:"
+ TEST NUMBER : 1.4.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.1

+ TITLE :  MTP3 management

+ SUBTITLE : MTP-Pause Indication Primitive

+ PURPOSE: To check that if MTP-Pause indication primitive is received
  from NIF at SG then SG sends DUNA message to the concerned AS.

+ TEST CONFIGURATION: D

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are 
  handling traffic for N/w appearance A and AS3 is handling traffic for
  N/w Appearance B. Also arrange the data in NIF at SG such that 
  MTP-Pause Indication Primitive is sent to the AS with Network 
  Appearance A and B and affected DPC any value. 

 EXPECTED MESSAGE SEQUENCE :
 ASP1        ASP2      ASP3            SG               NIF
                                     All AS are active
                                       <----------    MTP-Pause
                                                   N/w Appearance A     
                                                   Affected DPC T  
  <----------------------------      DUNA 
    
             <-----------------      DUNA

                                       <----------    MTP-Pause
                                                   N/w Appearance B     
                                                   Affected DPC T  
                      <---------     DUNA 
    
                                         
TEST DESCRIPTION:
1. Send MTP-Pause indication Primitive message from NIF in the SG 
   containing the Network Appearance A and Affected DPC T.
2. Check A: DUNA message will be received at the ASP1 and ASP2 
   containing the network Appearance A and Affected DPC T. 
3. Check B: DUNA message is received at both AS AS1 and AS2 which are 
   handling traffic for the same network appearance.
4. Check C: DUNA message is received on the Stream number 0.
5. Repeat the above test case with N/w Appearance B. In this case DUNA
   message should be sent to AS3.

Sunil-Prashant-Ashok, HSS                                 [Page  34]

Internet Draft          Test Specs for M3UA                 Feb 2001

"MTP-Resume Indication Primitive"

+ TEST NUMBER : 1.4.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.1

+ TITLE :  MTP3 management

+ SUBTITLE : MTP-Resume Indication Primitive

+ PURPOSE: To check that if MTP-Resume indication primitive is received
  from NIF at SG then SG sends DAVA message to the concerned AS.

+ TEST CONFIGURATION: D

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are 
  handling traffic for N/w appearance A and AS3 is handling traffic for
  N/w Appearance B. Also arrange the data in NIF at SG such that 
  MTP-Resume Indication Primitive is sent to the AS with Network 
  Appearance A and B and affected DPC any value.

EXPECTED MESSAGE SEQUENCE :
 AS1        AS2      AS3                  SG               NIF
                                     All AS are active
                                       <----------    MTP-Resume
                                                   N/w Appearance A     
                                                   Affected DPC T  
  <----------------------------      DAVA 
    
             <-----------------      DAVA

                                       <----------    MTP-Resume
                                                   N/w Appearance B     
                                                   Affected DPC T  
                      <---------     DAVA 
                                 
TEST DESCRIPTION:
1. Send MTP-Resume indication Primitive from NIF in the SG containing 
   the Network Appearance A and Affected DPC T.
2. Check A: DAVA message is received at AS1 and AS2 containing the 
   network Appearance A and Affected DPC T. 
3. Check B: DAVA message is received at AS1 and AS2 
4. Check C: DAVA message is received on the Stream number 0.
5. Repeat the test case for N/w appearance B and affected destination 
   any value. Check that message is being sent to AS3.

 Prashant-Ashok, HSS                                       [Page  35]

Internet Draft          Test Specs for M3UA                 Feb 2001

"MTP-Status Indication Primitive with Route Congested"

+ TEST NUMBER : 1.4.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.1

+ TITLE :  MTP3 management

+ SUBTITLE : MTP-Status Indication Primitive with Route Congested

+ PURPOSE: To check that if MTP-Status indication primitive with Route
  Congested parameter is received from NIF at SG then SG sends SCON 
  message to the concerned AS.

+ TEST CONFIGURATION: D

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are
  handling traffic for N/w appearance A and AS3 is handling traffic for
  N/w Appearance B. Also arrange the data in NIF at SG such that 
  MTP-Status indication Primitive is sent to the SG with cause Routing
  Congested, affected DPC, Congestion level and Network Appearance. 

EXPECTED MESSAGE SEQUENCE :
 AS1        AS2      AS3                  SG               NIF
                                     All AS are active

                                       <----------    MTP-Status
                                                   N/w Appearance A     
                                                   DPC T Cong Level 2 
  <----------------------------      SCON
    
             <-----------------      SCON

                                       <----------    MTP-Status
                                                   N/w Appearance B     
                                                   DPC T Cong Level 2 
 
                      <---------     SCON

Sunil-Prashant-Ashok, HSS                                 [Page  36]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send MTP-Status indication Primitive from NIF in the SG containing
   the Network Appearance A, cause Route congestion, Affected DPC X and
   congestion Level 2.
2. Check A: SCON message is received at the AS1 and AS2 containing the
   network Appearance A, Affected DPC X, Congestion Level 2 passed to 
   it from NIF.   
3. Check B: SCON message is received at AS1 and AS2.
4. Check C: SCON message is received on the Stream number 0.
5. Repeat the above test case for all congestion level 0,1,2 and 3.
   SCON message will be received with congestion level passed from NIF. 
6. Repeat the above test case with different congestion level for 
   different affected DPC. SCON message should contain the correct 
   congestion level for each affected destination.
7. Repeat the above test case with N/w appearance B. SCON message will
   be received at AS3.

Sunil-Prashant-Ashok, HSS                                 [Page  37]

Internet Draft          Test Specs for M3UA                 Feb 2001

"MTP-Status Indication Primitive with User Part Unavailable"

+ TEST NUMBER : 1.4.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.1

+ TITLE :  MTP3 management

+ SUBTITLE : MTP-Status Indication Primitive with User Part Unavailable

+ PURPOSE: To check that if MTP-Status indication primitive with cause
  User Part Unavailable is received from NIF at SG then SG sends DUPU 
  message to the concerned AS.

+ TEST CONFIGURATION: D

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are 
  handling traffic for N/w appearance A and AS3 is handling traffic for
  N/w Appearance B. Also arrange the data in NIF at SG such that 
  MTP-Status indication Primitive is sent to the SG with cause User 
  Part Unavailable Unknown, affected DPC, SIO for ISUP and network 
  appearance A. Assume routing context is DPC+SIO based.

EXPECTED MESSAGE SEQUENCE :

 AS1        AS2      AS3                  SG               NIF

                                     All AS are active

                                       <----------    MTP-Status
                                                   N/w Appearance A     
                                                   DPC S 
 
  <----------------------------      DUPU
    
             <-----------------      DUPU

                                       <----------    MTP-Status
                                                   N/w Appearance B     
                                                   DPC S

                      <---------     DUPU

Sunil-Prashant-Ashok, HSS                                 [Page  38]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send MTP-Status indication Primitive from NIF in the SG containing 
   the Network Appearance A, cause User Part Unavailable, Affected DPC 
   S and SIO for ISUP. 
2. Check A: SG will send DUPU message containing the network Appearance 
   A, Affected DPC S, cause unknown and user ISUP.
3. Check B: DUPU message is received at AS1 and AS2.
4. Check C: DUPU message is received on the Stream number 0.
5. Repeat the above test case with cause values Unequipped Remote User 
  and Inaccessible Remote User and other parameters being the same as 
  in the above tests. DUPU message will be received with these cause 
  values.
6. Repeat the above test case with SIO values TUP, Broadband ISUP, 
   Satellite ISUP and Reserved.
7. Repeat the above test case if MTP-Status is sent with N/w appearance
   B. DUPU message will be sent to AS3.

            

Sunil-Prashant-Ashok, HSS                                 [Page  39]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid Version Error"

+ TEST NUMBER : 1.5.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.3

+ TITLE :  Invalid Message Handling

+ SUBTITLE : Invalid Version Error

+ PURPOSE: To check that if any message with Invalid version is 
  received at the SG then SG responds with ERROR message containing 
  cause "Invalid Version" and diagnostic information filled with the 
  version the SG supports.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Also arrange the data in ASP such that ASPIA 
  message is sent with the version other than Release 1.0 protocol to 
  SG. Type field can be any valid value and fill the routing context 
  with any value.

EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is active 

   ASPIA   ---------------->
 Version = 2
           <---------------    ERROR
                            Cause = Invalid Version

TEST DESCRIPTION:
1. Send ASPIA message AS to SG containing version 2 in the common 
   header.
2. Check A: ERROR message is received at the ASP containing cause 
   Invalid Version.
3. Check B: Diagnostic Field Parameter in ERROR is filled with version 
   1.
4. Repeat the above test cases for other messages from AS to SG like 
   ASPAC, ASPUP, ASPDN, DAUD and DATA. In all these cases ERROR message
   will be received with the same cause.

Sunil-Prashant-Ashok, HSS                                 [Page  40]

Internet Draft          Test Specs for M3UA                 Feb 2001
      

"Invalid Traffic Handling Mode Error"

+ TEST NUMBER : 1.5.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1 and 4.3.3.4

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid Traffic Handling Mode Error

+ PURPOSE: To check that if ASPAC or ASPIA message is received with 
  Type parameter incompatible with the traffic handling mode currently 
  used in AS at SG, SG responds with ERROR message containing cause 
  "Invalid Traffic Handling Mode".

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP1 is Up. Arrange the data in ASP such that ASPAC 
  message is sent with Type field filled with Loadshare mode of Traffic
  handling. Traffic Handling Mode defined at SG for AS is Override.
  Fill value P in Routing context parameter.

EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is Inactive 

   ASPAC   ---------------->
 Type = Loadshare
           <---------------    ERROR
                            Cause = Invalid traffic Handling Mode

TEST DESCRIPTION:
1. Send ASPAC message from AS to SG containing Type field Loadshare. 
   Mode of Traffic handling for AS at SG is Override.
2. Check A: ERROR message is received at the ASP containing cause 
   Invalid Traffic Handling Mode.
3. Repeat the above test cases for other values of Type field with 
   Traffic Handling Mode for AS at SG being different from this Type 
   field.
4. Repeat the test case with Type field having value that is not 
   defined i.e any value greater than 0x03.
5. Repeat all the above tests for ASPIA message.

Sunil-Prashant-Ashok, HSS                                 [Page  41]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid Traffic Handling Mode Error if there are two ASP in one AS"

+ TEST NUMBER : 1.5.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1 and 4.3.3.4

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid Traffic Handling Mode Error if there are two ASP 
  in one AS

+ PURPOSE: To check that if ASPAC or ASPIA message is received with 
  Type parameter incompatible with the traffic handling mode currently 
  used in AS at SG, SG responds with ERROR message containing cause 
  "Invalid Traffic Handling Mode".

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP1 and ASP2 are Up. Arrange the data in ASP such that ASPAC
  message for ASP1 is sent with Type field filled with Override mode of
  Traffic handling and ASPAC message for ASP2 is sent with Type field 
  filled with Loadshare mode of Traffic handling. Traffic Handling Mode
  defined at SG for AS is Override Mode. Fill value P in Routing 
  context parameter.

EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is Inactive 
 ASPAC(ASP1)---------------->
 Type = Override               Status Ind ------->  

            <---------------  ASP-Active-Ack

 ASPAC(ASP2) ---------------->
 Type = Loadshare
             <---------------    ERROR
                            Cause = Invalid traffic Handling Mode
TEST DESCRIPTION:
1. Send ASPAC message from ASP1 to SG containing Type field Override. 
2. Check A: ASP-Active-Ack message is received at the ASP.
3. Send ASPAC message from ASP2 to SG containing Type field Loadshare.
4. Check B: ERROR message is received at the ASP containing cause 
   Invalid Traffic Handling Mode.
5. Repeat the above test cases for other values of Type field with 
   Traffic Handling Mode for AS at SG being different from this Type. 
6. Repeat the test case with Type field having value that is not 
   defined.
7. Repeat all the above tests for ASPIA message.

Sunil-Prashant-Ashok, HSS                                 [Page  42]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Unrecognized Message Type"

+ TEST NUMBER : 1.5.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1

+ TITLE : Invalid Message Handling

+ SUBTITLE : Unrecognized Message Type

+ PURPOSE: To check that if a message with message type not defined is 
  received at SG, SG responds with ERROR message containing cause 
  "Invalid Message Type".

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP1 is active. Arrange the data in ASP such that a message 
  with Message type not defined is sent to SG. Let the other parameters
  in the message be like any other message.

EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              ASP is Active 

   Message ---------------->
 Message Type=0408

           <---------------    ERROR
                            Cause = Invalid Message Type

   DATA    ---------------->
N/w Appearance A 
                               MTP-Transfer Ind ------->

TEST DESCRIPTION:
1. Send a message with message type 0408 or any other value which is 
   not defined from AS to SG 
2. Check A: ERROR message is received at the ASP containing cause 
   Invalid Message Type.
3. Check B: State of AS at SG is not disturbed.
4. Repeat the above test cases by sending DUNA, DAVA, DUPU, SCON 
   messages from AS which the SG is not expected to receive. In this 
   case Error will be reported to the SM and Message will be discarded.
 

 Prashant-Ashok, HSS                                       [Page  43]

Internet Draft          Test Specs for M3UA                 Feb 2001  

"Invalid Network Appearance"

+ TEST NUMBER : 1.5.5

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 3.3.1

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid Network Appearance

+ PURPOSE: To check that if a message with invalid network appearance 
  i.e. network appearance not defined at SG then SG responds with ERROR
  message containing cause "Invalid Network Appearance".

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data
  in AS such that DATA message with Network Appearance other than A is 
  sent to SG.

EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                 SM + NIF 
                              AS is Active 

   DATA    ---------------->
 N/w Appearance B

           <---------------    ERROR
                            Cause = Invalid N/w Appearance

   DATA    ---------------->
N/w Appearance A 
                               MTP-Transfer Ind ------->
TEST DESCRIPTION:
1. Send DATA message with network appearance B which is not defined at 
   SG. 
2. Check A: ERROR message containing cause Invalid Network Appearance 
   should be received at AS.
3. Check B: State of AS at SG is not disturbed. 
Note: Network Appearance parameter is optional. In some implementation 
      this parameter may not come in DATA message. In those 
      implementations, this test case need not be tested.

 Prashant-Ashok, HSS                                         [Page  44]

Internet Draft          Test Specs for M3UA                 Feb 2001          

"Invalid Reason parameter in ASPDN message"

+ TEST NUMBER : 1.5.6

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1 and 4.3.3.2

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid Reason Parameter in ASPDN message

+ PURPOSE: To check that if ASPDN message with Invalid Reason parameter
  is received then ASP Down Ack message is send back.

+ TEST CONFIGURATION:  A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is in Active state i.e. ASP1 is active. Arrange the data
  in ASP such that ASPDN message with Reason Parameter filled with 
  value 03 or more is sent to the SG.
  
 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                 SM + NIF 
                              ASP is Active 

   ASPDN    ---------------->
 Reason = 0x3                   Message is discarded
            <---------------  ASP-Down-Ack

            <---------------  NTFY (AS-Down)

           <---------------    Error 
                               (Unsupported Message Type)

TEST DESCRIPTION:
1. Send ASPDN message with Reason Parameter 0x3 from ASP to SG. 
2. Check A: The ASP-Down-Ack, NTFY (AS-Down) is send to ASP.
3. Also an error message with reason Unsupported Message Type is send
   to ASP to indicate that the reason parameter was invalid.
   

             

Sunil-Prashant-Ashok, HSS                                 [Page  45]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid routing context parameter in ASPAC message"

+ TEST NUMBER : 1.5.7

+ Reference: draft-ietf-sigtran-m3ua-05.txt 	Clause 3.5.7

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid routing context Parameter in ASPAC message

+ PURPOSE: To check that if ASPAC message with Invalid routing context 
  parameter is received then ASPAC message is discarded.

+ TEST CONFIGURATION:    A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Inactive state i.e. ASP1 is Inactive. Arrange the data 
  in AS such that ASPAC message with Routing Context P is sent  
  to the SG.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  NIF 
                              AS is Inactive 

   ASPAC    ---------------->
 Routing context Q

            <---------------    Error
                                ( Invalid Routing Context)

   ASPAC    ---------------->
 Routing context P and Q
                               Status Ind ---------> 

           <---------------    ASP-Active-Ack with routing context P

           <---------------    NTFY (AS-Active)

TEST DESCRIPTION:
1. Send ASPAC message with routing context Q. 
2. Check A: SG will send an Error message with Invalid Routing Context 
   parameter.
3. Send ASPAC message with routing context P and Q. 
4. Check B: ASP-Active-Ack and NTFY (AS-Active) message will be sent 
   for routing context P.  
Note: Routing context is an optional parameter in ASPAC message. In 
      some implementation this field may not come in ASPAC message. In 
      those implementation this test case need not be run.
Sunil-Prashant-Ashok, HSS                                 [Page  46]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid routing context parameter in ASPIA message"

+ TEST NUMBER : 1.5.8

+ Reference: draft-ietf-sigtran-m3ua-05.txt    Clause 3.5.7

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid routing context Parameter in ASPIA message

+ PURPOSE: To check that if ASPIA message with Invalid routing context 
  parameter is received then ASPIA message is discarded.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data
  in AS such that ASPIA message with Routing Context Q is sent to the 
  SG.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  NIF 
                              ASP is Active 

   ASPIA    ---------------->
 Routing context Q
            <---------------    Error
                                ( Invalid Routing Context)
   ASPIA    ---------------->
 Routing context P and Q
                               Status Ind ---------> 

           <---------------    ASP-Inactive-Ack with routing context P

           <---------------    NTFY(AS-Pending)

TEST DESCRIPTION:
1. Send ASPIA message with Routing Context Q. 
2. Check A: SG will send an Error message with Invalid Routing Context 
   parameter.
3. Send ASPIA message with routing context P and Q. 
4. Check B: ASP-Inactive-Ack and NTFY (AS-Pending) message will be sent
   with status AS-Pending for routing context P.  
Note: Routing context is an optional parameter in ASPIA message. In 
      some implementation this field may not come in ASPIA message. In
      those implementation this test case need not be run.

Sunil-Prashant-Ashok, HSS                                 [Page  47]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Message length less than the length of mandatory Parameters"

+ TEST NUMBER : 1.5.9

+ Reference: draft-ietf-sigtran-m3ua-05.txt 	Clause 3.5.7

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Message length less than the length of mandatory 
  parameters

+ PURPOSE: To check that if a message with value of length parameter 
  less than length of mandatory parameters is received then message is 
  discarded.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Active state. Arrange the data in AS such that 
  ASPIA message with length parameter filled with value less than the 
  length of type parameter is sent on stream 0.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  NIF 
                              AS is Active 

   ASPIA    ---------------->
 Message Length = 2

           <---------------    Error
                                ( Unsupported Message Type)

   DATA    ---------------->
 N/w appearance A
                                MTP-Transfer   ---------> 

TEST DESCRIPTION:
1. Send ASPIA message with length parameter filled with value less than
   the length of type field to the SG. 
2. Check A: SG will send an Error message with Unsupported Message Type
   parameter.
3. Check B: State of AS at SG is not disturbed.
4. Repeat the above test case for other messages like ASPAC, ERROR, 
   ASPDN.

Sunil-Prashant-Ashok, HSS                                 [Page  48]

Internet Draft          Test Specs for M3UA                 Feb 2001
                  
"ASPUP message in AS-Inactive state"

+ TEST NUMBER : 1.6.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.1

+ TITLE : Duplicate Message Handling 

+ SUBTITLE : ASPUP message in AS Inactive state

+ PURPOSE: To check that if ASPUP message is received in ASP-Inactive 
  state then message with ASP-Up-Ack is sent to the AS.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in 
  AS such that ASPUP message  is sent to the SG two times
  on stream 0.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is Down 

 ASPUP      ---------------->
                              Status Ind ------->  
            <---------------   ASP-Up-Ack

            <---------------   NTFY(AS-Inactive)

 ASPUP      ---------------->
                          
            <---------------   ASP-Up-Ack

 ASPAC       ---------------->
                               Status Ind ------->  
            <---------------   ASP-Active-Ack

            <---------------   NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPUP message to the SG in ASP-Down state. ASP-Up-Ack and
   NTFY (AS-Inactive) messages will come from the SG. Send ASPUP 
   message  again from the AS for the same ASP.
2. Check A: ASP-Up-Ack message should be received at AS.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in 
   the Inactive state. Send ASPAC message with valid Type and Routing 
   Context for the ASP1 and ASP-Active-Ack message should come.
Note: NTFY message with AS status may come before the NTFY message with
      ASP status.

Sunil-Prashant-Ashok, HSS                                 [Page  49]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPDN message in ASP-Down state"

+ TEST NUMBER : 1.6.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.2

+ TITLE : Duplicate Message Handling 

+ SUBTITLE : ASPDN message in ASP-Down  state

+ PURPOSE: To check that if ASPDN message is received in ASP-Down state
  then ASP-Down-Ack message is sent to the AS.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Inactive state i.e. ASP1 is Inactive. Arrange the data in 
  AS such that ASPDN message is sent to the SG two times with the valid
  Reason Parameter on stream 0.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is Inactive 
 ASPDN      ---------------->
                              Status Ind ------->  
            <---------------   ASP-Down-Ack

            <---------------   NTFY(AS-Down)

 ASPDN      ---------------->
                          
            <---------------   ASP-Down-Ack

 ASPUP       ---------------->
                               Status Ind ------->  

            <---------------   ASP-Up-Ack

            <---------------   NTFY(AS-Inactive)
TEST DESCRIPTION:
1. Send ASPDN message to the SG in ASP-Inactive state. ASP-Down-Ack and  
   NTFY (AS-Down) messages will come from the SG. Send ASPDN message 
   again from the AS for ASP1.
2. Check A: ASP-Down-Ack message should be received at AS.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
   Down state. Send ASPUP message for the ASP,ASP-Up-Ack and NTFY with  
   status AS-Inactive should come.
Note: NTFY message with AS status may come before the NTFY message with
     ASP status.
Sunil-Prashant-Ashok, HSS                                 [Page  50]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPAC message in ASP-Active state"

+ TEST NUMBER : 1.6.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4

+ TITLE : Duplicate Message Handling 

+ SUBTITLE : ASPAC message in ASP-Active  state

+ PURPOSE: To check that if ASPAC message is received in ASP-Active 
  state then ASP-Active-Ack message is sent to the AS.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Inactive state i.e. ASP1 is Inactive. Arrange the data 
  in AS such that ASPAC message with correct Type (Type is same as 
  defined at SG for the AS) and routing context P is sent to the SG 
  two times on stream 0.
 
 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is Inactive 

 ASPAC      ---------------->
                              Status Ind ------->  

            <---------------   ASP-Active-Ack

            <---------------    NTFY (AS-Active)
            
 ASPAC      ---------------->
                          
            <---------------   ASP-Active-Ack

 DATA        ---------------->
                               MTP-Transfer Ind ------->  

TEST DESCRIPTION:
1. Send ASPAC message to the SG in ASP-Inactive state. ASP-Active-Ack 
   and NTFY (AS-Active) message will come from the SG. 
2. Send ASPAC message again from the AS for the same ASP.
3. Check A: ASP-Active-Ack message should be received at ASP.
4. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
   Active state. Send DATA message for the ASP and SG should send
   MTP-Transfer indication to the NIF.

Sunil-Prashant-Ashok, HSS                                 [Page  51]

Internet Draft          Test Specs for M3UA                 Feb 2001

                   

"ASPIA message in ASP-Inactive state"

+ TEST NUMBER : 1.6.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5

+ TITLE : Duplicate Message Handling 

+ SUBTITLE : ASPIA message in ASP-Inactive state

+ PURPOSE: To check that if ASPIA message is received in ASP-Inactive
  state   then ASP-Inactive-Ack message is sent to the AS.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and AS is in AS-Active state i.e. AS1 is active. Arrange the data 
  in AS such that ASPIA message with correct Type(Type is same as 
  defined at SG for the AS) and Routing Context P is sent to the SG two
  times on stream 0.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              AS is Active 
 ASPIA      ---------------->
                              Status Ind ------->  

            <---------------   ASP-Inactive-Ack

            <---------------   NTFY(AS-Pending)

 ASPIA      ---------------->
                          
            <---------------   ASP-Inactive-Ack

 ASPAC      ---------------->
                              Status Ind ------->  

            <---------------   ASP-Active-Ack

            <---------------   NTFY(AS-Active)

Sunil-Prashant-Ashok, HSS                                 [Page 52]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPIA message to the SG in ASP-Active state. ASP-Inactive-Ack
   and  NTFY (AS-Pending) messages will come from the SG. 
2. Send ASPIA message again from the AS for the same ASP.
3. Check A: ASP-Inactive-Ack message will come from SG.
4. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
   Inactive state. Send ASPAC message with correct Type(Type is same as 
   defined at SG for the AS) for the ASP1 and SG should respond with 
   ASP-Active-Ack message.
Note: NTFY message with AS status may come before the NTFY message with
      ASP status.

Sunil-Prashant-Ashok, HSS                                 [Page  53]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPAC message in ASP-Down state"

+ TEST NUMBER : 1.6.5

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4

+ TITLE : Invalid Message Handling 

+ SUBTITLE : ASPAC message in ASP-Down state

+ PURPOSE: To check that if ASPAC message is received in ASP-Down 
  state then message is discarded and an Error message is returned back .

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is in ASP-Down state i.e. ASP1 is down. Arrange the data in 
  ASP such that ASPAC message with correct Type (Type is same as defined
  at SG for the AS) and routing context P is sent to the SG on stream 0.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG             SM + NIF 
                              ASP is Down 

 ASPAC      ---------------->

            <---------------   Error
                               ( Unexpected Message) 

 ASPUP      ---------------->
                                 Status Ind ------->
            <---------------   ASP-Up-Ack 

            <---------------   NTFY(AS-Inactive)

TEST DESCRIPTION:
1. Send ASPAC message to the SG in ASP-Down state. 
2. Check A: Error message with Unexpected Message should be received 
   at the ASP.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in 
   the Down state. Send ASPUP message for the ASP and SG should 
   respond with ASP-Up-Ack and NTFY message with status AS-Inactive.
4. Repeat the above test case for ASPIA message.
Note: NTFY message with AS status may come before the NTFY message 
   with ASP status.
 

Sunil-Prashant-Ashok, HSS                                 [Page 54]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPUP message in ASP-Active state"

+ TEST NUMBER : 1.6.6

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.1

+ TITLE : Invalid Message Handling 

+ SUBTITLE : ASPUP message in ASP-Active state

+ PURPOSE: To check that if ASPUP message is received in ASP-Active 
  state then ACK message is sent to AS and ASP 
  state is moved to ASP-up.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and ASP1 is Active. Arrange the data in AS such that ASPUP message
  is sent to the SG on stream 0.

 EXPECTED MESSAGE SEQUENCE :
  ASP                           SG             SM + NIF 
                              ASP is Active 

 ASPUP      ---------------->
                                 
            <---------------   Error
                               (Unexpected Message)
 ASPAC      ---------------->
                                 Status Ind ------->
            <---------------   ASP-Active-Ack 

            
TEST DESCRIPTION:
1. Send ASPUP message to the SG in ASP-Active state. 
2. Check A: An Error message with parameter Unexpected Message should
   be received at ASP.
3. Check B: State of ASP should not change. Send ASPAC message with 
   correct Type (Type is same as defined at SG for the AS) and routing 
   context P to the SG and SG should send ASP-Active-Ack.

                   

Sunil-Prashant-Ashok, HSS                                 [Page 55]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPDN message in ASP-Active state"

+ TEST NUMBER : 1.6.7

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.2

+ TITLE : Different Message Handling 

+ SUBTITLE : ASPDN message in ASP-Active state

+ PURPOSE: To check that if ASPDN message is received in ASP-Active 
  state then ASP-Down-Ack message is sent to AS and State 
  of ASP at SG becomes ASP-Down.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and ASP1 is Active. Arrange the data in AS such that ASPUP message
  with valid Reason parameter is sent to the SG on stream 0.

 EXPECTED MESSAGE SEQUENCE :
  ASP                           SG             SM + NIF 
                              ASP is Active 

 ASPDN      ---------------->
                                 Status Ind -------> 
            <---------------   ASP-Down-Ack 

            <---------------   NTFY(AS-Down)

 ASPUP      ---------------->
                                 Status Ind ------->
            <---------------   ASP-Up-Ack 

            <---------------   NTFY(AS-Inactive) 

TEST DESCRIPTION:
1. Send ASPDN message to the SG in ASP-Active state. 
2. Check A: ASP-Down-Ack and NTFY (AS-Down) message is received at ASP.
3. Check B: State of ASP should become Down. 
4. Send ASPUP message to the SG and SG should send ASP-Up-Ack and NTFY 
   message with Status ASP-Inactive.
 

                  

Sunil-Prashant-Ashok, HSS                                 [Page  56]

Internet Draft          Test Specs for M3UA                 Feb 2001

"DATA message from AS in ASP-Down state"

+ TEST NUMBER : 1.6.8

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 3.3.1

+ TITLE : Invalid Message Handling 

+ SUBTITLE : DATA message from AS in ASP-Down state

+ PURPOSE: To check that if DATA message is received in ASP-Down state 
  then it is discarded.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and ASP1 is Down. Arrange the data in AS such that DATA message 
  with N/w Appearance A is sent to the SG.

 EXPECTED MESSAGE SEQUENCE :
  ASP                           SG             SM + NIF 
                              ASP is Down 

 DATA       ---------------->
     
            <---------------   Error
                                (Unexpected Message)

 ASPUP      ---------------->
                                 Status Ind ------->
            <---------------   ASP-Up-Ack 

            <---------------   NTFY(AS-Inactive) 
 
TEST DESCRIPTION:
1. Send DATA message to the SG in ASP-Down state. 
2. Check A: DATA message should be discarded and an Error message 
   should be received at the ASP.
3. Check that state of SG is not disturbed. 
4. Send ASPUP message on stream 0 and SG should respond with ASP-Up-Ack
   and NTFY (AS-Inactive). 
  

                   

Sunil-Prashant-Ashok, HSS                                 [Page  57]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASPM message when SG has locked out the ASP for management reason"

+ TEST NUMBER : 1.7

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.1

+ TITLE : AS management

+ SUBTITLE : ASPM message when SG has locked out the ASP for management
  reason

+ PURPOSE: To check that if ASPM message is received when SG has locked
  out the ASP for managemet reason then NTFY message with status 
  ASP-Down is sent to AS .

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS and ASP may be in any state. Arrange the data in SG such that ASP 
  is locked out at the SG. Arrange the data in AS such that ASPM 
  messages with valid parameters are sent to the SG on stream 0.

 EXPECTED MESSAGE SEQUENCE :
  ASP                           SG             SM + NIF 
                              
                                  <----------  Lock-ASP 
                               
 ASPUP      ---------------->

            <---------------   ASP-Down-Ack 

TEST DESCRIPTION:
1. Lock out the ASP at the SG by sending primitive for locking ASP 
   from SM. 
2. Now send ASPUP message with valid parameters from ASP to SG.
2. Check A: ASP-Down-Ack message with reason " Management Blocking"
   is received at ASP.
3. Repeat the above test case for other ASPM messages like ASPAC, ASPIA
   and ASPDN messages from ASP to the SG with valid parameters. 
   Response should be same.

Sunil-Prashant-Ashok, HSS                                 [Page  58]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Message Routing based on DPC"

+ TEST NUMBER : 1.8.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.2.1

+ TITLE :  Message Routing 

+ SUBTITLE : Message Routing towards ASP

+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing 
  Protocol DATA to send to the AS then it is sent to the correct AS.

+ TEST CONFIGURATION: D

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  all ASP i.e. ASP1, ASP2 and ASP3 and all ASP are in Active state. 
  Also arrange the data in NIF at SG such that MTP-Transfer Indication 
  Primitives is sent to the AS with following parameter combination:
  Protocol Data and N/w Appearance A and DPC X
  Protocol Data and N/w Appearance A and DPC Y
  Protocol Data and N/w Appearance B and DPC Z

 EXPECTED MESSAGE SEQUENCE :
 AS1       AS2      AS3                   SG               NIF
                                     All AS are active
                                          <----------  MTP-Transfer Ind
                                                   N/w Appearance A     
                                                   DPC X  
  <----------------------------      DATA
    
                                          <----------  MTP-Transfer Ind
                                                   N/w Appearance A     
                                                   DPC Y  
              <----------------      DATA

                                          <---------- MTP-Transfer Ind
                                                   N/w Appearance B     
                                                   DPC Z  
                      <--------      DATA

TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in SG containing the
   Protocol Data with DPC X and N/w appearance A. 
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing
   Protocol Data with DPC Y and N/w appearance A.
4. Repeat the above test case for MTP-Transfer Ind primitive containing 
   Protocol Data with DPC Z and N/w appearance B.

Sunil-Prashant-Ashok, HSS                                 [Page  59]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Message Routing based on DPC+CIC"

+ TEST NUMBER : 1.8.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.2.1

+ TITLE :  Message Routing 

+ SUBTITLE : Message Routing based on DPC+CIC
 
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing
  Protocol DATA to send to the AS then it is sent to the correct AS.

+ TEST CONFIGURATION: E

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  all ASP i.e. ASP1 and ASP2 and all ASP are in Active state. Routing 
  context P consists of DPC X and CIC 1 to 31. Routing context Q 
  consists of DPC X and CIC 33 to 63. Also arrange the data in NIF at 
  SG such that MTP-Transfer Indication Primitives is sent to the AS  
  with the following parameter combination:
  Protocol Data with DPC X and CIC 3
  Protocol Data with DPC X and CIC 35

 EXPECTED MESSAGE SEQUENCE :
 AS1       AS2                           SG               NIF
                                     All AS are active
                                          <----------  MTP-Transfer Ind
                                                       DPC X CIC 3 
  <----------------------------      DATA
    
                                          <----------  MTP-Transfer Ind
                                                       DPC X CIC 35 
              <----------------      DATA
 

TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing 
   the Protocol Data with DPC X and CIC value 3.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing 
   Protocol Data with DPC X and CIC value 35. DATA message should be 
   received at AS2

Sunil-Prashant-Ashok, HSS                                 [Page  60]

Internet Draft          Test Specs for M3UA                 Feb 2001
               

"Message Routing based on DPC+SSN"

+ TEST NUMBER : 1.8.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.2.1

+ TITLE :  Message Routing 

+ SUBTITLE : Message Routing based on DPC+SSN
 
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing 
  Protocol DATA to send to the AS then it is sent to the correct AS.

+ TEST CONFIGURATION: E

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  all ASP i.e. ASP1and ASP2 and all ASP are in Active state. Routing 
  context P consists of DPC X and SSN S. Routing context Q consists of 
  DPC X and SSN T. Also arrange data in NIF at SG such that 
  MTP-Transfer Indication Primitives is sent to the AS with the 
  following parameter combination:
  Protocol Data with DPC X and SSN S
  Protocol Data with DPC X and SSN T

 EXPECTED MESSAGE SEQUENCE : 
 AS1       AS2                           SG               NIF
                                     All AS are active
                                          <----------  MTP-Transfer Ind
                                                       DPC X SSN S
  <----------------------------      DATA
    
                                          <----------  MTP-Transfer Ind
                                                       DPC X SSN T 
              <----------------      DATA  

TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing 
   the Protocol Data with DPC X and SSN value S.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing 
   Protocol Data with DPC X and SSN value T. DATA message should be 
   received at AS2

Sunil-Prashant-Ashok, HSS                                 [Page 61]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Message Routing based on DPC+SIO"

+ TEST NUMBER : 1.8.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.2.1

+ TITLE :  Message Routing 

+ SUBTITLE : Message Routing based on DPC+SIO

+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing 
  Protocol DATA to send to the AS then it is sent to the correct AS.

+ TEST CONFIGURATION: E

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  all ASP i.e. ASP1and ASP2 and all ASP are in Active state. Routing 
  context P consists of DPC X and SIO S. Routing context Q consists of 
  DPC X and SIO T. Also arrange the data in NIF at SG such that 
  MTP-Transfer Indication Primitives is sent to the AS with the 
  following parameter combination:
  Protocol Data with DPC X and SIO S
  Protocol Data with DPC X and SIO T

 EXPECTED MESSAGE SEQUENCE :
 AS1       AS2                           SG               NIF
                                     All AS are active
                                          <----------  MTP-Transfer Ind
                                                       DPC X SIO S
  <----------------------------      DATA
    
                                          <----------  MTP-Transfer Ind
                                                       DPC X SIO T 
              <----------------      DATA  
TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing 
   the Protocol Data with DPC X and SIO value S.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing 
   Protocol Data with DPC Y and SIO value T. DATA message should be 
   received at AS2

Sunil-Prashant-Ashok, HSS                                 [Page  62]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Routing for Data not matching any routing context"

+ TEST NUMBER : 1.8.5

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.2.1

+ TITLE :  Message Routing 

+ SUBTITLE : Routing for Data not matching any routing context 

+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing 
  Protocol DATA which does not match to any routing context then 
  default routing is given to this message. 

+ TEST CONFIGURATION: E

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1 and ASP2 and ASP and ASP2 are Active. Routing context P consists
  of DPC X and SSN S. Routing context Q consists of DPC X and SSN T. 
  Also arrange the data in NIF at SG such that MTP-Transfer Indication 
  Primitives is sent to the AS with DPC X and SSN other than S or T.

 EXPECTED MESSAGE SEQUENCE :
  ASP                           SG                 NIF + SM
                              AS is Active 
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & SSN <> S or T

                              Error  ind. ---------->  

TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing 
   the Protocol Data having DPC and SSN such that theu don't match any 
   routing key.
2. Check A: Error should be returned or some default routing will be 
   given to this message.
3. Repeat the above test case if routing context is defined based on 
   DPC+CIC. Send MTP-Transfer Ind from NIF containing protocol data 
   with DPC+CIC that doesn't match this routing key. Response will 
   be same as in the above case.
4. Repeat the above test case if routing context is defined based on 
   DPC+SIO. Send MTP-Transfer Ind from NIF containing protocol data 
   with DPC+SIO that doesn't match this routing key. Response 
   will be same as in the above case.
5. Repeat the above test case if routing context is defined based on 
   DPC. Send MTP-Transfer Ind from NIF containing protocol data with 
   DPC that doesn't match this routing key. Response will be same as 
   in the    above case.

Sunil-Prashant-Ashok, HSS                                 [Page  63]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Loadshare Mode of Traffic handling in ASPAC message"

+ TEST NUMBER : 1.9.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 5.1.3 and 4.3.3.4

+ TITLE : Mode of Traffic Handling by ASP in ASPAC message

+ SUBTITLE : Loadshare mode of Traffic Handling

+ PURPOSE: To check that if an ASPAC message is received with Type 
  field containing Loadshare mode then traffic is distributed between
  this ASP and all other active ASPs.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1 and ASP2. ASP1 is active. Arrange the DATA in AS such that it 
  sends ASPAC message for ASP2 with Loadshare mode and routing context 
  P on stream 0. Also mode of traffic handling for AS at SG is 
  Loadshare.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1 is Active 

 ASPAC(ASP2) ---------------->
 Loadshare Mode                 Status Ind ------->  
             <---------------   ASP-Active-Ack 

                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP1    <---------------   DATA

                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC T
 To ASP2    <---------------   DATA

 ASPIA(ASP1) ---------------->
                                 Status Ind ------->    
            <---------------   ASP-Inactive-Ack 
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP2    <---------------   DATA

                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC T
 To ASP2    <---------------   DATA

Sunil-Prashant-Ashok, HSS                                 [Page  64]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPAC message with Loadshare mode in type field and Routing 
   context P from AS to SG for ASP2. 
2. Check A: ASP-Active-Ack message should be received at AS.
3. Check B: Traffic should also go ASP2 which has sent the ASPAC. Check
   this by sending MTP-Transfer Ind from NIF at SG containing different 
   CIC values assuming traffic is load shared based on the CIC.
4. Send ASPIA message from ASP1 to the SG.
5. ASP1 will receive ASP-Inactive-Ack from SG. 
6. Check that all the traffic is now going to ASP2.
   

Sunil-Prashant-Ashok, HSS                                 [Page  65]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Loadshare (Standby) Mode of Traffic handling in ASPAC message"

+ TEST NUMBER : 1.9.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 5.1.3 and 4.3.3.4

+ TITLE : Mode of Traffic Handling by ASP in ASPAC message

+ SUBTITLE : Loadshare (Standby) mode of Traffic Handling

+ PURPOSE: To check that if an ASPAC message is received with Type 
  field containing Loadshare (Standby) mode then traffic is not started
  to the ASP until the remote peer determines that additional resources
  are needed.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. There are three ASPs in AS, ASP1, ASP2, ASP3. All are having SCTP 
  Associations with SG.ASP1 and ASP2 are active ASP3 is inactive. 
  Arrange the data in AS such that it sends ASPAC message with 
  Loadshare mode (Standby) for ASP3. Also mode of traffic
  Handling for AS at SG is also loadshare mode (Standbby).

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1&ASP2 are Active 

 ASPAC(ASP3) ---------------->
 Loadshare Mode (Standby)                Status Ind ------->  
             
 To ASP3     <---------------   ASP-Active-Ack (for ASP3)

                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP1     <---------------   DATA
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC T
 To ASP2     <---------------   DATA
 ASPIA(ASP1) ---------------->
                                 Status Ind ------->    
To ASP1     <---------------   ASP-Inactive-Ack (for ASP1)

                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP2    <---------------   DATA
                                    <-----------  MTP-Transfer Ind
 To ASP3    <---------------   DATA             DPC X & CIC T

Sunil-Prashant-Ashok, HSS                                 [Page  66]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPAC message with Loadshare mode (Standby) in type field from AS to SG               
   to SG. 
2. Check A: ASP-Active-Ack message should be received at AS.
3. Check B: All trafic should still go to ASP1 and ASP2 only.
4. Send ASPIA message from ASP1 to the SG.
5. ASP1 will receive ASP-Inactive-Ack from SG. 
6. Check that all the traffic is now going to ASP2 and ASP3 ( which has
   sent the ASPAC with loadshare mode (Standby).

Sunil-Prashant-Ashok, HSS                                 [Page  67]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Loadshare Mode of Traffic handling by ASP in ASPIA message"

+ TEST NUMBER : 1.9.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 5.1.3 and 4.3.3.4

+ TITLE : Mode of Traffic Handling 

+ SUBTITLE : Loadshare mode of Traffic Handling by ASP in ASPIA message

+ PURPOSE: To check that if an ASPIA message is received with Type 
  field containing Loadshare mode and no other active ASPs are 
  available then a NTFY (Insufficient ASPs) is sent to all 
  inactive ASPs.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1, ASP2 and ASP3. ASP1 and ASP2are active and ASP3 is active in 
  standby Mode and all are in loadshare mode of traffic handling. 
  Arrange the DATA in AS such that it sends ASPIA message for ASP2 with
  Loadshare mode and routing context P on stream 0. Also mode of 
  traffic handling for AS at SG is Loadshare.Data at SG is arranged in 
  such a way that a minimum of 2 ASPs are required for handling the 
  traffic for routing context P.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1&ASP2 are Active 

 ASPIA(ASP2) ---------------->
 Loadshare Mode                 Status Ind ------->  
 To ASP2    <---------------   ASP-Inactive-Ack 
                                     <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP2    <---------------   DATA
 To ASP3    <---------------   DATA
 
 ASPIA(ASP3) ---------------->
 Loadshare Mode                               Status Ind ------->    
 To ASP3    <---------------   ASP-Inactive-Ack 
 To ASPs    <---------------   NTFY (Insufficient ASPs)
                               with routinfg context P
 To ASP2    <---------------   DATA

Sunil-Prashant-Ashok, HSS                                 [Page  68]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPIA message with Loadshare mode in type field and Routing 
   context P from AS to SG for ASP2. 
2. Check A: ASP-Inactive-Ack message should be received at AS.
3. Check B: Traffic should go to ASP1 and ASP3 which has sent the ASPAC. 
   Check this by sending MTP-Transfer Ind from NIF at SG containing 
   different CIC values assuming traffic is load shared based on the 
   CIC.
4. Send ASPIA message with Loadshare mode in type field and Routing 
   context P from ASP3 to the SG.
5. ASP3 will receive ASP-Inactive-Ack from SG. 
6. Check that all the traffic is now going to ASP2.
7. Check NTFY (Insufficient ASPs) should be received at all the three 
   ASPs.

                                       

Sunil-Prashant-Ashok, HSS                                 [Page  69]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Over-ride Mode of Traffic handling"

+ TEST NUMBER : 1.9.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4

+ TITLE : Mode of Traffic Handling by ASP in ASPAC message

+ SUBTITLE : Over-ride mode of Traffic Handling

+ PURPOSE: To check that if an ASPAC message is received with Type 
  field containing over-ride mode then all traffic is sent to that ASP 
  which sent ASPAC message.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. ASP1 in AS is active. Arrange the DATA in AS such that it sends 
  ASPAC message with over-ride mode and routing context P for ASP2 on 
  stream 0. Also mode of traffic handling for AS at SG is also 
  override mode.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1 is Active 

 ASPAC(ASP2) ---------------->
 Override Mode                    Status Ind ------->  

                                     <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
                                            (Data is buffered and will
                                             be send to SG when ASP2 
                                             takes over.) 
 To ASP2     <---------------   ASP-Active-Ack 

 To ASP1     <---------------   NTFY(Alternate ASP-Active)
 
 To ASP2     <---------------   DATA 
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP2     <---------------   DATA

                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC T
 To ASP2    <---------------   DATA 

Sunil-Prashant-Ashok, HSS                                 [Page  70]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASPAC message with override mode in type field and Routing 
   context P from AS to SG for ASP2. 
2. Check A: ASP2 will receive ASP-Active-Ack from SG.
3. NTFY message with status Alternate ASP-Active should be received at 
   ASP1.
4. Check B: All traffic should go to ASP2 which has sent the ASPAC. 
   Check this by sending MTP-Transfer Ind from NIF at SG.

Sunil-Prashant-Ashok, HSS                                 [Page  71]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Over-ride Mode of Traffic handling"

+ TEST NUMBER : 1.9.5

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4

+ TITLE : Mode of Traffic Handling by ASP in ASPAC message

+ SUBTITLE : To check if ASP receives data during Over-ride mode of 
  Traffic Handling changeover.

+ PURPOSE: To check that if an ASPreceives data during the changeover 
  of ASPs in Override modeof traffic handling. 

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. ASP1 in AS is active. Arrange the data in AS such that it sends 
  ASPAC message with over-ride mode and routing context P for ASP2 on 
  stream 0 and ASP1 receives the DATA before it receives NTFY message.
  
 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1 is Active 

 ASPAC(ASP2) ---------------->
 Override Mode                    Status Ind ------->
 DATA        ---------------->   (Data is buffered and will 
                                 be passed on when ASP2 
                                 becomes active.) 
 
 To ASP2     <---------------   ASP-Active-Ack 

 To ASP1     <---------------   NTFY(Alternate ASP-Active)

                                DATA     ----------->
 DATA         ---------------->
 (From ASP2)                    DATA     ----------->

                                    
TEST DESCRIPTION:
1. Send ASPAC message with override mode in type field and Routing 
   context P from AS to SG for ASP2. 
2. Send DATA from ASP1 to SG before receiving Ack message.
3. Check A: The data is buffered at SG.
4. ASP2 receives ASP-Active-Ack and ASP1 receives a NTFY message with 
   status as Alternate ASP Active.
5 Check B: The data buffered at SG is passed further.And now it will 
  receive data from ASP2.
Sunil-Prashant-Ashok, HSS                                 [Page 72]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Over-ride Mode of Traffic handling"

+ TEST NUMBER : 1.9.6

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4

+ TITLE : Mode of Traffic Handling by ASP in ASPAC message

+ SUBTITLE : No NTFY message to the ASP whose status is not changed in 
  Over-ride mode of Traffic Handling

+ PURPOSE: To check that if an ASPAC message is received with Type 
  field containing over-ride mode then NTFY Altenate ASP Active is send 
  to that ASP only whose traffic is going to be handled by the sending
  ASP. All traffic is sent to that ASP which sent ASPAC message.
  
+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. ASP1 and ASP2 are active and handling the traffic for routing 
  context P and Q, ASP3 is Inactive. Now send the ASPAC with traffic 
  handling mode as override for routing context P on stream 0. Also the
  mode of traffic handling for AS at SG is also override mode. 
    
 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1 and ASP2 are Active 
                                      <-----------  MTP-Transfer Ind
                                                  Routing Context P
 To ASP1     <---------------   DATA

                                    <-----------  MTP-Transfer Ind
                                                  Routing Context Q
 To ASP2    <---------------   DATA 

 ASPAC(ASP3) ---------------->
 Routing Context P
 Override Mode                    Status Ind ------->  
 To ASP3     <---------------   ASP-Active-Ack

 To ASP1     <---------------   NTFY(Alternate ASP-Active)

                                    <-----------  MTP-Transfer Ind
                                                  Routing Context P
 To ASP3     <---------------   DATA

                                    <-----------  MTP-Transfer Ind
                                                  Routing Context Q
 To ASP2    <---------------   DATA 

Sunil-Prashant-Ashok, HSS                                 [Page 73]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send data with routing context as P and Q to ASP, ASP1 and ASP2 will
   receive the data respectively. 
2. Send ASPAC for ASP3 with routing context P and traffic handling mode
   as override.
3. Check A: ASP3 will receive ASP Active Ack and NTFY message with 
   status Alternate ASP-Active should be received by ASP1.
3. Send data with routing context as P and Q to ASP, ASP3 and ASP2 will
   receive the data respectively. 
4. Check B: NTFY message with status Alternate ASP-Active is not  
   received by ASP2.

Sunil-Prashant-Ashok, HSS                                 [Page  74]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Over-ride (Standby) Mode of Traffic handling"

+ TEST NUMBER : 1.9.7
+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4

+ TITLE : Mode of Traffic Handling by ASP in ASPAC message

+ SUBTITLE : Over-ride (Standby) mode of Traffic Handling

+ PURPOSE: To check that if an ASPAC message is received with Type 
  field containing over-ride (Standby) mode then all traffic is sent to
  that ASP which sent ASPAC message after all the previously active ASP
  transitions to inactive or down .

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS. ASP1 in AS is active. Arrange the DATA in AS such that it sends 
  ASPAC message with over-ride mode (Standby) and routing context P for 
  ASP2 on stream 0. Also mode of traffic handling for AS at SG is also 
  override mode (Standby).

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                              ASP1 is Active 
 a)ASPAC(ASP2) ---------------->
 Override Mode (Standby)                    Status Ind ------->  
 To ASP2     <---------------   ASP-Active-Ack (for ASP2)
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP1    <---------------   DATA
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC T
 To ASP1    <---------------   DATA 
b)ASPIA(ASP1) ---------------->
                                 Status Ind ------->    
 To ASP1    <---------------   ASP-Inactive-Ack (for ASP1)
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP2    <---------------   DATA
TEST DESCRIPTION:
1. Send ASPAC message with override mode (Standby) in type field and 
   Routing context P from AS to SG for ASP2. 
2. Check A: ASP2 will receive ASP-Active-Ack from SG.
3. Check B: All traffic should still go to ASP1.
4. Send ASPIA message from AS to SG for ASP1.
5. Check B: All traffic should go to ASP2 which has sent the ASPAC with
   override mode (standby). 
   Check this by sending MTP-Transfer Ind from NIF at SG.

Sunil-Prashant-Ashok, HSS                                 [Page  75]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Loadshare Mode of Traffic handling in ASPIA message"

+ TEST NUMBER : 1.10

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.5

+ TITLE : Mode of Traffic Handling by ASP in ASPIA message

+ SUBTITLE : Loadshare mode of Traffic Handling

+ PURPOSE: To check that if an ASPIA message is received with Type 
  field containing Loadshare mode then all traffic is sent to other 
  ASP.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1 and ASP2. ASP1 and ASP2 in AS are active and are in loadshare 
  mode of traffic handling. Arrange the DATA in AS such that it sends 
  ASPIA message with Loadshare mode and routing context P for ASP1 on 
  stream 0. Also mode of traffic handling for AS at SG is Loadshare.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                            ASP1 & ASP2 are Active 

 ASPIA(ASP2) ---------------->
 (Mode=Loadshare)         Status Ind ------->  
 To ASP2     <---------------   ASP-Inactive-Ack 
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC S
 To ASP1    <---------------   DATA
                                    <-----------  MTP-Transfer Ind
                                                  DPC X & CIC T
 To ASP1    <---------------   DATA

TEST DESCRIPTION:
1. Send ASPIA message with Loadshare mode in type field and Routing 
   context P from ASP1 to SG. 
2. Check A: SG should send ASP-Inactive-Ack message.
3. Check B: All traffic should go to ASP1. Check this by sending 
   MTP-Transfer Ind from NIF at SG with Protocol Data containing 
   different SLS values.

Sunil-Prashant-Ashok, HSS                                 [Page  76]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ERROR Message Handling"

+ TEST NUMBER : 1.11

+ Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1

+ TITLE : ERROR

+ SUBTITLE : Handling of Received Error

+ PURPOSE: To check that if an error is received then that is reported 
  to the SM and no action is taken against that.

+ TEST CONFIGURATION:   A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1. ASP1 is active. Arrange data in AS such that ERROR with cause 
  invalid version is sent to the SG.

 EXPECTED MESSAGE SEQUENCE :
 ASP                           SG                  SM + NIF 
                            ASP is Active 

 ERROR       ---------------->
 cause=Invalid version
                                   Error     ------->   

TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from ASP to SG. 
2. Check A: Error should be reported to the SM.
3. Check B: Further action at the SG are implementation dependent. 
   SM may tear down the connection or no action may be taken.
4. Repeat the test case for other cause values in ERROR message.

Sunil-Prashant-Ashok, HSS                                 [Page 77]

Internet Draft          Test Specs for M3UA                 Feb 2001

"SCTP Connection Establishment"

+ TEST NUMBER : 1.12.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.2

+ TITLE :  SCTP Connection Management

+ SUBTITLE : SCTP Connection Establishment

+ PURPOSE: To check that on receiving Communication Up primitive from
  SCTP, SG M3UA will send M-SCTP-Establish indication to the SM.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is not established between SG
  and ASP1. Also arrange the data in AS such that SCTP association is
  established between ASP1 and SG.

 EXPECTED MESSAGE SEQUENCE :
 ASP                                   SG                   SM 
 
 SCTP Establish request to SCTP          
       SCTP association will be established by SCTP    
                SG will receive Communication-Up primitive from SCTP
 
                                M-SCTP-Establish Ind ------->
 
 ASPUP   ------------------>
                                 Status Ind --------->
 
         <-----------------    ASP-Up-Ack
                                                 
         <-----------------    NTFY(AS-Inactive)

TEST DESCRIPTION:
1. Make an SCTP association between ASP1 and SG. SG will receive 
   Communication Up primitive from SCTP.
2. Check A:SM receives M-SCTP-Establish indication.
3. Send ASPUP message from AS to SG
4. Check B: ASP-Up-Ack and NTFY message with status ASP-Inactive should
   be received.
  

                

Sunil-Prashant-Ashok, HSS                                 [Page  78]

Internet Draft          Test Specs for M3UA                 Feb 2001

"SCTP Connection Termination"

+ TEST NUMBER : 1.12.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.2

+ TITLE :  SCTP Connection Management

+ SUBTITLE : SCTP Connection Termination

+ PURPOSE: To check that on receiving SCTP-Communication Down 
  indication primitive from SCTP, AS will send the M-SCTP Status 
  primitive to the upper layer.

+ TEST CONFIGURATION: A

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  ASP1. Arrange for terminating the SCTP association between ASP1 and
  SG.

 EXPECTED MESSAGE SEQUENCE :
 ASP                             SG              SM + NIF 
                                ASP is active

 ASPDN      ------------->          

                                 Status Ind --------->
 
         <-----------------    ASP-Down-Ack
                                                 
         <-----------------    NTFY(AS-Down)
         SCTP association is terminated 

             SG will receive Communication-Down primitive from SCTP     
 
                                M-SCTP Status -------->

                                      <--------     MTP-Transfer  
                                Send Failure --------->    

TEST DESCRIPTION:
1. Terminate the association between SG and AS. 
2. Check A: SCTP association will be down and on receiving 
   Communication Down primitive from SCTP, M-SCTP Status indication 
   will be received at SM.
3. Check B: State of AS will be down at the SG. Send MTP-Transfer 
   primitive from the NIF to send some Protocol DATA. SG will report 
   send failure.

Sunil-Prashant-Ashok, HSS                                 [Page  79]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Last ASP in a SPMC becomes Inactive" 

+ TEST NUMBER : 1.13.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.3.2

+ TITLE : SPMC Management

+ SUBTITLE : Last ASP in a SPMC goes down

+ PURPOSE: To check that if last ASP in a SPMC becomes inactive then 
  SG gives NIF the MTP-Pause indication.

+ TEST CONFIGURATION: C

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1 and ASP2. ASP1 and ASP2 in AS are active. Arrange the DATA in AS
  such that ASPIA message is sent from ASP to SG for ASP1 and ASP2
  on stream 0. 

 EXPECTED MESSAGE SEQUENCE :
 AS                            SG                  SM + NIF 
                            ASP1 & ASP2 are Active 

 ASPIA(ASP1) ---------------->
                                 Status Ind ------->  
 To ASP1     <---------------   ASP-Inactive-Ack 

 ASPIA(ASP2) ---------------->
                                 Status Ind ------->   
 To ASP2     <---------------   ASP-Inactive-Ack 

 To AS       <---------------   NTFY(AS-Pending) 

                                MTP-Pause -------->

TEST DESCRIPTION:
1. Send ASPIA and message for ASP1 and ASP2 from AS to SG.
2. ASP Inactive Ack and NTFY (AS-Pending) messages are received at AS.
3. Check A: SG should send MTP-Pause indication to the NIF when last 
   ASP goes down.
4. Repeat the above test case if SG and ASP are having the same point 
   code.

Sunil-Prashant-Ashok, HSS                                 [Page  80]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Last ASP serving a specific DPC+SIO becomes Inactive " 

+ TEST NUMBER : 1.13.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.3.2

+ TITLE : SPMC Management

+ SUBTITLE : Last ASP serving a specific DPC+SIO becomes Inactive

+ PURPOSE: To check that if last ASP which is serving a specific 
  DPC + SIO goes down then SG gives NIF the Status indication with 
  user part unavailable.

+ TEST CONFIGURATION: F

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP1, ASP2 and ASP3. All ASP are active. Arrange the DATA in AS1 and
  AS2 such that if ASPIA message are sent from ASP to SG for 
  ASP1 and ASP2 on stream 0. 

 EXPECTED MESSAGE SEQUENCE :
 AS                            SG                  SM + NIF 
                            ASP1 & ASP2 are Active 

 ASPIA(ASP1) ---------------->
                                 Status Ind ------->
 To ASP1     <---------------   ASP-Inactive-Ack 

 ASPIA(ASP2) ---------------->
                                 Status Ind -------> 
 To ASP2     <---------------   ASP-Inactive-Ack 

 To AS       <---------------   NTFY(AS-Pending) 

                                   Status Ind -------->
                               (user part unavailable)
TEST DESCRIPTION:
1. Send ASPIA and ASPDN messages for ASP1 and ASP2 from AS to SG.
2. Check A: SG should send Status indication to the NIF when last ASP
   goes down.
3. Repeat the above test case if ASP3 goes down

               

Sunil-Prashant-Ashok, HSS                                 [Page 81]

Internet Draft          Test Specs for M3UA                 Feb 2001

4.2 Test Cases for Testing M3UA at AS

These test cases are used to test the M3UA at AS.

"Send and Receive of MTP-Transfer Primitive in AS Active State"

+ TEST NUMBER : 2.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.3.1 and 1.6

+ TITLE :  MTP-Transfer Primitive

+ SUBTITLE : Send and Receive of MTP-Transfer Primitive

+ PURPOSE: To check that on receiving MTP-Transfer primitive from SU, 
  DATA message is sent to the SG.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  ASP. ASP is in ASP-Active state. Also arrange the data in ASP such 
  that SU send MTP-Transfer primitive to M3UA with N/w Appearance A.

 EXPECTED MESSAGE SEQUENCE :
    SG                              ASP              SU
                                  ASP is Active
a) 
                                      <-----------  MTP-Transfer
               <-------------       DATA            N/w appearance A

b)

      DATA      -------------->
                                   MTP-Transfer --------->

TEST DESCRIPTION:
1. Send MTP-Transfer Request Primitive from the SU at ASP to send 
   Protocol Data to the SG. 
2. Check A: DATA message is received at AS containing the data passed
   by the SU and the Network Appearance.
3. Send DATA message from SG containing Protocol Data and N/w 
   Appearance A to the ASP.
4. Check B: MTP-Transfer primitive is received at SU with the Protocol 
   Data and N/w Appearance.
5. Repeat the test step 3 if DATA message is sent without N/w 
   appearance parameter. Response should be same as in 4.
Note: In some implementation, N/w appearance parameter may not be 
      there in the DATA message sent from ASP to SG.

Sunil-Prashant-Ashok, HSS                                 [Page  82]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Stream Selection "

+ TEST NUMBER : 2.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.7

+ TITLE : Stream Selection

+ SUBTITLE : Stream Selection 

+ PURPOSE: To check that all the messages for the same call are sent 
  on the same SCTP stream.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  ASP with two or more streams. ASP is active. Also arrange the data in
  ASP such that SU sends three or more MTP-Transfer indication 
  primitive to M3UA containing the same CIC value and N/w Appearance A.

 EXPECTED MESSAGE SEQUENCE : 
    SG                               ASP             SU
                                     AS is active
                                       <---------   MTP-Transfer
Check Stream id  <-------------      DATA           Data with CIC X  

                                       <---------   MTP-Transfer
Check Stream id  <-------------      DATA           Data with CIC X

                                       <---------   MTP-Transfer
Check Stream id  <-------------      DATA           Data with CIC X

TEST DESCRIPTION:
1. Send three or more MTP-Transfer Request Primitive from the SU at SG 
   side to send Protocol Data to the AS. In the Protocol Data CIC 
   values should be same in all MTP-Transfer Request primitive. It is 
   assumed that load sharing across the streams is CIC based.
2. Check A: DATA messages are sent to the SG containing the same 
   Stream Sequence number.
3. Repeat the above test with same SLS value in Protocol Data in all 
   MTP-Transfer Request primitives assuming load sharing across the 
   streams is SLS based.
4. Repeat the above test case with different CIC values and different 
   SLS values. DATA messages should be sent on different streams.
Note: How the messages will be distributed on different streams based 
      on CIC and SLS is implementation dependent.

Sunil-Prashant-Ashok, HSS                                 [Page  83]

Internet Draft          Test Specs for M3UA                 Feb 2001

"SCTP Connection Establishment"

+ TEST NUMBER : 2.3.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.2

+ TITLE :  SCTP Connection Management

+ SUBTITLE : SCTP Connection Establishment

+ PURPOSE: To check that on receiving M-SCTP-Establish primitive from
  SM, ASP initiates and establishes an SCTP association with the SG.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is not established between SG
  and ASP. Also arrange the data in ASP such that SM sends 
  M-SCTP-Establish primitive to M3UA with the SG id to which the 
  connection is to be established.

EXPECTED MESSAGE SEQUENCE :
 SG                          ASP                SU + SM
                             
                              <---------     M-SCTP-Establish Request
      <------------------->
  SCTP association will be established by SCTP

                AS will receive Communication-Up primitive from SCTP 
                            
                              M-SCTP-Establish Ind------->
  

TEST DESCRIPTION:
1. Send M-SCTP-Establish Request Primitive from the SM at ASP side to
   establish an SCTP association with the SG. 
2. Check A: SCTP association will be established and M-SCTP-Establish
   indication will be received at the SM.

                 

Sunil-Prashant-Ashok, HSS                                 [Page  84]

Internet Draft          Test Specs for M3UA                 Feb 2001

"SCTP Connection Termination"

+ TEST NUMBER : 2.3.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.2

+ TITLE :  SCTP Connection Management

+ SUBTITLE : SCTP Connection Termination

+ PURPOSE: To check that on receiving SCTP-Communication Down 
  indication primitive from SCTP, ASP will send the M-SCTP Status 
  primitive to the upper layer.
 
+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and
  ASP. ASP is in active state. Also arrange the data in SG such that
  SCTP association is terminated between SG and AS.

 EXPECTED MESSAGE SEQUENCE :
 SG                                ASP              SM + SU 
                                   ASP is active

                 <-------------    ASPDN          

 ASP-Down-Ack  -------------->    

 NTFY(AS-Down)  -------------->       

       SCTP association is terminated 

          ASP will receive Communication-Down primitive from SCTP     
 
                                M-SCTP Status -------->

                                      <--------     MTP-Transfer  

                                Send Failure --------->    
TEST DESCRIPTION:
1. Terminate the association between SG and ASP. 
2. Check A: SCTP association will be down and on receiving 
   Communication Down primitive from SCTP, M-SCTP Status indication
   will be received at the SM.
3. Check B: State of ASP will be down. Send MTP-Transfer primitive from
   the SU to send some Protocol DATA. ASP will report send failure.
Note: It may be possible that SCTP connection is terminated without 
      exchanging the ASPDN message. 

Sunil-Prashant-Ashok, HSS                                 [Page  85]

Internet Draft          Test Specs for M3UA                 Feb 2001
             

"NTFY message is not received in response to ASPUP message"

+ TEST NUMBER : 2.4.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.1

+ TITLE :  AS management

+ SUBTITLE : ASP-Up-Ack is not received in response to ASPUP message 

+ PURPOSE: To check that if Ack message is not received in response to
  the ASPUP message then ASP keeps on sending ASPUP message at an 
  interval for some time and after some tries will report the SM.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. Also arrange the data in ASP such that SM sends ASP Up primitive
  to the M3UA. Arrange data in SG such that Ack message  
  is not sent in response to the ASPUP message.

EXPECTED MESSAGE SEQUENCE :
 SG                            ASP                    SM 

                                   <-----------     ASP-Up
       <------------          ASPUP
            |
            |time t1 
       <------------          ASPUP
            |
            |time t1 
       <------------          ASPUP
                                                              .
                               . n tries
                               .
                               Status Ind ----------> 

TEST DESCRIPTION:
1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message to
   the SG. Don't send Ack message from the SG.
2. Check A: ASPUP message will be retransmitted to the SG.
3. Check B: Note the time for which ASPUP will be retransmitted.
4. Repeat the above test case for ASPDN message i.e. Ack message is 
   not sent in response to ASPDN message.
Note: This case is implementation specific. In some implementation 
      there may not be any retransmission. Also the time for which it 
      will be retransmitted is implementation specific.

Sunil-Prashant-Ashok, HSS                                 [Page  86]

Internet Draft          Test Specs for M3UA                 Feb 2001
 

" ASP-Down-Ack message is received in response to ASPUP message"

+ TEST NUMBER : 2.4.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.1

+ TITLE :  AS management

+ SUBTITLE : ASP-Down-Ack is received in response to ASPUP message 

+ PURPOSE: To check that if ASP-Down-Ack message is received in 
  response to the ASPUP message then SG sends ASPUP message again.
    
+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. Also arrange the data in ASP such that SM sends ASP Up primitive
  to the M3UA. Arrange data in SG such that ASP-Down-Ack message  is
  sent in response to the ASPUP message on stream 0.

 EXPECTED MESSAGE SEQUENCE :
 SG                            ASP                    SM

                                   <-----------     ASP-Up
                <------------  ASPUP

 ASP-Down-Ack ------------>

                <------------  ASPUP

TEST DESCRIPTION:
1. Send ASP-Up primitive from SM at ASP. 
2. ASP will send ASPUP message to the SG. 
3. Send ASP-Down-Ack message from the SG.
4. Check A: ASPUP message will be retransmitted to the SG.

Note: This case is implementation specific it may be in Stack or 
      at the SM. In some implementation there may not be any 
      retransmission. 

                

Sunil-Prashant-Ashok, HSS                                 [Page  87]

Internet Draft          Test Specs for M3UA                 Feb 2001

"ASP Management messages towards SG"

+ TEST NUMBER : 2.4.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.5

+ TITLE :  AS management

+ SUBTITLE : ASP Management messages towards SG

+ PURPOSE: To check that if SM sends primitive to send ASP management 
  messages to the SG then the corresponding message is sent to the SG.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP is active. Also arrange the data in ASP such that SM sends 
  different ASP status primitive to the ASP with valid parameters.

 EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                     SM 
 
                                      <--------- ASP-Inactive
              <-----------    ASPIA

 ASP-Inactive-Ack  ------------>

 NTFY (AS-Inactive)  ------------>
                            Status Ind --------->
                                         <--------- ASP-Down  
              <-----------    ASPDN

 ASP-Down-Ack  ------------>

 NTFY (AS-Down)  ------------>
                           Status Ind  --------->
                                      <---------  ASP-Up
              <-----------    ASPUP

 ASP-Up-Ack   ------------>
 NTFY (AS-Inactive)  ------------>
                            Status Ind --------->
                                       <--------- ASP-Active
                 <-----------    ASPAC

 ASP-Active-Ack  ------------>
 NTFY (AS-Active)  ------------>
                            Status Ind --------->

Sunil-Prashant-Ashok, HSS                                 [Page  88]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send ASP-Inactive Primitive from SM in ASP to M3UA.
2. Check A: ASPIA message will be received at the SG.
3. Send ASP-Inactive-Ack and NTFY(AS-Inactive) in response to the ASPIA
   message on stream 0.
4. Check B: ASPM messages are sent on strem 0.
5. Repeat the test case for other primitives like ASP-Down, ASP-Up, and
   ASP-Active . ASPDN, ASPUP and ASPAC messages will be sent from 
   ASP to SG with parameters passed from SM.    
6. Repeat the above test case if Ack messages are sent on stream other 
   than 0.

Sunil-Prashant-Ashok, HSS                                 [Page  89]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid Version Error"

+ TEST NUMBER : 2.5.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1

+ TITLE :  Invalid Message Handling

+ SUBTITLE : Invalid Version Error

+ PURPOSE: To check that if any message with Invalid version is 
  received at the ASP then ASP responds with ERROR message containing 
  cause "Invalid Version" and diagnostic information filled with the 
  version the SG supports.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Also arrange the data in SG such that DUNA 
  message is sent on stream 0 with the version other than Release 1.0 
  protocol to the ASP. N/w appearance parameters in the DUNA message 
  should be A and affected DPC can be having any DPC.

 EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                        SM 
                                ASP is active 
  DUNA      --------------->
 Version = 2

            <--------------     ERROR
                               Cause = Invalid Version

TEST DESCRIPTION:
1. Send DUNA message from SG to ASP containing version 2 in the common 
   header.
2. Check A: ERROR message containing cause Invalid Version will be 
   received at SG.
3. Check B: Diagnostic Parameter in ERROR is filled with version 1.
4. Repeat the above test cases for other messages from SG to ASP like 
   DAVA, SCON, DUPU, NTFY and DATA.

Sunil-Prashant-Ashok, HSS                                 [Page  90]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Unrecognised Message Type"

+ TEST NUMBER : 2.5.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1

+ TITLE : Invalid Message Handling

+ SUBTITLE : Unrecognized Message Type

+ PURPOSE: To check that if a message with message type not defined is 
  received at AS, AS responds with ERROR message containing cause 
  "Invalid Message Type".

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Arrange the data in SG such that a message 
  with Message type not defined is sent to ASP. Let the other 
  parameters in the message be like any other message.

 EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                        SM 
                                ASP is active
  Message   --------------->
 Message Type = 0408

            <--------------     ERROR
                               Cause = Invalid Message Type
  
  DATA      --------------->
  N/w Appearance A
                                 MTP-Transfer Ind --------->

TEST DESCRIPTION:
1. Send a message with message type 0408 or any other value which is 
   not defined from SG to ASP. 
2. Check A: ERROR message containing cause Invalid Message Type will be
   received at the SG.
3. Check B: State of ASP is not disturbed.

Sunil-Prashant-Ashok, HSS                                 [Page  91]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid Network Appearance"

+ TEST NUMBER : 2.5.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid Network Appearance

+ PURPOSE: To check that if a message with invalid network appearance 
  i.e. ASP does not handle traffic for that network appearance then AS 
  responds with ERROR message containing cause "Invalid Network 
  Appearance".

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Arrange the data in SG such that DATA message 
  with invalid value of Network Appearance is sent to ASP.

 EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                        SM 
                                ASP is active
  DATA      --------------->
 N/w appearance B

            <--------------     ERROR
                               Cause = Invalid Network Appearance
  
  DATA      --------------->
  N/w Appearance A
                                 MTP-Transfer Ind --------->

TEST DESCRIPTION:
1. Send DATA message to the ASP with network appearance which ASP 
   doesn't handle. 
2. Check A: AS will respond with ERROR message containing cause Invalid
   Network Appearance.
3. Check B: State of ASP at AS is not disturbed.
4. Repeat the above test case for other messages like DUNA, DAVA, DUPU
   and SCON.

                   
Sunil-Prashant-Ashok, HSS                                 [Page  92]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid Congestion Level in SCON message"

+ TEST NUMBER : 2.5.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt	Clause 3.4.4

+ TITLE : Invalid Message Handling 

+ SUBTITLE: Invalid congestion level in SCON message.

+ PURPOSE: To check that if SCON message with Invalid congestion level 
  parameter is received then it is reported to the upper layer.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is active. Arrange the data in SG such that SCON message
  with congestion level with value 4 or more is sent to the ASP. In 
  N/w Appearance parameter in SCON message, fill value A and for 
  affected DPC fill any value.

 EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                        SM 
                                ASP is active 
  SCON      --------------->
 Congestion Level 4
            <--------------     ERROR
                               Cause = Invalid Message Type

                                   Error Ind --------> 
  
  DATA      --------------->
  N/w Appearance A
                                 MTP-Transfer Ind --------->
 
TEST DESCRIPTION:
1. Send SCON message with congestion Level 4. 
2. Check A: AS will pass the information in the SCON message to the SU
   via Status Indication Primitive.
3. Check B: State of ASP is not disturbed.

              
Sunil-Prashant-Ashok, HSS                                 [Page  93]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Invalid Cause parameter in DUPU message"

+ TEST NUMBER : 2.5.5

+ Reference: draft-ietf-sigtran-m3ua-05.txt 	Clause 3.4.5

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Invalid Cause parameter in DUPU message

+ PURPOSE: To check that if DUPU message with Invalid cause parameter 
  is received then error will be reported to SM.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Arrange the data in SG such that DUPU message 
  with invalid value of cause parameter is sent to ASP. In N/w 
  Appearance parameter fill value A and affected destination parameter 
  fill any value. In the user parameter fill any valid value.

 EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                        SM 
                                ASP is active 
  DUPU      --------------->
 Cause 03
            <--------------     ERROR
                                Cause = Invalid Message Type

                                      Error   --------> 
  
  DATA      --------------->
  N/w Appearance A
                                 MTP-Transfer Ind --------->
TEST DESCRIPTION:
1. Send DUPU message from the SG with cause value 03 or more to the ASP.
2. Check A: AS will take no action and will report error to the SM.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for invalid value of User parameter in 
   DUPU message(11 or more).

                 
Sunil-Prashant-Ashok, HSS                                 [Page  94]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Message length less than the length of mandatory Parameters"

+ TEST NUMBER : 2.5.6

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.5.1

+ TITLE : Invalid Message Handling 

+ SUBTITLE : Message length less than length of mandatory parameters

+ PURPOSE: To check that if a message with value of length parameter 
  less than length of mandatory parameters is received then message is 
  discarded.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  AS, and AS is Down. Arrange the data in SG such that NTFY message 
  with length parameter filled with value less than the length 
  of Status Type and Status Identificatin field.
  
 EXPECTED MESSAGE SEQUENCE :
  SG                              ASP                SM 
 
                                  <---------       ASP-Up
              <-----------    ASPUP

 ASP-Up-Ack         ------------>

 NTFY (AS-Inactive) ------------>
                                    Error -------> 
              <-----------    ASPUP

TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to the M3UA at the ASP. ASPUP message 
   will be sent to the SG.
2. Send ASP-Up-Ack and NTFY message with length field less than the 
   length of Status Type and Status Identification field.
3. Check A: ASP will take no action and will discard the NTFY message.
4. Check B: ASPUP message will be sent again.

                  
Sunil-Prashant-Ashok, HSS                                 [Page  95]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Reception of SSNM messages"

+ TEST NUMBER : 2.6.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.2

+ TITLE :  SSNM Message handling

+ SUBTITLE: Reception of SSNM messages

+ PURPOSE: To check that if SSNM message is received at the ASP then it
  is reported to the ULP.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Also arrange the data in SG such that DUNA, 
  DAVA, DUPU and SCON messages are sent from the SG to the ASP with 
  valid parameters and they are sent on stream number 0.

EXPECTED MESSAGE SEQUENCE :
 SG                              ASP                        SM 
                                ASP is active
a)
  DUNA      --------------->
                                  MTP-Pause Ind  --------> 

b)
  DAVA      --------------->
                                  MTP-Resume Ind  --------> 

c)
  SCON      --------------->
                                  MTP-Status Ind  --------> 

d)
  DUPU      --------------->
                                  MTP-Status Ind  --------> 
TEST DESCRIPTION:
1. Send DUNA message from SG to ASP containing the Network Appearance A
   and Affected DPC any value.
2. Check A: MTP-Pause indication primitive will be received at the SU. 
3. Repeat the above test case for other messages like DAVA, SCON and 
   DUPU messages.
4. Repeat the above test case for one affected DPC and for more than 
   one affected DPC parameters.
5. Repeat the above test cases if all these messages are sent on stream
   number other than zero. They should be accepted.
Note: Depending upon the number of affected destinations there may be 
      more than one MTP-Pause, MTP-resume and Status Indication.
Sunil-Prashant-Ashok, HSS                                 [Page  96]

Internet Draft          Test Specs for M3UA                 Feb 2001

+ TEST NUMBER : 2.6.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.4.2

+ TITLE :  SSNM Message handling

+ SUBTITLE: Reception of SSNM messages

+ PURPOSE: To check that if SSNM message is received at the ASP from 
  different SGs then it is reported to the ULP.
  
+ TEST CONFIGURATION: J

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Active. Also arrange the data in SG such that DUNA, 
  DAVA, DUPU and SCON messages are sent from the SG to the ASP with 
  valid parameters and they are sent on stream number 0.

EXPECTED MESSAGE SEQUENCE :
        SG1      SG2              ASP                        SM 
                                ASP is active
a)
  DUNA    -------------------------->
  (for Routing Context P                Status Ind  --------> 
    at SG1)
b)
  DUNA    -------------------------->

                   ----------------->
  (for routing Context P
   at SG1 and SG2)             MTP-Pause Ind  -------->

c)
  DUNA             ----------------->
  (for Routing Context Q)
                               MTP-Pause Ind  -------->

d)
  DAVA    -------------------------->
  (for Routing Context P                Status Ind  --------> 
    at SG1)
e)
  DAVA    -------------------------->

                   ----------------->
  (for routing Context P
   at SG1 and SG2)             MTP-Resume Ind  -------->

Sunil-Prashant-Ashok, HSS                                 [Page  97]

Internet Draft          Test Specs for M3UA                 Feb 2001

f)
  DAVA             ----------------->
  (for Routing Context Q)
                               MTP-Resume Ind  -------->
TEST DESCRIPTION:
1. Send DUNA message from SG1 to ASP for the Routing Context P.
2. Check A: Status indication primitive will be received at the SU.
3. Send DUNA from SG1 and SG2 to ASP for routing Context P.
4. Check B: MTP Pause indication will be received at SU. 
5. Send DUNA message from SG2 to ASP for the Routing Context Q.
6. Check C: MTP Pause indication will be received at SU. 
7. Repeat the above test case for other messages like DAVA, SCON and 
   DUPU messages.
8. Repeat the above test cases if all these messages are sent on stream
   number other than zero. They should be accepted.
Note: Depending upon the number of affected destinations there may be 
      more than one MTP-Pause, MTP-resume and Status Indication.

Sunil-Prashant-Ashok, HSS                                 [Page  98]

Internet Draft          Test Specs for M3UA                 Feb 2001
     

"DAUD message is not sent if SCON message is received with congestion 
 level 0 or undefined"

+ TEST NUMBER : 2.6.3

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.3

+ TITLE :  SSNM Message Handling

+ SUBTITLE : DAUD message is not sent if SCON message is received with 
  congestion level 0 or undefined

+ PURPOSE: To check that if SCON message is received with congestion 
  level 0 or undefined then DAUD message is not sent on expiry of the 
  timer.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is active. Also arrange the data in SG such that SCON 
  message with congestion level 0 is sent to the ASP. Network 
  Appearance parameter should be having value A and affected DPC can be
  having any value.

EXPECTED MESSAGE SEQUENCE :
 SG                               ASP                     SU 
                                  ASP is active 
 SCON(Level 1) --------------->
                      |            MTP-Status Ind  -------->
                      |
                      |Timer expires
               <---------------    DAUD
                      | 
                      |
                      |Timer expires
               <---------------    DAUD

 SCON(Level 0) --------------->
                      | 
                      |
                      |Timer expires
               <---------------    DAUD is not sent

Sunil-Prashant-Ashok, HSS                                 [Page  99]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send SCON message from the SG to the ASP. Don't send any other SSNM
   message from the SG. Timer will be started at the ASP on receiving 
   SCON message.
2. Check A: DAUD message should be received at the SG after expiry of
   the timer.  
3. Repeat the above test case if SCON message is sent with Scon level 0.
4. Check B: No DAUD message should be received at the SG after expiry 
   of the timer.     
Note: Value of the timer is implementation specific.

Sunil-Prashant-Ashok, HSS                                 [Page 100]

Internet Draft          Test Specs for M3UA                 Feb 2001
          

"Timer which started on receiving DUNA message is reset on issuing DAUD
 message"

+ TEST NUMBER : 2.6.4

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.3

+ TITLE :  SSNM Message Handling

+ SUBTITLE : Timer which started on receiving DUNA message is reset on 
  issuing DAUD message

+ PURPOSE: To check that timer which started on receiving DUNA message 
  from the SG is reset on issuing DAUD message from the ASP.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is active. Also arrange the data in SG such that DUNA 
  message is sent to the AS with Network appearance A and affected DPC 
  any value. 

 EXPECTED MESSAGE SEQUENCE :
 SG                               ASP                     SU 
                                  ASP is active 
 DUNA          --------------->
                      |              MTP-Pause -------->
                      |
                      |Timer expires
               <---------------    DAUD
                      | 
                      |
                      |Timer expires
               <---------------    DAUD 

TEST DESCRIPTION:
1. Send DUNA message from the SG to the ASP. Don't send any other SSNM
   message from the SG. Timer will be started at the AS on receiving 
   DUNA message.
2. Check A: DAUD message containing the network Appearance A and 
   Affected DPC will be received at SG after expiry of the timer. 
3. Check C: DAUD message is received on the Stream number 0.
4. Check D: Timer is started again after issuing DAUD message.
5. Repeat the above test case if DUNA message is sent without N/w 
   Appearance parameter. Response should be same.
6. Repeat the above test case if in place of DUNA message SCON message 
   with congestion level 1 or 2 or 3 is sent 
Note: Value of the timer is implementation specific.

Sunil-Prashant-Ashok, HSS                                 [Page 101]

Internet Draft          Test Specs for M3UA                 Feb 2001
                   

"Timer which started on receiving DUNA message is reset on receiving 
 another DUNA message"

+ TEST NUMBER : 2.6.5

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.3

+ TITLE :  SSNM Message Handling

+ SUBTITLE : Timer which started on receiving DUNA message is reset on 
  receiving another DUNA message

+ PURPOSE: To check that timer which started on receiving DUNA message 
  from the SG is reset on receiving another DUNA message from the SG.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is active. Also arrange the data in SG such that DUNA 
  message is sent to the ASP with Network appearance A and affected DPC
  two times on stream 0. First time it is sent with DPC X and second 
  time it is sent with DPC Y. ASP is handling traffic for both DPC X 
  and Y. 

 EXPECTED MESSAGE SEQUENCE :
 SG                               ASP                     SU 
                                  ASP is active 
 DUNA(DPC = X)  --------------->
                      |Timer starts   MTP-Pause -------->
                      |            
                      |
 DUNA(DPC = Y)  ------|--------->    Timer is reset   
                   |  |              MTP-Pause -------->
                   |  |Timer expires 
                   |           No DAUD is sent
                   |
                   |Timer expires
                <---------------     DAUD 

Sunil-Prashant-Ashok, HSS                                 [Page 102]

Internet Draft          Test Specs for M3UA                 Feb 2001

TEST DESCRIPTION:
1. Send DUNA message with affected DPC X from the SG to the ASP. Timer 
   will be started at the AS on receiving DUNA message. Send another 
   DUNA message for DPC Y to the ASP before expiry of the timer.
2. Check A: Timer will be reset on receiving DUNA message and DAUD 
   message is received at the SG after expiry of the timer.
3. Check C: DAUD message is received on the Stream number 0.
4. Check D: Timer is started again after issuing DAUD message.
5. Repeat the above test case if DUNA message is sent both times with 
   same DPC and also DUNA message contains both the DPC.
6. Repeat the above test case if instead of sending DUNA second time, 
   SCON is sent with congestion level 1 or 2 or 3 and affected DPC X or
   Y.
Note: It is assumed that timer is not DPC specific i.e. for every DPC a
      new timer is not started. It is SG specific.

Sunil-Prashant-Ashok, HSS                                 [Page 103]

Internet Draft          Test Specs for M3UA                 Feb 2001

"Timer which started on receiving DUNA message is stopped on receiving 
 DAVA message"

+ TEST NUMBER : 2.6.6

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.4.3

+ TITLE :  SSNM Message Handling

+ SUBTITLE : Timer which started on receiving DUNA message is stopped 
  on receiving another DUNA message

+ PURPOSE: To check that timer which started on receiving DUNA message 
  from the SG is stopped on receiving DAVA message from the SG.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is active. Also arrange the data in SG such that DUNA 
  message is sent to the ASP with Network appearance A and affected 
  DPC on stream 0. After DUNA message DAVA message is sent to the ASP 
  on stream 0.
  

 EXPECTED MESSAGE SEQUENCE :
  SG                               ASP                     SU 
                                  ASP is active 
 DUNA           --------------->
                      |Timer starts   MTP-Pause -------->
                      |            
                      |
 DAVA           ------|--------->    Timer is stopped   
                   |  |              MTP-Resume -------->
                   |  |Timer expires 
                   |                No DAUD is sent
                   |
                   |Timer expires
                                    No DAUD is sent

TEST DESCRIPTION:
1. Send DUNA message with affected DPC X from the SG to the ASP. Timer 
   will be started at the ASP on receiving DUNA message. Send another 
   DAVA message for DPC X to the ASP before expiry of the timer.
2. Check A: Timer will be stopped on receiving DAVA message and DAUD 
   message is not sent to the SG after expiry of the timer.
Note: It is assumed that timer is not DPC specific i.e. for every DPC a
      new timer is not started. it is SG specific.

Sunil-Prashant-Ashok, HSS                                 [Page 104]

Internet Draft          Test Specs for M3UA                 Feb 2001
               

"ASP-Down-Ack is received in response to ASPDN message"

+ TEST NUMBER : 2.7.1

+ Reference: draft-ietf-sigtran-m3ua-05.txt   Clause 4.3.3.2

+ TITLE : Invalid Message Handling 

+ SUBTITLE : ASP-Up-Ack is received in response to ASPDN message

+ PURPOSE: To check that if ASP-Up-Ack message is received in 
  response to the ASPDN then the Ack message is discarded and ASPDN is
  sent again.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is Up. Arrange data in SG such that ASP-Up-Ack is sent
  to ASP in response to ASPDN message with routing context P on stream 
  0.

 EXPECTED MESSAGE SEQUENCE :
   SG                              ASP                SM 
                                   ASP is Inactive
                                  <---------       ASP-Down
              <-----------    ASPDN

ASP-Up-Ack  ------------>
            
              <-----------    ASPDN

TEST DESCRIPTION:
1. Send ASP-Down Primitive to the ASP. ASPDN message will be sent to 
   the SG. 
2. Send ASP-Up-Ack message in response to the ASPDN message.
3. Check A: ASPDN message is received again at the SG.
4. Repeat the above test case if Ack message is sent.  
   

                  

Sunil-Prashant-Ashok, HSS                                 [Page 105]

Internet Draft          Test Specs for M3UA                 Feb 2001

"NTFY(ASP-Active) is received in response to ASPIA message"

+ TEST NUMBER : 2.7.2

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.5

+ TITLE : Invalid Message Handling 

+ SUBTITLE : ASP-Active-Ack is received in response to ASPIA message

+ PURPOSE: To check that if ASP-Active-Ack message is received in 
  response to the ASPIA then the Ack message is discarded and ASPIA is
  sent again.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP and ASP is active. Arrange the data in SG such that  
  ASP-Active-Ack with routing context P is sent to ASP in response to 
  ASPIA message on stream 0.

 EXPECTED MESSAGE SEQUENCE :
   SG                              ASP                SM 
                                   ASP is active
                                  <---------       ASP-Inactive
                  <-----------    ASPIA

  ASP-Active-Ack  ------------>
            
                  <-----------    ASPIA 
  
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive to the AS. ASPIA message will be sent to
   the SG.
2. Send ASP-Active-Act message in response to the ASPIA message.
3. Check A: ASPIA message is received again at the SG.
4. Repeat the above test case if ASP-Up-Ack is received in 
   response to the ASPIA message.

Sunil-Prashant-Ashok, HSS                                 [Page 106]

Internet Draft          Test Specs for M3UA                 Feb 2001
                

"ERROR Handling"

+ TEST NUMBER : 2.8

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 3.6.1

+ TITLE : ERROR

+ SUBTITLE : Handling of Received Error

+ PURPOSE: To check that if an error is received then that is reported 
  to the SM and no action is taken against that.

+ TEST CONFIGURATION: G

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP is in active state at the SG. Arrange data in SG such that 
  ERROR with cause invalid version is sent to the AS.

 EXPECTED MESSAGE SEQUENCE :
  SG                               ASP                     SU 
                                  ASP is active 
                                              <-------    ASP-Up  
            <---------------      ASPUP            
 
 ERROR       --------------->
Cause = invalid version              Error    -------->

TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from SG to AS. 
2. Check A: AS should report the error to its SM.
3. Check B: Further action at the SG are implementation dependent. 
4. Repeat the test case for other cause values in ERROR message.

Sunil-Prashant-Ashok, HSS                                 [Page 107]

Internet Draft          Test Specs for M3UA                 Feb 2001
                

"ASP in more than one AS"

+ TEST NUMBER : 2.9

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 4.3.3.4 and 4.3.3.5

+ TITLE : ASP configuration

+ SUBTITLE : ASP configured to handle traffic for more than one AS

+ PURPOSE: To check that if an ASP has been configured to handle 
  traffic for more than one AS then in ASPAC and ASPIA message more 
  than one routing context are sent.

+ TEST CONFIGURATION: I

+ PRE-TEST CONDITIONS: SCTP association is established between SG and 
  ASP. ASP has been configured to handle traffic for routing context P 
  and Q. ASP is Down. Arrange data in ASP such that ASP-Active is sent 
  from SM with the list of AS or routing context ASP is configured for.

 EXPECTED MESSAGE SEQUENCE :
  SG                               ASP                     SU 
                                  ASP is Down 
                                              <-------    ASP-Up  
                 <---------------   ASPUP            

 ASP-Up-Ack      --------------->

 NTFY (AS-Inactive)      --------------->
                                              <-------    ASP-Active  
                 <---------------   ASPAC(Routing context P and Q)

 ASP-Active-Ack --------------->

 NTFY(AS-Active)      --------------->
                                              <-------    ASP-Inactive
                 <---------------   ASPIA(Routing context P and Q)

TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to ASP. ASPUP message will be sent 
   from ASP to SG. Send ASP-Up-Ack and NTFY (ASP-Inactive) from the SG.
2 Now send ASP-Active primitive from SM. 
3. Check A: ASPAC message is received at the SG containing both the 
   routing context P and Q.
4. Repeat the above test case for ASP-Inactive primitive from SM. ASPIA
   message should be sent to SG containing both the routing contexts.
Note: Some implementation may take the AS 

Sunil-Prashant-Ashok, HSS                                 [Page 108]

Internet Draft          Test Specs for M3UA                 Feb 2001
            

"SG in Primary/Backup case"

+ TEST NUMBER : 2.10

+ Reference: draft-ietf-sigtran-m3ua-05.txt  Clause 1.4.4.2

+ TITLE : SG Redundancy

+ SUBTITLE : SG in Primary/Backup case

+ PURPOSE: To check that if an ASP is connected to the two SG, SG1 and 
  SG2 both configured to handle traffic for the same DPC but in 
  primary/backup mode and having same PC and SCTP association between 
  ASP and SG1 is down then ASP diverts all traffic towards SG2.

+ TEST CONFIGURATION: H

+ PRE-TEST CONDITIONS: ASP is having SCTP association with SG1 and SG2.
  Both SG1 and SG2 are handling traffic for the same PC. SG1 is the 
  primary SG and SG2 is the backup SG. Arrange to disconnect the SCTP 
  association between ASP and SG1. Let SG1 is the primary SG.

 EXPECTED MESSAGE SEQUENCE :
  SG1       SG2                   ASP                     SM + SU 
                                  ASP is Down 
                                            <------- ASP-Up(for SG1)
   <--------------------------    ASPUP
   ASP-Up-Ack --------------->

   NTFY(AS-Inactive) ----------->
                                            <------- ASP-Up(for SG2)
             <----------------    ASPUP

  ASP-Up-Ack --------------->

  NTFY(AS-Inactive) ----------->

                                            <------- ASP-Active(for SG1)
   <--------------------------    ASPAC

ASP-Active-Ack --------------->

NTFY(AS-Active) ----------->

Sunil-Prashant-Ashok, HSS                                 [Page 109]

Internet Draft          Test Specs for M3UA                 Feb 2001

                                            <------- ASP-Active(for SG2)
             <----------------    ASPAC

ASP-Active-Ack --------------->

NTFY(AS-Active) ----------->

                                              <-------    MTP-Transfer  
   <---------------------------   DATA

                                              <-------    MTP-Transfer  
   <---------------------------   DATA

       SCTP association between SG1 and ASP is down
                                      Status  --------->

                                              <-------    MTP-Transfer  
               <---------------   DATA

                                              <-------    MTP-Transfer  
               <---------------   DATA

TEST DESCRIPTION:
1. Send MTP-Transfer primitive containing protocol Data from SU at ASP. 
   DATA message will be sent to the SG. Send MTP-Transfer primitive 
   with Protocol Data with different SLS values. 
2. Check A: All DATA messages are received at SG1.
3. Terminate the SCTP association between ASP and SG1. 
4. Check B: All traffic is being received at SG2.
5. Check that if SCTP association between SG1 and ASP is restored then 
   all traffic is received at SG1.

Sunil-Prashant-Ashok, HSS                                 [Page 110]

Internet Draft          Test Specs for M3UA                 Feb 2001

5. Acknowledgement

Authors are greatful to Harsh and all the members of VoIP-Stacks group
members at  Hughes  Software  Systems . Authors  are  thankful to  all
the members of SIGTRAN mailing  list  who have floated  their comments
on  the  drafts  of  SCTP ,  making  it  more  transparent  for better
understanding.

6. Authors Address

Sunil, Prashant ,Ashok  
email:  hsssigtran@hss.hns.com
		                        
                             

Hughes Software Systems
Plot#31, Sector 18
Electronic City 
Gurgaon, Haryana
INDIA - 122015

Tel# +91-124-6346666 , 6455 5555
Fax# +91-124- 634 6530

7. References

[1] G. Sidebottom, L. Ong, Guy Mousseau, Ian Rytina, Hanns-Juergen 
    Schwarzbauer, Ken Morneault, Mallesh Kalla
    SS7 MTP3-User Adaptation Layer (M3UA)
    <draft-ietf-sigtran-m3ua-05.txt>
 

Sunil-Prashant-Ashok, HSS                                 [Page 111]



Last modified: Thu, 13 Nov 2014 05:43:48 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.