OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Fri, 28 Nov 2008 10:52:01 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-bhola-conformance-test-iua-01
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-bhola-conformance-test-iua-01

Description: Request For Comments

You can download source copies of the file as follows:

draft-bhola-conformance-test-iua-01.txt in text format.

Listed below is the contents of file draft-bhola-conformance-test-iua-01.txt.



Network Working Group					   Vikas Bhola
INTERNET-DRAFT						Gayatri Singla       
					       Hughes Software Systems

Expires in 6 months                                      17th Dec,2002
                                   

                 Conformance Test Specification for IUA
                <draft-bhola-conformance-test-iua-01.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.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress'.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This Internet Draft presents a test specification for RFC 3057 which 
defines the ISDN Q.921-User Adaptation protocol along with 
IUA Outstanding Issues <draft-ietf-sigtran-iua-imp-guide-02.txt>.
This test specification can be used to test IUA implementations for
conformance to the IUA protocol definition.

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

Vikas & Gayatri	                                               [Page 1]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Table of contents
=================

1.	Introduction
1.1	Terminology

2.	Test Setup 
2.1	 Test Environment
2.1.1      Simulated Test Setup
2.2	 Various Configurations for the Test Suite	   
2.2.1	   Various test Configurations at SG side 	 
2.2.2	   Various test Configurations at ASP side 	 

3. 	Test Scenarios
3.1	 ASPM Messages
3.1.1      Valid ASPM cases when ASP is Under Test
3.1.1.1.....ASPM_V_ASP_01 ASP Up and Active State Transition flow
3.1.1.2.....ASPM_V_ASP_02 ASP Inactive and Down State Transition flow
3.1.1.3.....ASPM_V_ASP_03 ASPUP Procedures when two ASPs are in two AS
3.1.1.4.....ASPM_V_ASP_04 ASP ACTIVE Procedures when two ASP's are 
			   in two AS
3.1.1.5.....ASPM_V_ASP_05 ASPUP Procedures when two ASPs are in one AS
3.1.1.6.....ASPM_V_ASP_06 ASPAC Procedures when two ASPs are in one AS
3.1.1.7.....ASPM_V_ASP_07 ASPAC Procedures when one ASP is in two AS
3.1.1.8.....ASPM_V_ASP_08 Heartbeat Procedures
3.1.1.9.....ASPM_V_ASP_09 Heartbeat Message Generation
3.1.1.10....ASPM_V_ASP_10 Text Based Interface identifiers in AS 
3.1.1.11....ASPM_V_ASP_11 Routing Verification when Two ASP's are
	                   in two different AS(Text+Integer)
3.1.2      Invalid ASPM cases when ASP is Under Test
3.1.2.1.....ASPM_I_ASP_01 ASPM Message received in wrong state of ASP
3.1.2.2.....ASPM_I_ASP_02 ASPDN ACK in Active state of ASP
3.1.2.3.....ASPM_I_ASP_03 ASPSM Timer expiry Cases
3.1.2.4.....ASPM_I_ASP_04 ASPTM Timer expiry Cases
3.1.2.5.....ASPM_I_ASP_05 ASPIA ACK in response to ASPAC
3.1.2.6.....ASPM_I_ASP_06 Association re-establishment in case of
			  Heartbeat timer expiry
3.1.3      Valid ASPM cases when SG is Under Test
3.1.3.1.....ASPM_V_SG_01 AS Inactive/Active State Transition in single
			  ASP-SG scenario.
3.1.3.2.....ASPM_V_SG_02 AS Inactive and Down State Transition, in
			  single ASP-SG scenario.
3.1.3.3.....ASPM_V_SG_03 Handling of the AS State Transition from
			  Active to DOWN, in single ASP-SG scenario.
3.1.3.4.....ASPM_V_SG_04 ASPUP procedures when one ASP is in two AS
3.1.3.5.....ASPM_V_SG_05 ASPAC procedures when one ASP is in two AS
3.1.3.6.....ASPM_V_SG_06 ASPUP procedures when two ASP's are in two AS
3.1.3.7.....ASPM_V_SG_07 ASPAC procedures when two ASP's are in two AS
3.1.3.8.....ASPM_V_SG_08 ASUP procedures when Two ASP's are in one AS
3.1.3.9.....ASPM_V_SG_09 ASP ACTIVE procedures when two ASP's are in
			    one AS(Override)
Vikas & Gayatri	                                               [Page 2]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

3.1.3.10....ASPM_V_SG_10 Text Based Interface identifiers in AS 
3.1.3.11....ASPM_V_SG_11 Routing Verification when Two ASP's are
			  in two different AS(Text+Integer)
3.1.3.12....ASPM_V_SG_12 Loadshare procedures
3.1.3.13....ASPM_V_SG_13 Notify-Insufficient Resources
3.1.3.14....ASPM_V_SG_14 AS-Active again before pending timer expires
3.1.3.15....ASPM_V_SG_15 Heartbeat Procedures
3.1.3.16....ASPM_V_SG_16 Optional parameter handling
3.1.3.17....ASPM_V_SG_17 ASPAC/ASPIA message handling when it contains
			  no interface identifier
3.1.4      Invalid ASPM cases when SG is Under Test
3.1.4.1.....ASPM_I_SG_01 Retransmitted ASPSM Message received 
3.1.4.2.....ASPM_I_SG_02 Retransmitted ASPTM Message received 
3.1.4.3.....ASPM_I_SG_03 ASPUP message handling in ACTIVE state of ASP
3.1.4.4.....ASPM_I_SG_04 ASPAC message handling in DOWN state of ASP
3.1.4.5.....ASPM_I_SG_05 Traffic Mode Parameter Missing in ASPAC
3.2      QPTM Messages
3.2.1      Valid QPTM cases when ASP is Under Test
3.2.1.1.....QPTM_V_ASP_01 Link Establishment Procedures
3.2.1.2.....QPTM_V_ASP_02 Link Release Request/Confirm Procedures
3.2.1.3.....QPTM_V_ASP_03 Link Release/Establish Indication Procedures
3.2.1.4.....QPTM_V_ASP_04 Unitdata Procedures
3.2.2      Valid QPTM cases when SG is Under Test
3.2.2.1.....QPTM_V_SG_01 Link Establishment Procedures
3.2.2.2.....QPTM_V_SG_02 Link Release Request/Confirm Procedures
3.2.2.3.....QPTM_V_SG_03 Link Release/Establish Indication Procedures
3.2.2.4.....QPTM_V_SG_04 Unitdata Procedures
3.2.2.5.....QPTM_V_SG_05 Mapping Interface Identifier within multiple 
	                  Associations/Streams
3.3      MGMT Messages
3.3.1      MGMT cases when ASP is Under Test
3.3.1.1.....MGMT_V_ASP_01 TEI Status Request/Confirm Procedures
3.3.1.2.....MGMT_V_ASP_02 TEI Status Query/Indication Procedures
3.3.2      MGMT cases when SG is Under Test
3.3.2.1.....MGMT_V_SG_01 TEI Status Request/Confirm Procedures
3.3.2.2.....MGMT_V_SG_02 TEI Status Query/Indication Procedures
3.3.3      Invalid scenario handling when SG is under test
3.3.3.1.....MGMT_I_SG_01 Invalid Version Error
3.3.3.2.....MGMT_I_SG_02 Invalid Interface identifier
3.3.3.3.....MGMT_I_SG_03 Unsupported Message Class/Type
3.3.3.4.....MGMT_I_SG_04 Unsupported Traffic Handling mode
3.3.3.5.....MGMT_I_SG_05 Unexpected Message
3.3.3.6.....MGMT_I_SG_06 Invalid Stream Identifier
3.3.3.7.....MGMT_I_SG_07 Unsupported Interface Identifier Type
3.3.3.8.....MGMT_I_SG_08 Refused - Management Blocking
3.4      ASP Identifier Cases
3.4.1      ASP Identifier Valid Cases
3.4.1.1.....ASPI_V_ASP_01 ASP Identifier Based Routing
3.4.2      ASP Identifier Invalid Cases
3.4.2.1.....ASPI_I_SG_01 ASP Identifier Required
3.4.2.2.....ASPI_I_SG_02 Invalid ASP Identifier
3.5      Miscellaneous Cases
3.5.1      MISC cases when SG is Under Test
3.5.1.1.....MISC_V_SG_01 SCTP Restart Handling

Vikas & Gayatri	                                               [Page 3]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

3.5.1.2.....MISC_V_SG_02 SCTP Comm-lost Handling
3.5.1.3.....MISC_V_SG_03 Establishing SCTP Association from SG
3.5.1.4.....MISC_V_SG_04 Payload Protocol id as 1
3.5.2      MISC cases when ASP is Under Test
3.5.2.1.....MISC_V_ASP_01 Multiple SG Scenario

4        Acknowledgements

5	 References

6	 Authors' Address

 
1. Introduction

IUA is a protocol used for backhauling of ISDN Q.921 User messages
over IP using the Stream Control Transmission Protocol (SCTP).  
This Draft presents a test specification for RFC 3057 which defines
the ISDN Q.921-User Adaptation protocol along with IUA Outstanding
Issues <draft-ietf-sigtran-iua-imp-guide-02.txt>.

1.1 Terminology

IUT - IUT refers to the Implementation Under Test.
	It refers to IUA stack(Configured as SG or ASP)

Peer - It refers to the peer simulator(Simulating SG or ASP)

For rest of standard terminology please refer Section 1.2 of 
rfc3057.

2. TEST SETUP
   ==========

2.1	Test Environment

2.1.1	Simulated Test Setup

	+-------+
	|  USER	|
	|  STUB	|
	+-------+
	   |	
	PCO|	
	   |
	+-------+			+-------+
	|	|			|	|	
	| IUT	|-----------------------|PEER	|	
	|	|	PCO		|END	|
	+-------+			+-------+

Vikas & Gayatri	                                               [Page 4]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

In the simulated test setup :

IUT is the Implementation Under Test i.e. IUA stack. 
The User stub is the simulated Q.921 user, which will invoke the 
different primitives.
Peer End is the remote end for sending and receiving the messages.
PCO in the above figure reflects the "Point of Control and 
Observation". SCTP will be used as a an underlying layer on both 
ends(This is not explicitly shown in the above Figure).

2.2 VARIOUS CONFIGURATIONS FOR THE TEST SUIT 
   =========================================
  
2.2.1 VARIOUS TEST CONFIGURATION AT SG SIDE 

   Configuration A:
       This simple configuration is used for all procedures of tests
       concerning only one AS. Configuration A is shown in figure 1.
       AS is  handling traffic for Interface Identifier X or a 
       range of interface identifiers. AS is having only one ASP
       (ASP1). 

       Interface Identifiers can be
       1.  Integer Based
       2.  Text Based

          
        +-------------+                               +--------------+
        |             |                               | AS  IID=X    |
        |     SG      |                               |  -------     |
        |   (IUT)     |-------------------------------|  | ASP1 |    |
        |             |                               |  -------     |
        +-------------+                               +--------------+
						           Peer
			     
			     Fig 1: Configuration A

      
   Configuration B:
       This configuration is used for all the procedures of tests 
       concerning two or more ASP in one AS. Configuration B is shown
       in figure 2. AS handles the traffic for Interface identifiers
       X-Z. AS can be in OVERRIDE or LOADSHARE mode of
       traffic handling. 

Vikas & Gayatri	                                               [Page 5]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

                                                      +--------------+
                                                      | AS  IID  X-Z |
        +-------------+                               |  -------     |
        |             |-------------------------------|-| ASP1  |    |
        |             |                               |  -------     |
        |    SG       |                               |  -------     |
        |   (IUT)     |                               | | ASP2  |    |
        |             |-------------------------------|- -------     |
        +-------------+                               +--------------+

							    Peer

                           Fig 2: Configuration B

 
 

 Configuration C:
       This configuration is used for all the procedures of tests
       concerning one ASP in two AS which is handling traffic for both
       AS. Configuration C is shown in figure 3. AS1 handles the
       traffic for Interface Identifier X and AS2 handles traffic for
       Interface Identifier Y. ASP1 is in both AS. 
       

                                                      +--------------+
                                                      |              |
                                                      |   --------   |
                                            ----------|   | ASP1  |  |
        +-------------+                    |          |    -------   |
        |             |                    |          |              |
        |             |--------------------           |      AS 1    |
        |     SG      |                               |              |
        |    (IUT)    |                               +--------------+
        |             |---------------------                                 
        |             |                     |            
        +-------------+			    |
					    | 			    
                                            |         +--------------+
                                            |         |      AS 2    |
                                            |         |   --------   |
                                            |         |  |  ASP1  |  |
                                            |         |   --------   |
                                            |         |   --------   |
                                            ----------|  |  ASP2  |  |
                                                      |   --------   |
                                                      +--------------+
							    Peer
							
			    Fig 3: Configuration C							

Vikas & Gayatri	                                               [Page 6]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			    
			    
2.2.2 VARIOUS TEST CONFIGURATION AT ASP SIDE 

Configuration D:
       This simple configuration is used for all procedures of tests
       concerning only one AS. Configuration D is shown in figure 4.
       AS is  handling traffic for Interface Identifier X or a 
       range of interface identifiers. AS is having only one ASP
       (ASP1). 

       Interface Identifiers can be
       1.  Integer Based
       2.  Text Based

          
        +-------------+                               +--------------+
        |             |                               | AS  IID=X    |
        |     SG      |                               |  -------     |
        |             |-------------------------------|  | ASP1 |    |
        |             |                               |  -------     |
        +-------------+                               +--------------+
	    Peer					    IUT
							    
			     Fig 4: Configuration D

 
 Configuration E:
       This configuration is used for all the procedures of tests
       concerning two or more ASP in one AS. Configuration E is shown
       in figure 5. AS handles the traffic for Interface identifiers
       X-Z. AS can be in OVERRIDE or LOADSHARE mode of traffic
       handling. 

                                                      +--------------+
                                                      | AS  IID  X-Z |
        +-------------+                               |  -------     |
        |             |-------------------------------|-| ASP1  |    |
        |             |                               |  -------     |
        |    SG       |                               |  -------     |
        |             |                               | | ASP2  |    |
        |             |-------------------------------|- -------     |
        +-------------+                               +--------------+
	    Peer					    IUT

                           Fig 5: Configuration E

 
 
Vikas & Gayatri	                                               [Page 7]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

 
 Configuration F:
       This configuration is used for all the procedures of tests
       concerning one ASP in two AS which is handling traffic for both
       AS. Configuration F is shown in figure 6. AS1 handles the
       traffic for Interface Identifier X and AS2 handles traffic for
       Interface Identifier Y. ASP1 is in both AS. 
       

						      
						      
						      +--------------+
                                                      |              |
                                                      |   --------   |
                                            ----------|   | ASP1  |  |
        +-------------+                    |          |    -------   |
        |             |                    |          |              |
        |             |--------------------           |      AS 1    |
        |     SG      |                               |              |
        |             |                               +--------------+
        |             |---------------------                                 
        |             |                     |            
        +-------------+			    |
	    Peer			    | 			    
                                            |         +--------------+
                                            |         |      AS 2    |
                                            |         |   --------   |
                                            |         |  |  ASP1  |  |
                                            |         |   --------   |
                                            |         |   --------   |
                                            ----------|  |  ASP2  |  |
                                                      |   --------   |
                                                      +--------------+
							   IUT
							
			    Fig 6: Configuration F							

 Configuration G:
       This configuration is used for all the procedures of tests
       concerning two SG's and one ASP. ASP1 is connected to both
       SG1 and SG2. 

Vikas & Gayatri	                                               [Page 8]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

        +-------------+                               
        |             |
        |             |
        |      SG1    |---------------
        |             |               |               +--------------+
        |             |               |               | AS1 IID X-Z  |
        +-------------+               |               |   -------    |
                                       ---------------|  | ASP1  |   |
                                       ---------------|   -------    |
                                     |                +--------------+
				     |	
				     | 
	+-------------+		     | 	
        |             |		     |
        |             |              |	
        |      SG2    |--------------
        |             |
        |             |
        +-------------+
			    Fig 7: Configuration G			    

			    

3. TEST SCENARIOS

3.1 ASPM Messages

3.1.1 Valid ASPM cases when ASP is Under Test
---------------------------------------------------------------
3.1.1.1 ASPM_V_ASP_01 : ASP Up and Active State Transition flow
---------------------------------------------------------------
Test Objective: To verify the ASP Up and Active state transition
Procedures at an ASP end.
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3.1.1
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP and SG.
---------------------------------------------------------------- 

Test Description :

a) Invoke an M-ASP-UP request from LM for ASP1.
   Verify that an ASPUP message is sent to the peer.

b) Send an ASPUP ACK from the peer.

Vikas & Gayatri	                                               [Page 9]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   Verify that an M-ASP-UP confirm primitive is invoked by the ASP.

c) Verify that the ASP state is moved to ASP-INACTIVE.

d) Invoke an M-ASP-ACTIVE request from LM for ASP1.
   Verify that an ASPAC message is sent to the SG.
   ASPAC message can be empty or may contain IID/IID's.

e) Send an ASPAC ACK in response to the ASPAC. 
   Verify that an M-ASP-ACTIVE confirm primitive is invoked by the
   ASP.

f) Verify that the ASP state is moved to ASP-ACTIVE.
  ---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 
--------M-ASP-UP---------->
	Request
	
			---------------ASPUP-------------->				
			<--------------ASPUP-ACK-----------		 	
<-------M-ASP-UP---------		   
	confirm				   

			ASP state is now ASP-INACTIVE
			<---------NOTIFY(AS-INACTIVE)------		 	
			AS state is now AS-INACTIVE

-------M-ASP-ACTIVE----->
	Request
			--------------ASPAC--------------->				
			<-------------ASPAC-ACK-----------		 	
<------M-ASP-ACTIVE-----		   
	Confirm				   

			ASP state is now ASP-ACTIVE
			<---------NOTIFY(AS-ACTIVE)------		 	
			AS state is now AS-ACTIVE
---------------------------------------------------------------

---------------------------------------------------------------
3.1.1.2 ASPM_V_ASP_02 : ASP Inactive and Down State Transition flow
---------------------------------------------------------------
Test Objective: To verify the ASP Inactive and Down state transition
Procedures at ASP end.
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3.1.1

Vikas & Gayatri	                                              [Page 10]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP and SG. ASP is in ASP-ACTIVE state.
---------------------------------------------------------------- 
Test Description :

a) Invoke an M-ASP-INACTIVE request from LM for ASP1.
   Verify that an ASPIA message is sent to the peer.
   ASPIA message can be empty or may contain IID/IID's.

b) Send an ASPIA ACK from the peer.
   Verify that an M-ASP-INACTIVE Confirm indication is given to LM.

c) Also verify that ASP state is moved to ASP-INACTIVE.

d) Invoke an M-ASP-DOWN request from LM for ASP1.
   Verify that an ASPDN message is sent to the SG.

e) Send an ASPDN ACK from peer(SG) in response to the ASPDN. 
   Verify that M-ASP-DOWN Confirm indication is given to LM.

f) Verify that state of ASP is moved to ASP-DOWN.
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

			ASP state is ASP-ACTIVE

--------M-ASP-INACTIVE--->
	Request
			----------------ASPIA------------->				
			<---------------ASPIA-ACK----------		 	
<-------M-ASP-INACTIVE---		   
	confirm				   
			
			ASP state is ASP-INACTIVE
			<---------NOTIFY(AS-INACTIVE)------		 	

-------M-ASP-DOWN----->
	Request
			---------------ASP-DOWN----------->				
			<--------------ASP-DOWN-ACK-------		 	
<------M-ASP-DOWN-----		   
	Confirm				   
			ASP state is now ASP-DOWN

--------------------------------------------------------------

Vikas & Gayatri	                                              [Page 11]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

--------------------------------------------------------------
3.1.1.3 ASPM_V_ASP_03 : ASPUP Procedures when two ASP's are in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the ASPUP 
procedures when two ASP's are in two AS. 
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- F
AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling
traffic for IID range 15-20.
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between 
ASP1, ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state.
---------------------------------------------------------------- 
Test Description :

   a) Invoke an M-ASP-UP request from LM for ASP1.
      An ASPUP message should be sent to the peer(SG).

   b) Send an ASPUP ACK and two Notify (AS-Inactive) messages in 
      response, corresponding to AS1 and AS2 from peer to ASP side.
      Verify that ASP1 is moved to ASP-INACTIVE state.

   c) Invoke an M-ASP-UP request from LM for ASP2.
      An ASPUP message should be sent to the peer(SG).
   
   d) Send an ASPUP ACK from peer to the ASP side.
      Verify that state of ASP2 is moved to ASP-INACTIVE.
   
---------------------------------------------------------------

Expected Message Sequence

LM/SU			ASP				Peer(SG) 

			ASP1 state is ASP-DOWN

--------M-ASP-UP------->
	Request (for ASP1)
			----------------ASPUP------------->				
			<---------------ASPUP-ACK----------		 	
<-------M-ASP-UP-------		   
	confirm				   
			ASP1 state is ASP-INACTIVE

			<-------NOTIFY (AS-Inactive)-------
				for AS1			
			<-------NOTIFY (AS-Inactive)-------		 	
				for AS2

--------M-ASP-UP------->
	Request (for ASP2)
			----------------ASPUP------------->				

Vikas & Gayatri	                                              [Page 12]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			<---------------ASPUP-ACK----------		 	
<-------M-ASP-UP-------		   
	confirm				   
			ASP2 state is ASP-INACTIVE

--------------------------------------------------------------

---------------------------------------------------------------
3.1.1.4 ASPM_V_ASP_04 : ASP ACTIVE Procedures when two ASP's are 
in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the ASPAC 
procedures when two ASP's are in two AS. 
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- F
AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling
traffic for IID range 15-20.
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between 
ASP1, ASP2 and SG. ASP1 and ASP2 are in ASP-INACTIVE state.
---------------------------------------------------------------- 
Test Description :

   a) Invoke an M-ASP-ACTIVE request from LM of ASP1 for AS1.
      Verify that an ASPAC message is sent to the SG for IID (1-5).

   b) Send an ASPAC ACK (IID 1-5)and Notify (AS-Active)from peer(SG)
      to ASP.
      Verify that state of ASP1(in AS1) is moved to ASP-ACTIVE.
   
   c) Invoke an M-ASP-ACTIVE request from LM of ASP2 (for say 
      IID 16).
      Verify that an ASPAC message is sent to the peer(SG) for
      IID 16.

   d) Send an ASPAC ACK (IID 15-20) and Notify (AS-Active)from peer
      to ASP side. ASPAC ACK may contain tag 0x8 for 
      specifying the ranges.
      Verify that ASP2 state is moved to ASP-ACTIVE.

   e) Invoke the primitive for Unit Data Request Message from SU
      of ASP1. Verify that a Unit Data Request Message is sent to
      the peer.
   
   f) Send Unit Data Indication Message from peer to ASP1 for say 
      IID 4.
      Verify that the corresponding indication is given to SU.
   

Vikas & Gayatri	                                              [Page 13]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   g) Invoke the primitive for Unit Data Request Message from SU
      of ASP2. Verify that a Unit Data Request Message is sent to
      the peer.
   
   h) Send Unit Data Indication Message from peer to ASP2 for say
      IID 16.
      Verify that the corresponding indication is given to SU.

---------------------------------------------------------------

Expected Message Sequence

LM/SU			ASP				Peer(SG) 
--------M-ASP-ACTIVE---->
	Request
			
			----------------ASPAC------------->				
			<---------------ASPAC-ACK----------		 	
<------M-ASP-ACTIVE-----		   
	confirm				   
			ASP1 state is ASP-ACTIVE
			<-------NOTIFY (AS-Active)-------		 	

--------M-ASP-ACTIVE---->
	Request
			----------------ASPAC------------->				
			<---------------ASPAC-ACK----------		 	
<-------M-ASP-ACTIVE-------		   
	confirm				   
			
			ASP2 state is ASP-ACTIVE
			<-------NOTIFY (AS-Active)-------		 	

			-------Unit Data Request----------->
			<---Unit Data Indication (IID 4)----
			
			-------Unit Data Request----------->
			<---Unit Data Indication (IID 16)---

--------------------------------------------------------------

---------------------------------------------------------------
3.1.1.5 ASPM_V_ASP_05 : ASPUP Procedures when two ASP's are
in one AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the ASPUP 
procedures when two ASP's are in one AS.
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- E

Vikas & Gayatri	                                              [Page 14]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

(AS can have text or integer based identifiers)
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state.
---------------------------------------------------------------- 
Test Description :

   a) Invoke an M-ASP-UP request from LM for ASP1.
      Verify that an ASPUP message is sent to the peer(SG).
   
   b) Send an ASPUP ACK and Notify (AS-Inactive) messages from
      peer to ASP side.
      Verify that the state of ASP1 is now ASP-INACTIVE.

   c) Invoke an M-ASP-UP request from LM for ASP2.
      Verify that an ASPUP message is sent to the peer.
  
   d) Send an ASPUP ACK from peer in response.
      Verify that the State of ASP2 is now ASP-INACTIVE.   

---------------------------------------------------------------

Expected Message Sequence

LM/SU			ASP				Peer(SG) 

--------M-ASP-UP-------->
	Request (ASP1)
			---------------ASPUP------------->				
			<--------------ASPUP-ACK---------		 	
  

<-------M-ASP-UP---------		   
	confirm	(ASP1)			   
			
			ASP1 state is now ASP-INACTIVE
			<----------NOTIFY (AS-Inactive)---

--------M-ASP-UP-------->
	Request (ASP2)
			---------------ASPUP------------->				
			<--------------ASPUP-ACK----------		 	
<-------M-ASP-UP---------		   
	confirm	(ASP2)			   
								
			ASP2 state is now ASP-INACTIVE

--------------------------------------------------------------

Vikas & Gayatri	                                              [Page 15]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

--------------------------------------------------------------
3.1.1.6 ASPM_V_ASP_06 : ASPAC Procedures when two ASP's are
in one AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the ASPAC 
procedures when two ASP's are in one AS.
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- E
(AS can have text or integer based identifiers)
AS is in Override mode.
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-INACTIVE state.
---------------------------------------------------------------- 
Test Description :

   a) Invoke an M-ASP-ACTIVE request from LM for ASP1.
      Verify that an ASPAC message is sent to the SG.
   
   b) Send an ASPAC ACK to ASP1 and two Notify (AS-Active) messages
      one each to ASP1 and ASP2 from peer.
      Verify that state of ASP1 is now ASP-ACTIVE. 

   c) Send a Unit Data Request Message from ASP1 to the peer by
      invoking the Unitdata Request primitive from SU.
   
   d) Send Unit Data Indication Message from peer to ASP1. 
      Verify that the corresponding indication is given to SU.

   e) Invoke an M-ASP-ACTIVE request from LM for ASP2.
      Verify that an ASPAC message is sent to the peer.

   f) Send an ASPAC ACK from peer to ASP2 in response.
      Verify that ASP2 is moved to ASP-ACTIVE state.
   
   g) Send a Notify(Alternate ASP Active) from peer to ASP1.
      ASP1 should be moved to ASP-INACTIVE state.

   h) Send a Unit Data Request Message from ASP2 to the peer by
      invoking the Unitdata Request primitive from SU.
  
   i) Send Unit Data Indication Message from peer to ASP2.
      Verify that the corresponding indication is given to SU.
      
---------------------------------------------------------------

Expected Message Sequence

LM/SU			ASP				Peer(SG) 

--------M-ASP-ACTIVE---->
	Request (ASP1)

Vikas & Gayatri	                                              [Page 16]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			---------------ASP ACTIVE------------->				
			<--------------ASP ACTIVE-ACK---------		 	
<-------M-ASP-ACTIVE----		   
	confirm	(ASP1)			   
			ASP1 state is now ASP-ACTIVE
			<----------NOTIFY (AS-Active)---
					to ASP1	
			<----------NOTIFY (AS-Active)---
					to ASP2	
			-------Unit Data Request----------->
			<------Unit Data Indication---------

--------M-ASP-ACTIVE--->
	Request (ASP2)
			---------------ASP ACTIVE----------->				
			<--------------ASP ACTIVE-ACK----------		 	
<-------M-ASP-ACTIVE----		   
	confirm	(ASP2)			   
								
			ASP2 state is now ASP-ACTIVE

			<-----NOTIFY (Alternate ASP Active)----
			ASP1 state is now ASP-INACTIVE

			-------Unit Data Request----------->
			<------Unit Data Indication---------

--------------------------------------------------------------

---------------------------------------------------------------
3.1.1.7 ASPM_V_ASP_07 : ASPAC Procedures when one ASP is in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the ASPAC 
procedures when one ASP is in two AS.
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- F
AS1 and AS2 can serve traffic for either integer or text based
identifiers.
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1, ASP2 and SG. ASP1 is in ASP-INACTIVE state. ASP2 is in
ASP-DOWN state.
--------------------------------------------------------------- 
Test Description :

   a) Invoke an M-ASP-ACTIVE request from LM for ASP1 (in AS1).
      Verify that an ASPAC message is sent to the peer.
   

Vikas & Gayatri	                                              [Page 17]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   b) Send an ASPAC ACK from peer(SG) to ASP1.
      Also Send a Notify (AS-Active) message from peer to ASP1.
      Verify that the State of ASP1 in AS1 is now marked
      ASP-ACTIVE. 
   
   c) Send a Unit Data Request Message from ASP1 to the peer by
      invoking the Unitdata Request primitive from SU.
   
   d) Send a Unit Data Indication message from peer to ASP1 for AS1.
      Verify that the corresponding indication is given to SU.

   e) Invoke an M-ASP-ACTIVE request from LM for ASP1 (in AS2).
      Verify that an ASPAC message is sent to the peer.
   
   f) Send an ASPAC ACK from peer to ASP1.
      Send a Notify (AS-Active) message from peer to ASP1.
      State of ASP1 in AS2 is now marked ASP-ACTIVE.  	

   g) Send a Unit Data Request Message from ASP1 to peer by
      invoking the Unitdata Request primitive from SU.

   h) Send Unit Data Indication Message from peer to ASP1 for AS2.
      Verify that corresponding indication is invoked at SU.
      
---------------------------------------------------------------

Expected Message Sequence

LM/SU			ASP				Peer(SG) 

-------M-ASP-ACTIVE----->
	Request (ASP1)
			---------------ASPAC-------------->				
			<-------------ASPAC-ACK -----------		 	
<------M-ASP-ACTIVE-----		   
	Confirm	(ASP1)			   
			ASP1 state is now ASP-ACTIVE in AS1
			<-----------NOTIFY (AS-ACTIVE)-----

			-------Unit Data Request--------->
			<-------Unit Data Indication------

-------M-ASP-ACTIVE----->
	Request (ASP1)
			--------------ASPAC ------------->				
			<-----------ASPAC-ACK ------------		 	
<------M-ASP-ACTIVE-----		   
	Confirm	(ASP1)			   
			ASP1 is now ASP-ACTIVE in AS2
			<-----------NOTIFY (AS-Active)-----

			------------Unit Data Request---->
			<-------Unit Data Indication-----
--------------------------------------------------------------

Vikas & Gayatri	                                              [Page 18]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.1.1.8 ASPM_V_ASP_08 : Heartbeat Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that if the
IUA stack receives a heartbeat message, it responds with an Heartbeat 
Ack. 
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10
---------------------------------------------------------------
Test Configuration :- D
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state.
---------------------------------------------------------------
Test Description :

   a) Heartbeat message containing some heartbeat data
      received from peer(SG).
   
   b) Verify that IUA stack sends a Heartbeat Ack (with the same
      heartbeat Data) to the peer stack (SG).

   The IUA stack MUST acknowledge the Heartbeat message
   with an Heartbeat Ack even if it doesn't support Heartbeat 
   generation.
---------------------------------------------------------------
Expected Message Sequence
LM/SU			ASP				Peer(SG) 

			<--------------Heartbeat-----------		   
			--------------Heartbeat Ack-------->		   
---------------------------------------------------------------

---------------------------------------------------------------
3.1.1.9 ASPM_V_ASP_09 : Heartbeat Message Generation
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the heartbeat
message generation if an implementation generates it.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10
---------------------------------------------------------------
Test Configuration :- D
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state.
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 19]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Description :

   a) Verify that Heartbeat message is sent periodically to the peer. 
   
   b) Send Heartbeat Ack to the IUT. 
      Verify that Heartbeat timer is started again. 	
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

			--------------Heartbeat------------>		   
			<--------------Heartbeat Ack--------		   
---------------------------------------------------------------

---------------------------------------------------------------
3.1.1.10 ASPM_V_ASP_10 : Text Based Interface identifiers in AS 
---------------------------------------------------------------
Test Objective: The main aim of this case is to check data 
transfer when AS is having text based interface identifiers.
This case is valid for the implementations that support text based
interface identifiers.
----------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.5
---------------------------------------------------------------
Test Configuration :- D
AS1 is handling traffic for two text based interface
identifiers say "smile" and "john". 
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between 
ASP1 and peer(SG). ASP1 is in ASP-INACTIVE state.
---------------------------------------------------------------
Test Description :

   a) Invoke an M-ASP-ACTIVE request from LM for ASP1.

   b) Verify that an ASPAC message is sent to the SG for both 
      IID's(smile and john).
   
   c) Send an ASPAC ACK and Notify (AS-Active)from peer in response.
      Verify that ASP and AS states are moved to ASP-ACTIVE/AS-ACTIVE.
   
   d) Send a Unit Data Request Message from ASP to peer by invoking
      the Unit Data Request primitive from SU.

   e) Send a Unit Data Indication Message from peer to ASP.
      Verify that corresponding indication primitive is given to SU.  	

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

Vikas & Gayatri	                                              [Page 20]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

-------M-ASP-ACTIVE----->
	Request
			--------ASPAC (smile and john)------>				
			<-------------ASPAC-ACK -------------		 	
<------M-ASP-ACTIVE-----		   
	Confirm				   
			AS1/ASP1 state is now AS-ACTIVE/ASP-INACTIVE
			<----------NOTIFY (AS-Active)--------

			--------------Unit Data Request----->
			<-----------Unit Data Indication-----

---------------------------------------------------------------

---------------------------------------------------------------
3.1.1.11 ASPM_V_ASP_11 : Routing Verification when Two ASP's are
in two different AS(Text+Integer)
---------------------------------------------------------------
Test Objective: The main aim of this case is to check data 
transfer when one AS has integer based interface identifier and
other text based interface identifier. This case is valid for the
implementations that support both text and integer based interface
identifiers.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.5
---------------------------------------------------------------
Test Configuration :- F
AS1 serves traffic for integer based identifier say 1. AS2 serves
traffic for text based identifier say john.
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1, ASP2 and peer(SG). ASP1, ASP2 are in ASP-INACTIVE state. 
---------------------------------------------------------------
Test Description :
  
   a) Invoke an M-ASP-ACTIVE request from LM for ASP2.
      Verify that an ASPAC message is sent to the SG.

   b) Send an ASPAC ACK from peer to ASP2.
      Verify that state of ASP2 in AS2 is now marked ASP-ACTIVE. 
      Also send Notify (AS-Active) message to ASP2.
   
   c) Invoke an M-ASP-ACTIVE request from LM for ASP1 in AS1.
      Verify that an ASPAC message is sent to the SG.

   d) Send an ASPAC ACK from peer to ASP1.
      Verify that state of ASP1 in AS1 is now marked ASP-ACTIVE. 
      Also send a Notify (AS-Active) message from peer to ASP1.

   e) Send a Unit Data Request Message from ASP1 to peer by invoking
      the Unit Data Request primitive from SU.

Vikas & Gayatri	                                              [Page 21]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   f) Send Unit Data Indication Message from peer for ASP1.
      Verify that corresponding indication primitive is given to SU.

   g) Send a Unit Data Request Message from ASP2 to peer by invoking
      the Unit Data Request primitive from SU.

   h) Send Unit Data Indication Message from peer for ASP2.
      Verify that corresponding indication primitive is given to SU.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

-------M-ASP-ACTIVE----->
	Request (ASP2)
			----------ASPAC (IID john)--------->				
			<-------ASPAC-ACK (IID john)-------		 	
<------M-ASP-ACTIVE-----		   
	Confirm	(ASP2)			   
			ASP2 is now ASP-ACTIVE in AS2
			<--------NOTIFY(AS-Active)---------

-------M-ASP-ACTIVE----->
	Request (ASP1)
			------------ASPAC (IID 1)---------->				
			<---------ASPAC-ACK (IID 1)--------		 	
<------M-ASP-ACTIVE-----		   
	Confirm	(ASP1)			   

			ASP1 is now ASP-ACTIVE in AS1
			<--------NOTIFY(AS-Active)---------			

			-----------Unit Data Request------->
			<-------Unit Data Indication--------

			-----------Unit Data Request------->
			<-------Unit Data Indication--------

---------------------------------------------------------------

3.1.2 Invalid ASPM cases when ASP is Under Test

---------------------------------------------------------------
3.1.2.1 ASPM_I_ASP_01 : ASPM Message received in wrong 
state of ASP
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle an ASPM message when received in 
wrong state of the ASP.

Vikas & Gayatri	                                              [Page 22]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

----------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.14, 3.16
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------
Test Description :

a) Send an ASPIA ACK message from peer to ASP1.
   Verify that ASP state is moved to ASP-INACTIVE.

b) Send a ASPDN ACK message from peer to ASP1.
   Verify that ASP state is moved to ASP-DOWN.

c) Invoke an M-ASPUP request from LM(ASP1).
   Verify that an ASPUP message reaches the peer.

d) Send a ASPUP ACK message from peer to ASP1.
   Verify that state of ASP is moved to ASP-INACTIVE.

e) Invoke an M-ASP Active request from LM(ASP1).
   Verify that an ASPAC message reaches the peer.

f) Send a ASPAC ACK message from peer to ASP1.
   Verify that state of ASP is moved to ASP-ACTIVE.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

			<-------------ASPIA-ACK------------		 	
			ASP state moved to ASP-INACTIVE

			<-------------ASPDN ACK------------				
			ASP state moved to ASP-DOWN

--------M-ASP-UP---------->
	Request
			---------------ASPUP-------------->				
			<--------------ASPUP-ACK-----------		 	
<-------M-ASP-UP---------		   
	confirm				   
			ASP state is now ASP-INACTIVE
			<---------NOTIFY(AS-Inactive)------				

-------M-ASP-ACTIVE----->
	Request
			--------------ASPAC--------------->				
			<-------------ASPAC-ACK-----------		 	

Vikas & Gayatri	                                              [Page 23]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

<------M-ASP-ACTIVE-----		   
	Confirm				   
			ASP state is now ASP-ACTIVE

			<---------NOTIFY(AS-Active)------				
---------------------------------------------------------------

---------------------------------------------------------------
3.1.2.2 ASPM_I_ASP_02 : ASPDN ACK in Active state of ASP
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle ASPDN ACK in Active state of ASP.
----------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.14
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------
Test Description :

a) Send a ASPDN ACK message from peer to ASP1.

b) Verify that ASP state is moved to ASP-DOWN.

c) Invoke an M-ASPUP request from LM(ASP1).
   Verify that an ASPUP message reaches the peer.

d) Send a ASPUP ACK message from peer to ASP1.
   Verify that state of ASP is moved to ASP-INACTIVE.

e) Invoke an M-ASP Active request from LM(ASP1).
   Verify that an ASPAC message reaches the peer.

f) Send a ASPAC ACK message from peer to ASP1.
   Verify that state of ASP is moved to ASP-ACTIVE.
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

			<-------------ASPDN ACK------------				
			ASP state moved to ASP-DOWN

--------M-ASP-UP---------->
	Request
			---------------ASPUP-------------->				
			<--------------ASPUP-ACK-----------		 	

Vikas & Gayatri	                                              [Page 24]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

<-------M-ASP-UP---------		   
	confirm				   
			ASP state is now ASP-INACTIVE
			<-------NOTIFY(AS-INACTIVE)--------		 	

-------M-ASP-ACTIVE----->
	Request
			--------------ASPAC--------------->				
			<-------------ASPAC-ACK-----------		 	
<------M-ASP-ACTIVE-----		   
	Confirm				   
			ASP state is now ASP-ACTIVE
			<-------NOTIFY(AS-ACTIVE)--------		 	

---------------------------------------------------------------

---------------------------------------------------------------
3.1.2.3 ASPM_I_ASP_03 : ASPSM Timer expiry Cases
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle ASPSM timer expiry procedures.
----------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.13, 3.14
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-DOWN state.
---------------------------------------------------------------
Test Description :

a) Invoke an M-ASPUP request from LM(ASP1).
   Verify that an ASPUP message reaches the peer.

b) Don't send any response(ASPUP-ACK) message from peer.
   Verify that after max retransmissions, the ASP remains in 
   ASP-DOWN state and a negative indication is given to LM.

c) Again ,invoke an M-ASPUP request from LM(ASP1).
   Verify that an ASPUP message reaches the peer.

d) Send ASP-UP-ACK and Notify (AS-Inactive) from peer.
   Verify that the state of the ASP moves from ASP-DOWN to
   ASP-INACTIVE.

e) Invoke an M-ASP Down request from LM(ASP1).
   Verify that an ASPDN message reaches the peer.

f) Don't send any response(ASPDN-ACK) message from peer.
   Verify that after max retransmissions, the ASP is brought to

Vikas & Gayatri	                                              [Page 25]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   ASP-DOWN state and a negative indication is given to LM.
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

-------M-ASP-UP----->
	Request
			--------------ASPUP--------------->				
			
			--------------ASPUP--------------->				
			--------------ASPUP--------------->				
			--------------ASPUP--------------->				
			--------------ASPUP--------------->				
	After Max(say 4) retransmissions, ASP remains in ASP-DOWN
	state			

LM again invokes M-ASPUP request
-------M-ASP-UP----->
	Request
			--------------ASPUP--------------->				
			<--------------------------------
				ASP-UP ACK
			<--------------------------------
				Notify (AS-INACTIVE)

			ASP1 is in ASP-INACTIVE state

-------M-ASP-DOWN----->
	Request
			--------------ASPDN--------------->				

			--------------ASPDN--------------->				
			--------------ASPDN--------------->				
			--------------ASPDN--------------->				
			--------------ASPDN--------------->				
			
	After Max(say 4) retransmissions, ASP is brought to ASP-DOWN
	state

---------------------------------------------------------------

---------------------------------------------------------------
3.1.2.4 ASPM_I_ASP_04 : ASPTM Timer expiry Cases
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle ASPTM(ASPAC, ASPIA) timer expiry 
procedures.
----------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.15, 3.16
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 26]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-INACTIVE state.
---------------------------------------------------------------

a) Invoke an M-ASP Active request from LM(ASP1).
   Verify that an ASPAC message reaches the peer.

b) Don't send any response(ASPAC-ACK) message from peer.
   Verify that after max retransmissions, the ASP remains in
   ASP-INACTIVE state and a negative indication is given to LM.

c) Invoke an M-ASP Active request from LM(ASP1).
   Verify that an ASPAC message reaches the peer.

d) Send ASP-ACTIVE-ACK and Notify (AS-active) from peer.
   Verify that state of an ASP moves from ASP-INACTIVE to
   ASP-ACTIVE.

e) Invoke an M-ASP Inactive request from LM(ASP1).
   Verify that an ASPIA message reaches the peer.

f) Don't send any response(ASPIA-ACK) message from peer.
   Verify that after max retransmissions, the ASP is brought to
   ASP-INACTIVE state and a negative indication is given to LM.
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

-------M-ASP-ACTIVE----->
	Request
			--------------ASPAC--------------->				
			
			--------------ASPAC--------------->				
			--------------ASPAC--------------->				
			--------------ASPAC--------------->				
			--------------ASPAC--------------->				

	After Max retransmissions, ASP remains in ASP-INACTIVE state			

LM again invokes M-ASP-ACTIVE request
-------M-ASP-ACTIVE----->
	Request
			--------------ASPAC--------------->				
			<--------------------------------
				ASP-ACTIVE ACK
			<--------------------------------
				Notify (AS-ACTIVE)

-------M-ASP-INACTIVE----->
	Request
			--------------ASPIA--------------->				

Vikas & Gayatri	                                              [Page 27]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			--------------ASPIA--------------->				
			--------------ASPIA--------------->				
			--------------ASPIA--------------->
			--------------ASPIA--------------->
	After Max retransmissions, ASP brought to ASP-INACTIVE state
---------------------------------------------------------------

---------------------------------------------------------------
3.1.2.5 ASPM_I_ASP_05 : ASPIA ACK in response to ASPAC
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
ASPAC retransmissions if ASPIA ACK is received in 
response to ASPAC.
----------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.8
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-INACTIVE state.
---------------------------------------------------------------
Test Description :

a) Invoke an M-ASP Active request from LM(ASP1).
   Verify that an ASPAC message reaches the peer.

b) Send ASPIA-ACK message from peer.
   Verify that ASP remains in ASP-INACTIVE state.
   ASPAC retransmissions may continue or are stopped.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

-------M-ASP-ACTIVE----->
	Request
			--------------ASPAC--------------->				
			<-------------ASPIA-ACK------------		 	

			ASPAC retransmissions may continue or stopped
			ASP state remains in ASP-INACTIVE

---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 28]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.1.2.6 ASPM_I_ASP_06 : Association re-establishment in case of
Heartbeat timer expiry
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the Association
re-establishment procedures if no Heartbeat Ack is received.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10
---------------------------------------------------------------
Test Configuration :- D
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state.
---------------------------------------------------------------

Test Description :

   a) Verify that Heartbeat message is sent periodically to the peer. 
   
   b) Verify that if no Heartbeat Ack is received from the peer
      within 2*T heartbeat timer interval, the SCTP association is
      disconnected and re-establishment is tried if signaling process 
      is configured as client.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

			--------------Heartbeat----------->		   
		No HeartbeatAck received within 2*T heartbeat
		interval.
		Association disconnected and re-establishment tried.
---------------------------------------------------------------

3.1.3 Valid ASPM cases when SG is Under Test

---------------------------------------------------------------
3.1.3.1 ASPM_V_SG_01 : AS Inactive/Active State Transition in single
ASP-SG scenario.
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify the ASP 
Up and Active Procedures at SG end in single ASP-SG scenario.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between

Vikas & Gayatri	                                              [Page 29]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

peer(ASP1) and SG.
---------------------------------------------------------------
Test Description :

a) Send an ASPUP message from peer to SG.

b) Verify that the SG sends an ASPUP ACK and Notify (AS-INACTIVE) to 
   ASP1.
   Verify that the ASP and AS states are moved to ASP-INACTIVE/
   AS-INACTIVE.

c) Send an ASPAC message from the peer to SG.

d) Verify that the SG sends an ASPAC-ACK and NOTIFY (AS-ACTIVE)
   message to the peer.
   Verify that the ASP and AS states are moved to ASP-ACTIVE/
   AS-ACTIVE.
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPUP-------------				
			---------------ASPUP-ACK----------->		 	
			----------NOTIFY (AS-INACTIVE)----->								

		ASP and AS state moved to ASP-INACTIVE/AS-INACTIVE

			<---------------ASPAC-------------				
			--------------ASPAC-ACK----------->		 	
			----------NOTIFY (AS-ACTIVE)----->

		ASP and AS state moved to ASP-ACTIVE/AS-ACTIVE

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.2 ASPM_V_SG_02 : AS Inactive and Down State Transition,
in single ASP-SG scenario.
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify the ASP 
Inactive and Down Procedures at SG end, in single ASP-SG scenario.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1/AS are in ASP-ACTIVE/AS-ACTIVE state
respectively.
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 30]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Description :

a) Send an ASPIA message from peer to SG.

b) Verify that SG sends an ASPIA ACK and Notify (AS-Pending) to 
   the peer.
   Verify that the ASP state is moved to ASP-INACTIVE and AS state is
   moved to AS-PENDING.

c) Allow the pending timer to expire.
   Verify that after pending timer expiry, SG sends a 
   NOTIFY(AS-Inactive) to the peer.
   Also verify that AS state is now moved to AS-INACTIVE state.

d) Send an ASPDN message from peer to SG.
   Verify that SG sends ASPDN-ACK to the peer.

e) Verify that ASP and AS state is moved to ASP-DOWN/AS-DOWN.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPIA--------------				
			----------------ASPIA-ACK----------->		 	
			------------NOTIFY(AS-PENDING)------>

			ASP state moves to ASP-INACTIVE
			AS state moves to AS-PENDING

			
			Pending timer Expires
			------NOTIFY(AS-INACTIVE)---------->		 	

			<--------------ASPDN---------------				
			-------------ASPDN-ACK------------		 	

			ASP and AS state moved to ASP-DOWN/AS-DOWN

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.3 ASPM_V_SG_03 : Handling of the AS State Transition from
Active to DOWN, in single ASP-SG scenario.
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify the ASP 
Down Procedures at SG end in single ASP-SG scenario, when the ASP is 
in active state.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3

Vikas & Gayatri	                                              [Page 31]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP and AS state are in ASP-ACTIVE and AS-ACTIVE state
respectively.
---------------------------------------------------------------
Test Description :

a) Send an ASPDN message from peer to SG.

b) Verify that the SG sends an ASPDN ACK to the peer.
   Verify that the ASP state moves to ASP-DOWN and AS state moves to
   AS-PENDING.

c) Allow the pending timer to expire.
   Verify that after pending timer expiry, AS state moves to 
   AS-DOWN.

d) Verify that SG does not send any Notify message to the peer.
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPDN--------------				
			----------------ASPDN-ACK----------->		 	
			ASP state moves to ASP-DOWN
			AS state moves to AS-PENDING

		
			Pending timer Expires
			AS state moves to AS-DOWN

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.4 ASPM_V_SG_04 : ASPUP procedures when one ASP is in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the ASPUP
procedures when one ASP is in two AS.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- C
AS1 and AS2 can serve traffic for either integer or text based
identifiers.
---------------------------------------------------------------- 
Pre-requirement Condition :  SCTP Association is established 
between ASP1, ASP2 and SG. ASP1, ASP2 are in ASP-DOWN state. 

Vikas & Gayatri	                                              [Page 32]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

AS1 and AS2 are in AS-DOWN state.
---------------------------------------------------------------
Test Description :

   a) Send an ASPUP message from peer to SG.

   b) Verify that SG sends an ASPUP ACK and two Notify (AS-Inactive)
      in response, corresponding to AS1 and AS2.
      Verify that state of ASP1 in AS1 and AS2 is now ASP-INACTIVE.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPUP--------------				
			----------------ASPUP-ACK----------->		 	
			----------NOTIFY (AS-Inactive)------>		 	
			----------NOTIFY (AS-Inactive)------>		 	
			
			ASP1 is now ASP-INACTIVE in both AS1 and AS2
---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.5 ASPM_V_SG_05 : ASPAC procedures when one ASP is in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the ASPAC
procedures when one ASP is in two AS.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- C
AS1 and AS2 can serve traffic for either integer or text based
identifiers.
---------------------------------------------------------------- 
Pre-requirement Condition :  SCTP Association is established 
between ASP1, ASP2 and SG. ASP1, ASP2 are in ASP-INACTIVE state. 
---------------------------------------------------------------
Test Description :

   a) Send an ASPAC message from peer to the SG for AS1.
   
   b) Verify that SG sends an ASPAC ACK and Notify (AS-Active)
      message to ASP1 in response.
      Verify that state of ASP1 in AS1 is now marked ASP-ACTIVE. 
   
   c) Send a Unit Data Request Message from peer(ASP1) to SG.
      Verify that the corresponding indication is invoked at NIF.	

   d) Invoke the primitive for Unit Data Indication Message from 

Vikas & Gayatri	                                              [Page 33]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

      NIF for AS1.
      Message should be sent to ASP1.

   e) Send an ASPAC message from peer to the SG for AS2.
     
   f) Verify that SG sends an ASPAC ACK and Notify (AS-Active)
      message to ASP1 in response.
      Verify that State of ASP1 in AS2 is now marked ASP-ACTIVE.

   g) Send a Unit Data Request Message from ASP1 to SG.
      Verify that the corresponding indication is invoked at NIF.	

   h) Invoke the primitive for Unit Data Indication Message from 
      NIF for AS2.
      Message should be sent to ASP1.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPAC--------------				
			----------------ASPAC-ACK----------->		 	
			----------NOTIFY (AS-Active)-------->		 	

			AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE
			
			<-------Unit Data Request---------
			-------Unit Data Indication------>
			
			
			<----------------ASPAC--------------				
			----------------ASPAC-ACK----------->		 	
			----------NOTIFY (AS-Active)------>		 	

			ASP1 is now ASP-ACTIVE in AS2
			
			<-------Unit Data Request---------
			-------Unit Data Indication------>

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.6 ASPM_V_SG_06 : ASPUP procedures when two ASP's are in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check ASPUP procedures
when two ASP's are in two AS.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3

Vikas & Gayatri	                                              [Page 34]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Test Configuration :- C
AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling
traffic for IID range 15-20.
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between 
ASP1, ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state. AS1 and AS2 
are in AS-DOWN state.
---------------------------------------------------------------
Test Description :

   a) Send an ASPUP message from peer(ASP1) to the SG.

   b) Verify that SG sends an ASPUP ACK and two Notify (AS-Inactive)
      in response, corresponding to AS1 and AS2.
      Verify that ASP1, AS1 and AS2 states are moved to
      ASP-INACTIVE/AS-INACTIVE.
   
   c) Send an ASPUP message from peer(ASP2) to the SG.
   
   d) Verify that SG sends an ASPUP ACK in response.
      Verify that no Notify message is sent by SG.
      Verify that ASP2 state is moved to ASP-INACTIVE.
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<---------------ASPUP-----------				
			--------------ASPUP-ACK--------->		 	
			------NOTIFY (AS-Inactive, AS1)-->
			------NOTIFY (AS-Inactive, AS2)-->

			AS1/AS2/ASP1 state is now 
			AS-INACTIVE/ASP-INACTIVE

			<---------------ASPUP-----------				
			--------------ASPUP-ACK--------->		 	
			ASP2 state is now ASP-INACTIVE

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.7 ASPM_V_SG_07 : ASPAC procedures when two ASP's are in two AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check data 
transfer when AS is having integer based interface identifiers. 
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 35]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Configuration :- C
AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling
traffic for IID range 15-20.
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between 
ASP1, ASP2 and SG. ASP1 and ASP2 are in Inactive state. AS1 and AS2
are in AS-INACTIVE state.
---------------------------------------------------------------
Test Description :

   a) Send an ASPAC message from peer to the SG for IID (1-5).

   b) Verify that SG sends an ASPAC ACK (IID 1-5)and 
      Notify (AS-Active)in response.
      Verify that state of ASP1(in AS1)and AS1 is moved to 
      ASP-ACTIVE/AS-ACTIVE.
   
   c) Send an ASPAC message from peer to the SG for IID 16.

   d) Verify that SG sends an ASPAC ACK (IID 15-20)and 
      Notify (AS-Active)in response.
      Verify that state of ASP2 and AS2 is moved to ASP-ACTIVE/
      AS-ACTIVE.

   e) Send a Unit Data Request Message from peer(ASP1) to SG.
      Verify that corresponding indication is given to NIF.

   f) Invoke the primitive for Unit Data Indication Message from NIF
      for say IID 4.
      Message should be sent to ASP1 in AS1.

   g) Send a Unit Data Request Message from peer(ASP2) to SG.
      Verify that corresponding indication is given to NIF.

   h) Invoke the primitive for Unit Data Indication Message from NIF
      for say IID 16.
      Message should be sent to ASP2 in AS2.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<-----------ASPAC (IID 1-5)---------				
			----------ASPAC-ACK (IID 1-5)------->		 	
			----------NOTIFY(AS-Active)--------->
			    
			AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE

			<-----------ASPAC (IID 16)----------				
			----------ASPAC-ACK (IID 15-20)----->		 	
			----------NOTIFY(AS-Active)--------->
			    
			AS2/ASP2 state is now AS-ACTIVE/ASP-ACTIVE

Vikas & Gayatri	                                              [Page 36]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			<------Unit Data Request-------------
			-----Unit Data Indication (IID 4)--->

			<------Unit Data Request-------------				
			-----Unit Data Indication (IID 16)-->
				
---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.8 ASPM_V_SG_08 : ASPUP procedures when Two ASP's are in
one AS
---------------------------------------------------------------
Test Objective: The main aim of this case is to check ASPUP 
procedures when two ASP's are in a single AS.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- B (AS can have text or integer based 
identifiers)
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between both ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state.
AS1 is in AS-DOWN state.
---------------------------------------------------------------
Test Description :

   a) Send An ASPUP message from peer(ASP1) to the SG.

   b) Verify that SG sends an ASPUP ACK and Notify (AS-Inactive)
      in response.
      Verify that state of ASP1 and AS1 is now ASP-INACTIVE/
      AS-INACTIVE.
   
   c) Send an ASPUP message from peer(ASP2) to the SG.

   d) Verify that SG sends an ASPUP ACK in response.
      Verify that no Notify message is sent by SG as AS state
      is already AS-INACTIVE.
      Verify that state of ASP2 is now ASP-INACTIVE.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPUP-------------				
			---------------ASPUP-ACK----------->		 	
			-----------NOTIFY (AS-Inactive)---->
								

Vikas & Gayatri	                                              [Page 37]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			AS1/ASP1 state is now 
			AS-INACTIVE/ASP-INACTIVE

			<---------------ASPUP-------------				
			---------------ASPUP-ACK---------->		 	
								
			ASP2 state is now ASP-INACTIVE
				
---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.9 ASPM_V_SG_09 : ASP ACTIVE procedures when two ASP's are in
one AS(Override)
---------------------------------------------------------------
Test Objective:  The main aim of this case is to check ASPAC
procedures when two ASP's are in a single AS in OVERRIDE mode.
and also to verify for the generation of Notify (Alternate ASP Active)
message.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- B (AS can have text or integer based 
identifiers)
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between both ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-INACTIVE
state. AS1 is in AS-INACTIVE state.
---------------------------------------------------------------
Test Description :

   a) Send an ASPAC message from peer(ASP1) to the SG.
   
   b) Verify that SG sends an ASPAC ACK to ASP1.
      Also verify that SG sends two Notify (AS-Active) messages
      one each to ASP1 and ASP2 .
      Verify that ASP1 and AS1 is now moved to ASP-ACTIVE/AS-ACTIVE
      state. 

   c) Send a Unit Data Request Message from peer(ASP1) to SG. 
      Verify that corresponding indication is given to NIF.
      
   d) Invoke primitive for Unit Data Indication Message multiple
      times from NIF.
      Verify that messages are sent to ASP1 only.

   e) Send an ASPAC message from peer(ASP2) to the SG.

   f) Verify that SG sends an ASPAC ACK to ASP2 in response.
      Verify that ASP2 is moved to ASP-ACTIVE state.   	
      
   g) Also verify that SG sends a Notify(Alternate ASP Active) to 

Vikas & Gayatri	                                              [Page 38]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

      peer(ASP1).
      Verify that ASP1 should be moved to ASP-INACTIVE state.
      AS1 should remain in AS-ACTIVE state.

   h) Send a Unit Data Request Message from peer(ASP2) to SG. 
   
   i) Invoke multiple primitives for Unit Data Indication Message
      from NIF. Verify that message should be sent to ASP2 only.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<---------------ASPAC -------------				
			------------ASPAC-ACK ------------->		 	
			----------NOTIFY (AS-Active)------->
			----------NOTIFY (AS-Active)------->			    

			AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE

			<-------Unit Data Request-----------
			--------Unit Data Indication-------->
			--------Unit Data Indication-------->

			
			<---------------ASPAC -------------				
			------------ASPAC-ACK ------------->		 	
			-------NOTIFY (Alt ASP Active)----->
				     for ASP1
			
			ASP2 state is now ASP-ACTIVE

			ASP1 state is now ASP-INACTIVE

			<-------Unit Data Request-----------
			--------Unit Data Indication-------->
					(ASP2)
			--------Unit Data Indication-------->
					(ASP2)
---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.10 ASPM_V_SG_10 : Text Based Interface identifiers in AS 
---------------------------------------------------------------
Test Objective: The main aim of this case is to check data 
transfer when AS is having text based interface identifiers. 
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 39]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Configuration :- A
AS1 is handling traffic for two text based interface
identifiers say "smile" and "john". 
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between 
ASP1 and SG. ASP1 is in ASP-INACTIVE state. AS1 is in AS-INACTIVE
state.
---------------------------------------------------------------
Test Description :

   a) Send an ASPAC message from peer to SG for both IID's(smile and 
      john).

   b) Verify that SG sends an ASPAC ACK and Notify (AS-Active)
      in response.
      Verify that ASP and AS states are moved to ASP-ACTIVE/AS-ACTIVE.
   
   c) Send a Unit Data Request Message from peer to SG.
      Verify that corresponding indication is given to NIF.	

   d) Send a Unit Data Indication Message from SG to Peer by
      invoking the Unit Data Indication primitive from NIF.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<-------ASPAC (smile and john)-----				
			-------------ASPAC-ACK ------------>		 	
			----------NOTIFY (AS-Active)------->
			    
			AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE
			
			<-------Unit Data Request-----------
			-------Unit Data Indication---------

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.11 ASPM_V_SG_11 : Routing Verification when Two ASP's are in two 
different AS(Text+Integer)
---------------------------------------------------------------
Test Objective: The main aim of this case is to check data 
transfer when one AS has integer based interface identifier and other 
text based interface identifier. This case is valid for the
implementations that support both text and integer based interface
identifiers.
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 40]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- C
AS1 serves traffic for integer based identifier say 1. AS2 serves
traffic for text based identifier say john.
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1, ASP2 and SG. ASP1, ASP2 are in ASP-INACTIVE state. 
---------------------------------------------------------------
Test Description :
   
   a) Send an ASPAC message from peer(ASP2) to the SG.

   b) Verify that SG sends an ASPAC ACK to ASP2.
      Also Verify that SG sends Notify (AS-Active) messages to 
      ASP2 and ASP1.
      Verify that State of ASP2 in AS2 is now marked ASP-ACTIVE. 
   
   c) Send an ASPAC message from peer(ASP1) to the SG for AS1.

   d) Verify that SG sends an ASPAC ACK to ASP1.
      Also verify that SG sends a Notify (AS-Active) message to ASP1.
      Verify that the state of ASP1 in AS1 is now marked ASP-ACTIVE. 

   e) Send a Unit Data Request Message from peer(ASP1) to SG.
      Verify that corresponding indication is given to NIF.

   f) Invoke the primitive for Unit Data Indication Message from NIF
      for AS1.
      Verify that Message reaches the peer (ASP1).

   g) Send a Unit Data Request Message from ASP2 to SG.
      Verify that corresponding indication is given to NIF.

   h) Invoke the primitive for Unit Data Indication Message from NIF
      for AS2.
     Verify that Message reaches the peer (ASP2).

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<------------ASPAC (IID john)------				
			-----------ASPAC-ACK (IID john)---->		 	
			----------NOTIFY (AS-Active)------->
			----------NOTIFY (AS-Active)------->			    

			AS2/ASP2 state is now AS-ACTIVE/ASP-ACTIVE

			<----------ASPAC (IID 1)-----------				
			----------ASPAC-ACK (IID 1)-------->		 	
			---------NOTIFY (AS-Active)-------->
			

Vikas & Gayatri	                                              [Page 41]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			ASP1 is now ASP-ACTIVE in AS1

			<----------Unit Data Request--------
			-------Unit Data Indication------->
			
			<----------Unit Data Request--------
			-------Unit Data Indication------->
---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.12 ASPM_V_SG_12 : Loadshare procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the 
loadshare procedures
---------------------------------------------------------------
Test Configuration :- B
--------------------------------------------------------------- 
Reference : RFC 3057, Section 3.3.2.5
---------------------------------------------------------------
Pre-requirement Condition : SCTP Association is established 
between ASP1, ASP2 and SG. AS is in Loadshare mode. ASP1 and ASP2
are in ASP-ACTIVE state. Minimum two ASP's are required to handle
traffic.
---------------------------------------------------------------
Test Description :

   a) Invoke Unit Data Indication Primitive multiple times from NIF. 

   b) Multiple Unit Data indication messages are sent from SG to peer.
      These Messages are sent to ASP1 or ASP2 depending on the 
      Loadshare algorithm. For example if the Loadshare Algorithm 
      is Round-Robin, the data may be sent first to peer(ASP1) and 
      then to peer(ASP2) in a round-robin fashion.
   
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)
		
			<-------Unit Data Request----------
			-----Unit Data Indication (ASP1)--->
			-----Unit Data Indication (ASP2)--->

---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 42]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.1.3.13 ASPM_V_SG_13 : Notify-Insufficient Resources
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the generation
of Notify - Insufficient Resources message.
---------------------------------------------------------------
Test Configuration :- B
--------------------------------------------------------------- 
Reference : RFC 3057, Section 3.3.3.2
---------------------------------------------------------------
Pre-requirement Condition : SCTP Association is established 
between ASP1, ASP2 and SG. AS is in Loadshare mode. ASP1 and ASP2
are in ASP-ACTIVE state. Minimum two ASP's are required to handle
traffic.
---------------------------------------------------------------
Test Description :

   a) Send an ASPIA message from peer(ASP1) to the SG.
      Verify that SG sends an ASPIA ACK and Notify (Insufficient 
      resources) to ASP1 in response.
      Verify that ASP1 state is moved to ASP-INACTIVE.

   b) Invoke Unit Data Indication Primitive multiple times from NIF. 
      Verify that Multiple Unit Data indication messages are sent 
      from SG to the peer. These Messages are sent to ASP2 only. 

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)
		
			<-----------------ASPIA-------------				
			---------------ASPIA-ACK------------>		 	
			----Notify(Insufficient Resources)-->
			
			ASP1 state is ASP-INACTIVE

			-----Unit Data Indication (ASP2)--->
			-----Unit Data Indication (ASP2)--->

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.14 ASPM_V_SG_14 : AS-Active again before pending timer expires
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 43]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Objective: The main aim of this scenario is to check that if 
an ASP becomes Active before pending timer expiry, the AS state 
is moved to AS-ACTIVE. Also all the buffered Data should be routed to 
that ASP (Implementation Dependent).
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP association is established between 
ASP and SG. ASP and AS is in ASP-ACTIVE/AS-ACTIVE state.
---------------------------------------------------------------
Test Description :

   a) Send an ASPIA message from peer to the SG.
   
   b) Verify that SG sends an ASPIA ACK and Notify (AS-Pending)
      in response.
      
   c) Verify that a pending timer is started at SG.
      Also verify that AS state is moved to AS-PENDING and ASP state is 
      moved to ASP-INACTIVE.

   d) Try sending multiple data indication messages from SG.
      Verify that all the data should get buffered.
 
   e) Send an ASPAC message from peer to the SG before the 
      pending timer expiry.

   f) Verify that SG sends an ASPAC ACK and Notify (AS-Active)
      in response.
      Verify that all the buffered data is sent to the ASP.

--------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<---------------ASPIA--------------				
			--------------ASPIA-ACK------------>		 	
			------------NOTIFY (AS-Pending)---->
			    
			AS state is AS-PENDING 
			and ASP state is ASP-INACTIVE

			Data Indication primitive
			invoked from NIF and
			Data buffered

Before Pending timer expiry, 
			<------------------ASPAC-----------				
			-----------------ASPAC-ACK--------->		 	
			----------NOTIFY(AS-Active)-------->

Vikas & Gayatri	                                              [Page 44]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			    

			Buffered messages sent to peer
			---------Unit Data Indication------>
			---------Unit Data Indication------>

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.15 ASPM_V_SG_15 : Heartbeat Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that if the
IUA stack receives a heartbeat message, it responds with an Heartbeat
Ack. 
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10
---------------------------------------------------------------
Test Configuration :- A
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state.
---------------------------------------------------------------
Test Description :

   a) Send Heartbeat message containing some heartbeat data
      from the peer stack.

   b) Verify that Stack(SG) sends Heartbeat Ack to the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<--------------Heartbeat-----------		   
			--------------Heartbeat Ack-------->		   

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.16 ASPM_V_SG_16 : Optional parameter handling
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that IUA stack
is able to handle an IUA message with any optional parameter. 
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.2, 3.3.2.5
---------------------------------------------------------------
Test Configuration :- A

Vikas & Gayatri	                                              [Page 45]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1 and SG. ASP1 is in ASP-DOWN state.
---------------------------------------------------------------
Test Description :

   a) Send ASPUP message with info string from the peer.

   b) Verify that the SG sends an ASPUP ACK and Notify(AS-Inactive)
      message to the peer.

   c) Send an ASPAC message from peer with info string and 
      interface identifier parameter.

   d) Verify that SG sends an ASPAC ACK and Notify(AS-ACTIVE) message
      to the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPUP-------------				
			---------------ASPUP-ACK----------->		 	
			----------NOTIFY (AS-INACTIVE)----->								

		ASP and AS state moved to ASP-INACTIVE/AS-INACTIVE

			<---------------ASPAC-------------				
			--------------ASPAC-ACK----------->		 	
			----------NOTIFY (AS-ACTIVE)----->

		ASP and AS state moved to ASP-ACTIVE/AS-ACTIVE

---------------------------------------------------------------

---------------------------------------------------------------
3.1.3.17 ASPM_V_SG_17 : ASPAC/ASPIA message handling when it contains
no interface identifier
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the
ASPAC/ASPIA message handling when it contains no interface identifier.
----------------------------------------------------------------
Reference : RFC 3057, Section 3.3.2.5, 3.3.2.6, 3.3.2.7, 3.3.2.8 
---------------------------------------------------------------
Test Configuration :- C
AS1 and AS2 can serve traffic for either integer or text based

Vikas & Gayatri	                                              [Page 46]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

identifiers.
---------------------------------------------------------------- 
Pre-requirement Condition :  SCTP Association is established 
between ASP1 and SG. ASP1 is in ASP-INACTIVE state in both AS1
and AS2.
---------------------------------------------------------------
Test Description :

   a) Send an ASPAC message from peer to SG without any interface 
      identifier.

   b) Verify that SG sends an ASPAC ACK and two Notify (AS-Active)
      in response, corresponding to AS1 and AS2.
      Verify that state of ASP1 in AS1 and AS2 is now ASP-ACTIVE.

   c) Verify that it is possible to send data for all interface 
      Integers.  
      
   d) Send an ASPIA message from peer to SG without any interface 
      identifier.

   e) Verify that SG sends an ASPIA ACK and two Notify (AS-Pending)
      in response, corresponding to AS1 and AS2.
      Verify that state of ASP1 in AS1 and AS2 is now ASP-INACTIVE.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPAC--------------				
				(Without Interface Identifier)
			----------------ASPAC-ACK----------->
				(for both the AS)
			----------NOTIFY (AS-Active)-------->		 	
					(for AS1)
			----------NOTIFY (AS-Active)-------->		 	
					(for AS2)
			
			ASP1 is now ASP-ACTIVE in both AS1 and AS2
			
			Data exchange for both all IID's

			<----------------ASPIA--------------				
				(Without Interface Identifier)
			----------------ASPIA-ACK----------->
				(for both the AS)
			----------NOTIFY (AS-Pending)------>		 	
					(for AS1)
			----------NOTIFY (AS-Pending)------>		 	
					(for AS2)
			
			ASP1 is now ASP-INACTIVE in both AS1 and AS2
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 47]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

3.1.4 Invalid ASPM cases when SG is Under Test

---------------------------------------------------------------
3.1.4.1 ASPM_I_SG_01 : Retransmitted ASPSM Messages received 
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle a retransmitted ASPSM (ASPUP/ASPDN)
message.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-DOWN state.
---------------------------------------------------------------
Test Description :

a) Send an ASPUP message from peer to SG.

b) Verify that the SG sends an ASPUP ACK and Notify (AS-INACTIVE) to
   the peer(ASP1).
   Verify that the ASP and AS states are moved to ASP-INACTIVE/
   AS-INACTIVE.

c) Again send an ASPUP message from peer to SG.

d) Verify that the SG sends an ASPUP ACK to the peer(ASP1).

e) Send an ASPDN message from the peer to SG.

f) Verify that the SG sends an ASPDN-ACK message to the peer.
   Verify that the ASP and AS states are moved to ASP-DOWN/AS-DOWN.

g) Again send an ASPDN message from peer to SG.

h) Verify that the SG sends an ASPDN ACK to the peer(ASP1).
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPUP-------------				
			---------------ASPUP-ACK----------->		 	
			----------NOTIFY (AS-INACTIVE)----->								

		ASP and AS state move to ASP-INACTIVE/AS-INACTIVE

Vikas & Gayatri	                                              [Page 48]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			<----------------ASPUP-------------				
			---------------ASPUP-ACK----------->		 	

			<----------------ASPDN-------------				
			---------------ASPDN-ACK----------->		 	

		ASP and AS state move to ASP-DOWN/AS-DOWN
			
			<----------------ASPDN-------------				
			---------------ASPDN-ACK----------->		 	

---------------------------------------------------------------

---------------------------------------------------------------
3.1.4.2 ASPM_I_SG_02 : Retransmitted ASPTM Message received 
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle a retransmitted ASPTM (ASPAC/ASPIA)
message.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-INACTIVE state.
---------------------------------------------------------------
Test Description :

a) Send an ASPAC message from the peer to SG.

b) Verify that the SG sends an ASPAC-ACK and NOTIFY (AS-ACTIVE)
   message to the peer.
   Verify that the ASP and AS states are moved to ASP-ACTIVE/
   AS-ACTIVE.

c) Again, send an ASPAC message from the peer to SG.

d) Verify that the SG sends an ASPAC-ACK message to the peer.

e) Send an ASPIA message from the peer to SG.

f) Verify that the SG sends an ASPIA ACK and NOTIFY (AS-PENDING)
   message to the peer.

g) Verify that after pending timer expiry, SG sends a 
   Notify(AS-INACTIVE) message to the peer.
   Verify that the ASP and AS states are moved to ASP-INACTIVE/
   AS-INACTIVE.

Vikas & Gayatri	                                              [Page 49]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

h) Again, send an ASPIA message from the peer to SG.

i) Verify that the SG sends an ASPIA-ACK message to the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<---------------ASPAC-------------				
			--------------ASPAC-ACK----------->		 	
			----------NOTIFY (AS-ACTIVE)----->

		ASP and AS state move to ASP-ACTIVE/AS-ACTIVE

			<---------------ASPAC-------------				
			--------------ASPAC-ACK----------->		 	

			<---------------ASPIA-------------				
			--------------ASPIA-ACK----------->		 	
			----------NOTIFY (AS-PENDING)----->

		Pending timer starts

		Pending timer expires

			----------NOTIFY (AS-INACTIVE)---->

		ASP and AS state move to ASP-INACTIVE/AS-INACTIVE
			
			<---------------ASPIA-------------				
			--------------ASPIA-ACK----------->		 	
---------------------------------------------------------------

---------------------------------------------------------------
3.1.4.3 ASPM_I_SG_03 : ASPUP message handling in ACTIVE state of ASP
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle ASPUP in ACTIVE state of ASP.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- C
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1,ASP2 and SG. ASP1 is in ASP-ACTIVE state in both AS1 and AS2.
---------------------------------------------------------------
Test Description :

Vikas & Gayatri	                                              [Page 50]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

a) Send an ASPUP message from peer to SG.

b) Verify that the SG sends an ASPUP ACK and an Error(Unexpected
   message) to the peer(ASP1).

c) Verify that the state of ASP1 is moved to ASP-INACTIVE in
   both AS1 and AS2.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPUP-------------				
			---------------ASPUP-ACK----------->		 	
			-----ERROR(Unexpected Message)----->								

---------------------------------------------------------------

---------------------------------------------------------------
3.1.4.4 ASPM_I_SG_04 : ASPAC message handling in DOWN state of ASP
---------------------------------------------------------------
Test Objective: The main aim of this scenario is to verify that 
IUA stack is able to handle ASPAC in DOWN state of ASP.
----------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and SG. ASP1 is in ASP-DOWN state.
---------------------------------------------------------------
Test Description :

a) Send an ASPAC message from peer to SG.

b) Verify that the SG Discards the message.

c) SG may silently discard the message or also send an
   Error(Unexpected Message) to the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPAC-------------				
			-----ERROR(Unexpected Message)----->								

---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 51]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.1.4.5 ASPM_I_SG_05 : Traffic Mode Parameter Missing in ASPAC
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that IUA stack
is able to handle an ASPAC message received without the mandatory 
Traffic Handling mode parameter.
---------------------------------------------------------------
Reference : RFC 3057, Section 4.3
---------------------------------------------------------------
Test Configuration :- A
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1 and SG. ASP1 is in ASP-INACTIVE state.
---------------------------------------------------------------
Test Description :

 a) Send an ASPAC message from peer without the mandatory Traffic 
      Mode parameter.

 b) Verify that SG rejects the message and ASP remains in
      ASP-INACTIVE state.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP)

			<----------------ASPAC-------------				

		Message Rejected

---------------------------------------------------------------

3.2 QPTM Messages

3.2.1 Valid QPTM cases when ASP is Under Test

---------------------------------------------------------------
3.2.1.1 QPTM_V_ASP_01 : Link Establishment Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the Link
Establishment and Data Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1

Vikas & Gayatri	                                              [Page 52]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

 a) Invoke Establish Request primitive from SU. 
    Verify that an Establish request message is sent from ASP1 to 
    the peer.

 b) Send an Establish Confirm message from peer to the ASP side.
    Verify that an Establish confirm primitive is invoked at ASP side.

 c) Invoke the Data request primitive from SU.
    Verify that a Data request message is sent from ASP1 to the peer.

 d) Send a Data Indication message from peer to the ASP side.
    Verify that a Data Indication primitive is given to SU. 

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

Establish Request 
Primitive
-------------------->
			--------Establish Request----------->
			<-------Establish Confirm------------	
Establish Confirm 
Primitive
<--------------------

Data request
Primitive
-------------------->	--------Data Request------------------>
			<-------Data Indication----------------

Data Indication
Primitive
<--------------------
---------------------------------------------------------------

---------------------------------------------------------------
3.2.1.2 QPTM_V_ASP_02 : Link Release Request/Confirm Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the Link

Vikas & Gayatri	                                              [Page 53]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Release Procedures with various reasons.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

 a) Invoke Release Request primitive from SU with reason as 
    RELEASE_MGMT. 
    Verify that a Release request message with reason as RELEASE_MGMT
    is sent from ASP1 to the peer.

 b) Send a Release Confirm message from peer to the ASP side.
    Verify that a Release confirm primitive is invoked at ASP side.

 c) Verify the same for reasons RELEASE_DM, RELEASE_OTHER.
 
----------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

Release Request 
Primitive
-------------------->
			--------Release Request----------->
				(reason as RELEASE_MGMT)
			<-------Release Confirm------------	
Release Confirm 
Primitive
<--------------------

---------------------------------------------------------------

---------------------------------------------------------------
3.2.1.3 QPTM_V_ASP_03 : Link Release/Establish Indication 
Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the
Release/Establish Indication Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 

Vikas & Gayatri	                                              [Page 54]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

 a) Invoke Establish Request primitive from SU. 
    Verify that an Establish request message is sent from ASP1 to 
    the peer.

 b) Send a Release Indication message from peer with reason as 
    RELEASE_MGMT to the ASP side.
    Verify that a Release Indication primitive is invoked at ASP side.

 c) Verify the same for reasons RELEASE_PHY, RELEASE_DM, RELEASE_OTHER.
 
 d) Send an Establish Indication message from peer. 
    Verify that an Establish Indication primitive is given to SU.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

Establish Request 
Primitive
-------------------->
			--------Establish Request----------->
			<-------Release Indication-----------	
				(RELEASE_MGMT)
Release Indication 
Primitive
<--------------------

			<--------Establish Indication-------
Establish Indication 
Primitive
<--------------------

---------------------------------------------------------------

---------------------------------------------------------------
3.2.1.4 QPTM_V_ASP_04 : Unitdata Procedures
---------------------------------------------------------------
Test Objective: To verify Unitdata Procedures
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- D

Vikas & Gayatri	                                              [Page 55]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

 a) Invoke Unitdata Request primitive from SU. 
    Verify that a Unitdata request message is sent from ASP1 to the
    peer.

 b) Verify that message padding is proper.

 c) Send a Unit Indication message from peer to the ASP side.
    Verify that a Unitdata Indication primitive is invoked at ASP
    side.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

Unitdata Request 
Primitive
-------------------->
			--------Unitdata Request----------->
			<-------Unitdata Indication---------	
Unitdata Indication 
Primitive
<--------------------

---------------------------------------------------------------

3.2.2 Valid QPTM cases when SG is Under Test

---------------------------------------------------------------
3.2.2.1 QPTM_V_SG_01 : Link Establishment Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the 
Establishment and Data Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively.
---------------------------------------------------------------- 

Vikas & Gayatri	                                              [Page 56]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Description :

 a) Send an Establish request message from peer to SG.
    Verify that an Establish request primitive is invoked at 
    SG side.
        
 b) Invoke Establish Confirm primitive from SG. 
    Verify that an Establish Confirm message is sent to the peer.

 c) Send a Data Request message from peer to the ASP side.
    Verify that Data Request primitive is invoked. 

 d) Invoke the Data Indication primitive from SG.
    Verify that a Data Indication message is sent from SG to the
    peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<--------Establish Request-----------
Establish Request 
Primitive
<--------------------

Establish Confirm 
Primitive
-------------------->

			-------Establish Confirm------------>	

			<--------Data Request------------------
Data request
Primitive
<--------------------

Data Indication
Primitive
-------------------->
			-------Data Indication---------------->

---------------------------------------------------------------

---------------------------------------------------------------
3.2.2.2 QPTM_V_SG_02 : Link Release Request/Confirm Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the Link

Vikas & Gayatri	                                              [Page 57]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Release Procedures with various reasons.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively.
---------------------------------------------------------------- 

Test Description :

 a) Send a Release request message with reason as RELEASE_MGMT from
    peer to the SG.
    Verify that a Release request primitive is invoked at SG side.
 
 b) Invoke Release confirm primitive from NIF. 
    Verify that a Release Confirm message is sent to the peer.

 c) Verify the same for reasons RELEASE_DM, RELEASE_OTHER
 
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<--------Release Request-----------
				(reason as RELEASE_MGMT)

Release Request 
Primitive
<--------------------

Release Confirm 
Primitive
-------------------->
			-------Release Confirm------------>	

---------------------------------------------------------------

---------------------------------------------------------------
3.2.2.3 QPTM_V_SG_03 : Link Release/Establish Indication Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the
Release/Establish Indication Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- A

Vikas & Gayatri	                                              [Page 58]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively.
---------------------------------------------------------------- 
Test Description :

 a) Send an Establish Request message from the peer to SG.
    Verify that an Establish Request primitive is invoked at the SG.

 b) Invoke Release Indication primitive from NIF with reason as 
    RELEASE_MGMT. 
    Verify that a Release Indication message is sent to the peer with
    reason as RELEASE_MGMT.
 
 c) Verify the same for reasons RELEASE_PHY, RELEASE_DM, RELEASE_OTHER
 
 d) Invoke Establish Indication primitive from NIF. 
    Verify that an Establish Indication message is sent to the peer.
 
---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<--------Establish Request-----------
Establish Request 
Primitive
<--------------------

Release Indication 
Primitive
-------------------->

			-------Release Indication----------->	
				(RELEASE_MGMT)

Establish Indication 
Primitive
-------------------->

			--------Establish Indication-------->

---------------------------------------------------------------

---------------------------------------------------------------
3.2.2.4 QPTM_V_SG_04 : Unitdata Procedures
---------------------------------------------------------------
Test Objective: To verify Unitdata Procedures

Vikas & Gayatri	                                              [Page 59]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively.
---------------------------------------------------------------- 

Test Description :

 a) Invoke Unitdata Indication primitive from NIF. 
    Verify that a Unitdata Indication message is sent to the peer.

 b) Send a Unit Request message from peer to the SG.
    Verify that a Unitdata Request primitive is given to NIF.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

Unitdata Indication 
Primitive
-------------------->
			--------Unitdata Indication----------->
			<-------Unitdata Request---------------	

Unitdata Request 
Primitive
<--------------------

---------------------------------------------------------------

---------------------------------------------------------------
3.2.2.5 QPTM_V_SG_05 : Mapping Interface Identifier within multiple 
	      Associations/Streams
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the mapping 
of Interface Identifier to Association/Stream.
----------------------------------------------------------------
Reference : RFC 3057, Section 1.5.1
---------------------------------------------------------------
Test Configuration :- B
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP association (with Multiple Streams)
is established between ASP1,ASP2 and SG. ASP1,ASP2 are in ASP-ACTIVE 
state. AS is in Loadshare mode. AS is having multiple interface
identifiers say 1-5.
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 60]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Description :

   a) Send a Unitdata Indication message from SG for an
      IID (say 1) by invoking the corresponding primitive.
      Check the Association(X) and Stream number(y) being
      used for sending data.

   b) Now send a Unitdata Indication message from SG for
      another IID (say 2) by invoking the corresponding primitive.
      Check the Association(P) and Stream number (q) being used 
      for sending data. 
   
   c) Algorithm for mapping data to different Association/Stream
      within an AS is implementation dependent.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			------Unit Data Indication-------->	
			    (Association id X Stream y)	

			------Unit Data Indication-------->	
			    (Association id P Stream q)	

---------------------------------------------------------------

3.3 MGMT Messages

3.3.1 MGMT cases when ASP is Under Test
---------------------------------------------------------------
3.3.1.1 MGMT_V_ASP_01 : TEI Status Request/Confirm Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the 
TEI Request/Confirm Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.3
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

   a) Invoke an M-TEI STATUS request API from the LM(ASP). 
      Verify that a TEI Status request message is sent to the peer.

Vikas & Gayatri	                                              [Page 61]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   
   b) Send TEI STATUS Confirm message from peer with status as 
      ASSIGNED.
      Verify that a TEI Status confirm primitive is given to LM.

   c) Invoke an M-TEI STATUS request API from the LM(ASP). 
      Verify that a TEI Status request message is sent to the peer.
   
   d) Send TEI STATUS Confirm message from peer with status as 
      UNASSIGNED.
      Verify that a TEI Status confirm primitive is given to LM.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

--------M-TEI-STATUS--->
	Request
			---------TEI Status Request-------->		 	
			<--------TEI Status Confirm---------
				(ASSIGNED)
<-------M-TEI-STATUS---
	Confirm

--------M-TEI-STATUS--->
	Request
			---------TEI Status Request-------->		 	
			<--------TEI Status Confirm---------
				(UNASSIGNED)
<-------M-TEI-STATUS---
	Confirm

---------------------------------------------------------------

---------------------------------------------------------------
3.3.1.2 MGMT_V_ASP_02 : TEI Status Query/Indication Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the 
TEI Query/Indication Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.3
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

Vikas & Gayatri	                                              [Page 62]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

   a) Invoke an M-TEI QUERY request API from the LM(ASP). 
      Verify that a TEI Status Query request message is sent to the
      peer.
   
   b) Send TEI STATUS Indication message from peer with status as 
      ASSIGNED.
      Verify that a TEI Status indication primitive is given to LM.

   c) Invoke an M-TEI QUERY request API from the LM(ASP). 
      Verify that a TEI Status Query request message is sent to the
      peer.
   
   d) Send TEI STATUS Indication message from peer with status as 
      UNASSIGNED.
      Verify that a TEI Status indication primitive is given to LM.

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

--------M-TEI-QUERY--->
	Request
			---------TEI Query Request--------->		 	
			<-----TEI Status Indication--------	
				(ASSIGNED)
<-------M-TEI-STATUS---
	Indication

--------M-TEI-QUERY--->
	Request
			---------TEI Query Request--------->		 	
			<-----TEI Status Indication--------	
				(UNASSIGNED)
<-------M-TEI-STATUS---
	Indication
---------------------------------------------------------------

3.3.2 MGMT cases when SG is Under Test

---------------------------------------------------------------
3.3.2.1 MGMT_V_SG_01 : TEI Status Request/Confirm Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the 
TEI Request/Confirm Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.3
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 63]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

   a) Send TEI STATUS Request message from peer.
      Verify that a TEI Status request primitive is given to LM.

   b) Invoke an M-TEI STATUS confirm API with status as ASSIGNED 
      from the LM(SG). 
      Verify that a TEI Status confirm message with status as ASSIGNED
      is sent to the peer.
   
   c) Send TEI STATUS Request message from peer.
      Verify that a TEI Status request primitive is given to LM. 

   d) Invoke an M-TEI STATUS confirm API with status as UNASSIGNED 
      from the LM(SG). 
      A TEI Status confirm message with status as UNASSIGNED is sent
      to the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<---------TEI Status Request--------		 	
<-------M-TEI-STATUS---
	Request

-------M-TEI-STATUS--->
	Confirm
			--------TEI Status Confirm--------->
				(ASSIGNED)

			<---------TEI Status Request--------		 	
<-------M-TEI-STATUS---
	Request

-------M-TEI-STATUS--->
	Confirm
			--------TEI Status Confirm--------->
				(UNASSIGNED)

---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 64]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.3.2.2 MGMT_V_SG_02 : TEI Status Query/Indication Procedures
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the 
TEI Query/Indication Procedures.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.3
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. ASP1 is in ASP-ACTIVE state.
---------------------------------------------------------------- 

Test Description :

   a) Send TEI QUERY Request message from peer.
      Verify that a TEI Query request primitive is given to LM.

   b) Invoke an M-TEI STATUS Indication API with status as ASSIGNED 
      from the LM(SG). 
      Verify that a TEI Status Indication message with status as 
      ASSIGNED is sent to the peer.
   
   c) Send TEI QUERY Request message from peer.
      Verify that a TEI Query request primitive is given to LM.

   d) Invoke an M-TEI STATUS Indication API with status as UNASSIGNED 
      from the LM(SG). 
      Verify that a TEI Status Indication message with status as
      UNASSIGNED is sent to the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<---------TEI Query Request--------		 	
<-------M-TEI-QUERY---
	Request

-------M-TEI-STATUS--->
	Indication
			--------TEI Status Indication--------->
				(ASSIGNED)

			<---------TEI Query Request--------		 	
<-------M-TEI-QUERY---
	Request

Vikas & Gayatri	                                              [Page 65]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

-------M-TEI-STATUS--->
	Indication
			--------TEI Status Indication--------->
				(UNASSIGNED)

---------------------------------------------------------------

3.3.3 Invalid scenario handling when SG is under test

---------------------------------------------------------------
3.3.3.1 MGMT_I_SG_01 : Invalid Version Error
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG
returns an Error message if it receives any message with an invalid 
Version.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state.
---------------------------------------------------------------- 

Test Description :

   a) Send an ASPUP message from peer to the SG with an invalid
      version say 2.

   b) Verify that SG generates an Error message with reason as 
      "Invalid Version". Verify that ASP is in ASP-DOWN state.  

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<---------------ASPUP----------------		 	
				     (Version 2)	

			--------ERROR (Invalid Version)----->

---------------------------------------------------------------

---------------------------------------------------------------
3.3.3.2 MGMT_I_SG_02 : Invalid Interface identifier

Vikas & Gayatri	                                              [Page 66]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG
returns an Error Message for all the interface identifiers for
which the AS is not configured.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
AS1 at SG is handling traffic for say IID range 1-5
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state
respectively.
---------------------------------------------------------------- 

Test Description :

   a) Send An ASPAC message from peer to the SG for IID's (1-10).
   
   b) Verify that SG sends an ASPAC ACK (IID 1-5)and Notify(AS-Active)
      in response.
      Verify that ASP1 and AS1 states are moved to ASP-ACTIVE/
      AS-ACTIVE.	
   
   c) Also Verify that SG sends error messages for IID's 6-10 with
      reason as 2 (Invalid Interface Identifier).
      The diagnostic Information must contain the common and IUA 
      message headers of the offending message so that the Invalid
      Interface Identifier can be identified.
      
   d) Send a Unit Data Request message from peer to the SG.
      Verify that a Unitdata Request primitive is invoked at SG.

   e) Invoke the primitive for Unit Data Indication Message from NIF
      for say IID 1.
      Message should be sent to ASP1 in AS1.

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------ASPAC (IID 1-10)----------				
			-----------ASPAC-ACK (IID 1-5)------->		 	

			-----------NOTIFY (AS-Active)-------->
			    
			-----------ERROR (IID 6)------------->
			-----------ERROR (IID 7)------------->
			-----------ERROR (IID 8)------------->
			-----------ERROR (IID 9)------------->
			-----------ERROR (IID 10)------------>

			<-----------Unitdata Request---------

Vikas & Gayatri	                                              [Page 67]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			------------Unitdata Indication----->

---------------------------------------------------------------

---------------------------------------------------------------
3.3.3.3 MGMT_I_SG_03 : Unsupported Message Class/Type
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG
returns an Error Message if an Unsupported Message Class/Type
is received in a message.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state.
---------------------------------------------------------------- 
Test Description :

   a) Send a message from peer to the SG with message class as 7.
   
   b) Verify that SG sends an Error Message with reason as 
      "Unsupported Message Class".
   
   c) Send a message from peer to the SG with message class as 3
      and message type as 9.
         
   d) Verify that SG sends an Error Message with reason as 
      "Unsupported Message Type".

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------Message (Class 7)----------				
			-----------ERROR--------------------->		 	
			    (Unsupported Message Class)

			<----------Message (Type 9)----------				
			-----------ERROR--------------------->		 	
			    (Unsupported Message Type)

---------------------------------------------------------------

---------------------------------------------------------------
3.3.3.4 MGMT_I_SG_04 : Unsupported Traffic Handling mode

Vikas & Gayatri	                                              [Page 68]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG
returns an Error Message if an Unsupported Traffic Handling 
mode is received in a message.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state.
AS is configured in override mode.
---------------------------------------------------------------- 

Test Description :

   a) Send a ASPAC message from peer to SG with Traffic Handling
      Mode as "Loadshare".
   
   b) Verify that SG sends an Error Message with reason as 
      "Unsupported Traffic Handling Mode".

   Also Verify that the same Error message is sent to the peer if the
   SG doesn't support loadsharing.
   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------ASPAC (Loadshare)----------				
			-----------ERROR--------------------->		 	
			  (Unsupported Traffic handling Mode)

---------------------------------------------------------------

---------------------------------------------------------------
3.3.3.5 MGMT_I_SG_05 : Unexpected Message
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG 
returns an Error Message if a QPTM message is received in Inactive
state of ASP.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state. 
---------------------------------------------------------------- 

Test Description :

   a) Send a Unitdata Request message from peer to SG.

Vikas & Gayatri	                                              [Page 69]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

      
   b) Verify that SG sends an Error Message with reason as 
      "Unexpected Message".

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------Unitdata -----------------				
			-----------ERROR--------------------->		 	
			  (Unexpected Message)

---------------------------------------------------------------

---------------------------------------------------------------
3.3.3.6 MGMT_I_SG_06 : Invalid Stream Identifier
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG 
returns an Error Message if a Management message is received on
a stream other than 0.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. SCTP Association has multiple streams. 
AS/ASP1 is in AS-DOWN/ASP-DOWN state. 
---------------------------------------------------------------- 

Test Description :

   a) Send an ASPUP message from peer to SG on a stream other 
      than 0.
      
   b) Verify that SG sends an Error Message with reason as 
      "Invalid stream identifier".

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------ASPUP (Stream 1)-----------				
			-----------ERROR--------------------->		 	
			  (Invalid Stream Identifier)

---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 70]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.3.3.7 MGMT_I_SG_07 : Unsupported Interface Identifier Type
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG 
returns an Error Message if it doesn't support text based interface
Identifiers.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state. 
---------------------------------------------------------------- 

Test Description :

   a) Send an ASPAC message having text based interface identifier.
      
   b) Verify that SG sends an Error Message with reason as 
      "Unsupported Interface Identifier Type".

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------ASPAC (Text Based)---------				
			-----------ERROR--------------------->		 	
			  (Unsupported Interface Identifier Type)

---------------------------------------------------------------

---------------------------------------------------------------
3.3.3.8 MGMT_I_SG_08 : Refused - Management Blocking
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG 
returns an Error Message if the ASP is locked out for management 
reasons.
---------------------------------------------------------------
Reference : RFC 3057, Section 3.3.3.1
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state.
ASP is locked out for management reasons.
---------------------------------------------------------------- 

Test Description :

   a) Send an ASPUP message from peer to SG.

Vikas & Gayatri	                                              [Page 71]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

      
   b) Verify that SG sends an Error Message with reason as 
      "Refused - Management Blocking".

   c) Verify that AS/ASP state is still AS-DOWN/ASP-DOWN.

   d) Unlock the ASP.

   e) Send an ASPUP message from peer to SG.
      
   f) Verify that SG sends an ASPUP ACK and Notify (AS-Inactive)
      message to the peer.

   ---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------ASPUP --------------------				
			-----------ERROR--------------------->		 	
			  (Refused - Management Blocking)

			<----------ASPUP --------------------				
			-----------ASPUP-ACK------------------>		 	
			-----------Notify (AS-Inactive)------->		 	

---------------------------------------------------------------

3.4 ASP Identifier Cases

---------------------------------------------------------------
3.4.1.1 ASPI_V_ASP_01 : ASP Identifier Case
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify ASP
identifier based routing.
---------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.7
---------------------------------------------------------------
Test Configuration :- B (Stack to Stack)
--------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established 
between ASP1, ASP2 and SG. AS is in Loadshare mode. ASP1 and ASP2
are in ASP-DOWN state.
---------------------------------------------------------------
Test Description :

Vikas & Gayatri	                                              [Page 72]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

ASPUP PROCEDURES
   a) Invoke an M-ASP-UP request from LM for ASP1.
   b) ASPUP message sent from ASP1 containing ASP identifier.
   c) SG sends ASPUP ACK and Notify message.
   d) ASP Id should be present in Notify Message. 
   e) State of ASP1 in AS1 is now marked ASP-INACTIVE. 

   f) Invoke an M-ASP-UP request from LM for ASP2.
   g) ASPUP message sent from ASP2 containing ASP identifier.
   h) SG sends ASPUP ACK message.
   i) State of ASP2 in AS1 is now marked ASP-INACTIVE. 

ASP ACTIVE PROCEDURES
   a) Invoke an M-ASP-ACTIVE request from LM for ASP1.
   b) An ASPAC message is sent to the SG.
   c) SG sends an ASPAC ACK to ASP1.
   d) Also SG sends a Notify (AS-Active) message to ASP2 and ASP1.
   e) State of ASP1 in AS1 is now marked ASP-ACTIVE. 

   f) Invoke an M-ASP-ACTIVE request from LM for ASP2.
   g) An ASPAC message is sent to the SG.
   h) SG sends an ASPAC ACK to ASP2.
   i) State of ASP2 in AS1 is now marked ASP-ACTIVE. 

UNIT DATA PROCEDURES
   a) Send a Unit Data Request Message from ASP1 to SG.
   b) Send a Unit Data Request Message from ASP2 to SG.
   c) Send multiple Unit Data Indication Messages from SG.
      They will be sent to ASP1 or ASP2 according to the Loadshare 
      Algorithm. For example if the Algorithm is round robin, first
      data message may be sent to ASP1, second to ASP2 and so on.
   
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP		SG		LM/NIF
--------M-ASP-UP-------->
	Request (ASP1)
			-------ASPUP-------->				
			<------ASPUP-ACK-----		 	
<-------M-ASP-UP---------		   
	confirm	(ASP1)			   
			<------NOTIFY--------
			    (AS-Inactive)

			AS1/ASP1 state is now AS-INACTIVE/ASP-INACTIVE
--------M-ASP-UP-------->
	Request (ASP2)
			-------ASPUP-------->				
			<------ASPUP-ACK-----		 	
<-------M-ASP-UP---------		   
	confirm	(ASP2)			   
								

Vikas & Gayatri	                                              [Page 73]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

			ASP2 state is now ASP-INACTIVE
-------M-ASP-ACTIVE----->
	Request (ASP1)
			----ASPAC (IID vikas)-->				
			<---ASPAC-ACK (IID vikas)--		 	
<------M-ASP-ACTIVE-----		   
	Confirm	(ASP1)			   
			<------NOTIFY--------
			    (AS-Active)
			
			AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE
-------M-ASP-ACTIVE----->
	Request (ASP2)
			----ASPAC (IID vikas)----->				
			<---ASPAC-ACK (IID vikas)--		 	
<------M-ASP-ACTIVE-----		   
	Confirm	(ASP2)			   
			ASP2 state is now ASP-ACTIVE
			-------Unit Data----->
				Request
			<-------Unit Data-----
				Indication
			<-------Unit Data-----
				Indication

---------------------------------------------------------------

---------------------------------------------------------------
3.4.2.1 ASPI_I_SG_01 : ASP Identifier Required
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG 
returns an Error Message if ASP identifier is required and ASPUP
message doesn't contain the same.
---------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.19
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. 
---------------------------------------------------------------- 

Test Description :

   a) Send an ASPUP message from peer to SG without the ASP identifier
      parameter.
      
   b) Verify that SG sends an Error Message with reason as 
      "ASP Identifier Required".

---------------------------------------------------------------
Expected Message Sequence

Vikas & Gayatri	                                              [Page 74]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

LM/NIF			SG				Peer(ASP) 

			<----------ASPUP --------------------				
			-----------ERROR--------------------->		 	
			  (ASP Identifier Required)

---------------------------------------------------------------

---------------------------------------------------------------
3.4.2.2 ASPI_I_SG_02 : Invalid ASP Identifier
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that SG 
returns an Error Message if an invalid ASP identifier is received
in an ASPUP message.
---------------------------------------------------------------
Reference : IUA Outstanding Issues Section 3.19
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. 
---------------------------------------------------------------- 

Test Description :

   a) Send an ASPUP message from peer to SG with an invalid ASP 
      identifier parameter.
      
   b) Verify that SG sends an Error Message with reason as 
      "Invalid ASP Identifier".

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

			<----------ASPUP --------------------				
			-----------ERROR--------------------->		 	
			  (Invalid ASP Identifier)

---------------------------------------------------------------

3.5 Miscellaneous Cases

3.5.1 MISC cases when SG is Under Test
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 75]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

3.5.1.1 MISC_V_SG_01 : SCTP Restart Handling
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the SCTP 
Restart handling by the IUA stack. 
----------------------------------------------------------------
Reference : RFC 3057
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP association is established between 
ASP1 and SG. ASP1 is in ASP-ACTIVE state. 
---------------------------------------------------------------
Test Description :

  a) Restart the peer(ASP) side (IUA stack). 

  b) Verify that an SCTP_RESTART indication is invoked at the
     SG side.
  
  c) Verify that ASP is now marked as ASP-DOWN at SG side.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

		ASP is in ASP-ACTIVE state
		
		ASP side (IUA stack) restarts
		SCTP association established.
		An SCTP_RESTART indication given to 
		IUA by SCTP at SG side
		ASP is marked ASP-DOWN.

---------------------------------------------------------------

---------------------------------------------------------------
3.5.1.2 MISC_V_SG_02 : SCTP Comm-lost Handling
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify the SCTP 
Comm-Lost handling by the IUA stack. 
----------------------------------------------------------------
Reference : RFC 3057
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP association is established between 
ASP1 and SG. ASP1 is in ASP-ACTIVE state. 
---------------------------------------------------------------
Test Description :

  a) Kill the ASP side (IUA stack).

Vikas & Gayatri	                                              [Page 76]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

  b) After some time SCTP(SG) detects association failure
     via the Heartbeat procedures.
  
  c) SCTP invokes an SCTP_CDI indication towards IUA.
  
  d) Verify that ASP is brought to ASP-DOWN State.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

		
		IUA(at SG) receives a CDI indication from SCTP
		ASP is brought to ASP-DOWN state at SG.

---------------------------------------------------------------

---------------------------------------------------------------
3.5.1.3 MISC_V_SG_03 : Establishing SCTP Association from SG
---------------------------------------------------------------
Test Objective: The main aim of this case is to verify that it is
possible to establish association from SG.
----------------------------------------------------------------
Reference : RFC 3057
---------------------------------------------------------------
Test Configuration :- A
---------------------------------------------------------------- 
Pre-requirement Condition : IUA stack is Initialized. SG is client 
and ASP is server.
---------------------------------------------------------------
Test Description :

a) Invoke M-SCTP Establish Request from SG.

b) Verify that an SCTP Association is established with the peer.

---------------------------------------------------------------
Expected Message Sequence

LM/NIF			SG				Peer(ASP) 

M-SCTP ESTABLISH
request
----------------------->
			SCTP Association Established
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 77]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

---------------------------------------------------------------
3.5.1.4 MISC_V_SG_04 : Payload Protocol id as 1
---------------------------------------------------------------
Test Objective: To verify that payload protocol id 1 is filled by 
IUA when sending any message
---------------------------------------------------------------
Reference : RFC 3057, Section 7.1
---------------------------------------------------------------
Test Configuration :- D
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP Association is established between
ASP and SG.
---------------------------------------------------------------- 

Test Description :

a) Invoke an M-ASP-UP request from LM for ASP1.
   Verify that an ASPUP message is sent to the peer.

b) Verify that the payload protocol identifier filled by IUA 
   in SCTP payload is 1.
   
---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP				Peer(SG) 

--------M-ASP-UP---------->
	Request
			---------------ASPUP-------------->				

---------------------------------------------------------------

3.5.2 MISC cases when ASP is Under Test
---------------------------------------------------------------
3.5.2.1 MISC_V_ASP_01 :  Multiple SG Scenario
---------------------------------------------------------------
Test Objective: The main aim of this case is to check the ability
of the IUA stack to reroute Data to the alternate SG if an 
association to one SG fails.
----------------------------------------------------------------
Reference : RFC 3057
---------------------------------------------------------------
Test Configuration :- G (Stack to Stack)
---------------------------------------------------------------- 
Pre-requirement Condition : SCTP association is established between 
ASP1 and SG1, SG2. ASP1 is in ASP-ACTIVE state via both the SG's. 
---------------------------------------------------------------

Vikas & Gayatri	                                              [Page 78]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

Test Description :

a) SG1 or Association between ASP1 and peer(SG1) goes down.
   In other words, IUA receives a SCTP_CDI indication from SCTP
   corresponding to the association for SG1.

b) Invoke Unitdata request primitive from ASP.
   ASP should be able to route the data via peer(SG2).

---------------------------------------------------------------
Expected Message Sequence

LM/SU			ASP		SG1		SG2

<-------SCTP_COMM_LOST-------
        (with SG1)
			-----------Unit Data Request------->				  
---------------------------------------------------------------

4. Acknowledgements

The authors would like to thank Ken Morneault, Dipak Bash, Akhtar Iqbal,
Manish Sharma, Sandeep Mahajan, Anshoo Sharma, A Anuradha for their 
insightful comments and suggestions.

                

            
5. References   
            
[1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System
     No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer -
     General Aspects'
            

[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H.,
       Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
       "Stream Control Transmission Protocol", RFC 2960, October 2000.

   
[3] IUA (ISDN Q.921-User Adaptation Layer) RFC 3057

[4] IUA(RFC 3057)Outstanding Issues
     draft-ietf-sigtran-iua-imp-guide-02.txt. Morneault K.

          

Vikas & Gayatri	                                              [Page 79]

Internet Draft         IUA Conformance Test Plan	       Dec 2002

6. Authors' Address   
                
             Vikas Bhola
	     Gayatri Singla
	     
             Hughes Software Systems   
             Electronic City, Plot 31,  
             Sector 18 , Gurgaon 122015  
             Haryana, India  
             Email:  vbhola@hss.hns.com 
	             gsingla@hss.hns.com
		   	
            

Copyright Statement  
            
Copyright (C) The Internet Society (2002). All Rights Reserved.   
                
This document and translations of it may be copied and furnished to   
others, and derivative works that comment on or otherwise explain it   
or assist in its implementation may be prepared, copied, published   
and distributed, in whole or in part, without restriction of any   
kind, provided that the above copyright notice and this paragraph   
are included on all such copies and derivative works. However, this   
document itself may not be modified in any way, such as by removing   
the copyright notice or references to the Internet Society or other   
Internet organizations, except as needed for the purpose of   
developing Internet standards in which case the procedures for   
copyrights defined in the Internet Standards process must be   
followed, or as required to translate it into languages other than   
English.   
               
 The limited permissions granted above are perpetual and will not be   
 revoked by the Internet Society or its successors or assigns.   
  
                
 This document and the information contained herein is provided on an   
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   
             
Acknowledgement

Funding for the RFC editor function is currently provided by the 
Internet Society.
           
  



OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-bhola-conformance-test-iua-01
Last modified: Fri, 28 Nov 2008 10:52:01 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.