OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Wed, 07 Jan 2009 08:39:30 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-ietf-sigtran-iua-test-spec
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-ietf-sigtran-iua-test-spec

Description: Request For Comments

You can download source copies of the file as follows:

draft-ietf-sigtran-iua-test-spec.txt in text format.

Listed below is the contents of file draft-ietf-sigtran-iua-test-spec.txt.


Network Working Group                        Jose Luis Jimenez Ramirez
INTERNET-DRAFT                                                 Siemens 
                                                         Ken Morneault
                                                         Cisco Systems

Expires in six months                                         Jan 2001

         ISDN Q.921-User Adaptation Layer Test Specification
              <draft-ietf-sigtran-iua-test-spec-00.txt>

Status of This Memo

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

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 document presents a test specification for RFCXXXX which defines
the ISDN Q.921-User Adaptation prototocol.  This test specifcation can 
be used to test IUA implementations for conformance to the IUA protocol 
definition. 

				Table of Contents

1	Introduction--------------------------------------------------------

2	General Principles of IUA Tests-------------------------------------

2.1	Terminology---------------------------------------------------------
2.2   Presentation of test descriptions-----------------------------------

3.    Test Environment for IUA on MGC Side--------------------------------

3.1   IUA validation testing----------------------------------------------
3.2   IUA Test Tool ------------------------------------------------------
3.3  	Link Monitor--------------------------------------------------------

4. 	Test Configurations-------------------------------------------------				

4.1 	Presentation of test configurations---------------------------------
4.2 	Configuration for testing the IUA at AS-----------------------------

5.	Test Cases for Testing IUA at MGC-----------------------------------

5.1	AS management-------------------------------------------------------
5.2 	ERROR management----------------------------------------------------
5.3 	ASP configuration---------------------------------------------------
5.4 	Q.921/Q.931 primitives backhaul-------------------------------------

6.	Test Cases for Testing IUA at SG------------------------------------

6.1	AS management-------------------------------------------------------
6.2 	ERROR management----------------------------------------------------
6.3 	ASP configuration---------------------------------------------------
6.4 	Q.921/Q.931 primitives backhaul-------------------------------------

7. 	Acknowledgement-----------------------------------------------------

8. 	Authors Address-----------------------------------------------------

9.  	References----------------------------------------------------------

1. Introduction

This document provides a test specification for the IUA protocol.  The
document provides test scenarios for the IUA implementation for Media
Gateway Controller (MGC) and the Signaling Gateway (SG).  It should be 
pointed out that IUA Protocol is an asymmetric protocol.  The requirements 
of the IUA on the MGC differ from those on the SG.  Thus, the MGC and SG 
will have different implementations of IUA. 

The list of test is an initial proposal and covers almost all the 
categories of test, and graphical representation of various scenarios 
help easy understanding of the protocol testing .

2. General Principles of IUA Tests

These tests aim to verify a given implementation of an IUA protocol 
implementation in accordance with RFCXXXX. This specification is independent 
of a given implementation and does not generally imply any modification of
the endpoint under test.  However, it is recognized that certain tests 
require capabilities of the system that are not explicitly defined in 
RFCXXXX, and these capabilities may not be present in all implementations.  
As a consequence, some tests may not apply to all implementations. 

2.1 Terminology

The terminology from Section 1.2 of RFCXXXX applies to this document.

2.2 Presentation of test descriptions

2.2.1 Pre Test Condition

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

3. Test Environment for IUA on MGC Side.

                                            -------------------
                                           |                   |
                                           |  Test Interface   |
                                           |                   |
                                           |                   |
                                            --------------------
                                                |     |   |
                                                |     |   |  
        ------------                       -----|-----|---|------
       |             |                    |     V     V   |     |       
       | Simulated   |                    | ------------- |     | 
       |             |                    | |  IUA  |LMG| |     |
       |     SG      |                    | ------------- |     |         
       |             |                    |   |   |       V     | 
       |             |                    | -----------------   |     
       |             |                    | |  SCTP     |LMG|   |
       |             |                    | -----------------   |             
       |             |                    |                     | 
       |             |                    |                     | 
       |             |<------------------>|         MGC         |       
       |             |              |     |                     | 
        ------------                |      ----------------------
                                    |  
                                    | An ASP process under Test is
                                    |  running on Host (e.g.  MGC)	
                                    | 
                                    | 
                              -------------
                             |             |
                             |Link Monitor |
                             |             |
                              ------------- 

3.1 IUA validation testing

The IUA test environment consists of the following items
(see Figure 2)

* a MGC with an IUA Test Interface

* a simulated Signaling Gateway

* the link monitor

* the IP link

3.2 IUA Test Interface

In order to perform an optimum test of the IUA Layer, a Test Interface 
MAY be used. This Test Interface should covers the simulation of IUA 
Traffic User, IUA layer Manager (LMG) and SCTP Layer manager (optional).

During the IUA tests, it is necessary to inject messages and 
indications to and from the IUA endpoint under test. 

It is desirable that the IUA user function used is the actual IUA user 
of the IUA with some additional functions for test purposes or a more
controlled user function. The application should also provide means to
check the interface interaction with the IUA implementation under test.

3.3 Simulated SG Test Tool

During IUA testing, it will be necessary to inject some abnormal messages 
(as well as normal messages) to fully test the IUA under test.  The 
Simulated SG should have this function.  The generation of certain abnormal
sequences of messages should also be a capability of this test tool. 

3.4 Link Monitor

During IUA testing, it will be necessary to monitor the various messages 
being exchanged between the two IUA endpoints.  A link monitor, or 
network sniffer, should have this function. It should also have the 
capability to show all the parameters of the message.

4. Test Configurations

The set of tests described in this document assumes that the 
point under test is inserted in a test environment called "test 
configuration".

4.1 Presentation of test configurations

There should be different configurations for testing the IUA protocol. 
These configurations and hence test cases can be divided on the basis of 
IUA at SG and IUA at MGC.  This document proposed describes configuration
for testing the IUA protocol in the Media Gateway Controller (MGC) side 
(ASP's view).

4.2 Configuration for testing the IUA at AS

This subsection describes test scenarios for the IUA protocol in the 
Media Gateway Controller (MGC) side, so A and B and some other scenarios 
that could be added in future, refer to ASP's point of view.

4.2.1 Configuration M1

This simple configuration is used for all the procedures of tests 
concerning only one SG. Configuration M1 is shown in Figure 1.
The ASP is handling the traffic from a list of Interface Identifiers 
in the SG.

  Host 1
  -------------                                 --------------
 | ASP1        |                               | SG           | 
 | under Test  |                               |              |
 |             |-------------------------------|              |
 |             |                               |              |  
  -------------                                 --------------

                    Figure 1  Configuration M1

4.2.2 Configuration M2 

This configuration is used for all the procedures of tests concerning 
two SGs connected to the same ASP.  In this case, the ASP will be part 
of two differents AS.  An AS is modeled at the SG, in practical terms, 
as an ordered list of one or more related Application Server Processes
(e.g., primary, secondary, tertiary), configured to process
Q.921-User messages from certain Interface Identifiers.

                                                --------------
  Host 1                                       | SG1          | 
  -------------                                |              |
 |             |-------------------------------|              |
 | ASP         |                               |              |  
 | Under Test  |                                --------------
 |             |                                --------------  
 |             |-------------------------------| SG2          | 
  -------------                                |              |
                                               |              | 
                                               |              | 
                                                --------------

                      Figure 2  Configuration M2

4.3 Configuration for testing the IUA at AS

This subsection describes test scenarios for the IUA protocol in the 
Signaling Gateway (SG) side, so Configuration S1 and Configuration S2 
and some other scenarios that could be added in future, refer to SG's 
point of view.

4.3.1 Configuration S1

This simple configuration is used for all the procedures of tests 
concerning only one ASP (1+0 failover scenario).  Configuration S1 
is shown in Figure 3.  The ASP is handling the traffic from a list of 
Interface Identifiers in SG.

  -------------                -------------             --------------
 |   PBX       |              | SG          |           | ASP          | 
 |    or       |              | under Test  |           |              |
 |  PBX sim    |--------------|             |-----------|              |
 |             |              |             |           |              |  
  -------------                -------------             --------------

                      Fig 3 Configuration S1

4.2.2 Configuration S2 

This configuration is used for all the procedures of tests concerning 
a single SG connected to two ASPs representing a single AS (1+1 failover
scenario).  Only one ASP will be active at a given point in time.  This
scenario will be useful for testing failover scenarios.

                                                --------------
                                               | ASP1         | 
  -------------                                |              |
 |             |-------------------------------|              |
 | SG          |                               |              |  
 | Under Test  |                                --------------
 |             |                                --------------  
 |             |-------------------------------| ASP2         | 
  -------------                                |              |
                                               |              | 
                                               |              | 
                                                --------------

                      Figure 4  Configuration S2

 
5. Test Cases for Testing IUA at MGC

5.1 AS management
	
5.1.1 ASP Transition to Active State

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  ASP reachs to Active State 
----------------------------------------------------------------------
 PURPOSE:   To check that if LMG sends primitive to send ASP management 
    messages to the SG then the corresponding message is sent to the SG.
    ASP sends the ASP status primitives messages sequence that
    transitions the ASP to the Active state.  After this sequence a new 
    sequence taking the ASP to the Down State will be sent.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is down. 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                     LMG 
 
                                      <---------  ASP-Up
              <-----------      ASPUP

ACK(ASP-Up)  ------------>
                             Status Ind --------->

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

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

ACK(ASP-Active)  ------------>
                             Status Ind --------->

                                      <---------  ASP-Inactive
                <-----------   ASPIA

ACK(ASP-Inactive)  ------------>
                            Status Ind --------->

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

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

ACK(ASP-Down)  ------------>
                            Status Ind --------->

TEST DESCRIPTION
1. Send ASP-Up Primitive message from ASP to SG.
2. Check A ASPUP message will be received at the SG. SG should send 
   an ACK(ASP-Up) in response to the ASPUP message on stream 0.
3. Check B ASPM messages are sent on stream 0.
4. Repeat the test case for primitives like, ASP-Active and ASP-Down. 
   ASPDN, ASPAC and ASPUP messages will be sent from ASP to
   SG with parameters passed from LMG (i.e Test Interface LMG 
   functionality). 
5. Check C Interface Id Ranges AND/OR Interface Id List can be used 
   indistinctly in ASP-Active, ASP-Inactive, ACK(ASP-Active) and 
   ACK(ASP-Inactive) messages.

5.1.2  SG rejects ASPUP message from ASP

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  ASP can not reach Up state; SG rejects ASPUP message 
----------------------------------------------------------------------
 PURPOSE:   To check that if an ASPUP msg is acknowledged with a 
    ACK(ASP-Down), ASP remains in Down State.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is down.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                     LMG 
 
                                      <---------  ASP-Up
               <------------    ASPUP

ACK(ASP-Down)  ------------>
                             Status Ind --------->

TEST DESCRIPTION
1. Send ASP-Up Primitive message from ASP to SG.
2. Check A ASPUP message will be received at the SG. SG should send 
   an ACK(ASP-Down) in response to the ASPUP message on stream 0.
3. ASPUP will be sent from ASP to SG with parameters passed from 
   LMG (i.e Test Interface LMG functionallity). 
4. SG Simulator responds ACK(ASP-Down) with reason parameter set to 
   Management Blocking.

5.1.3 Notify Alternate ASP Active

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  Notify Alternate ASP Active
----------------------------------------------------------------------
 PURPOSE:   To check that if an ASP in Active State is informed by SG 
    that an alternate ASP has overriden it, the ASP will be moved to 
    Inactive State.
----------------------------------------------------------------------
 TEST Configuration:   M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is down.
----------------------------------------------------------------------
 Reference:  RFCXXXX Clause 4.3.2 
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                     LMG 
 
                                      <---------  ASP-Up
                 <-----------   ASPUP

ACK(ASP-Up)  ------------>
                            Status Ind --------->

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

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

ACK(ASP-Active)  ------------>
                            Status Ind --------->

NTFY(ASP-Alternate ------------>
      ASP Active)
                            Status Ind --------->

TEST DESCRIPTION
1. ASP become to Active State.
2. A NTFY(ASP-Alternate ASP Active) msg is received from SG.
3. Check A ASPM messages are sent on stream 0.
4. Check B ASP is moved to Inactive State.
5. Check C Interface Id Ranges AND/OR Interface Id List can be used 
   indistinctly in ASP-Active and ACK(ASP-Active) messages.

5.1.4 SCTP Communication Down Indication

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  SCTP Communication Down Indication
----------------------------------------------------------------------
 PURPOSE:   To check that if the local SCTP sends this indication due to 
    the loss of connectivity to the ASP's peer, ASP will be moved to 
    Down State.
    SCTP CDI is understood as either a SHUTDOWN COMPLETE notification 
    and COMMUNICATION LOST notification from the SCTP.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Up.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                     LMG 
 
                                       <--------- ASP-Active

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

ACK(ASP-Active)  ------------>
                            Status Ind --------->

-----X  X-----SCTP COMMLOST====>
			
			ASP moves to Down State

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

TEST DESCRIPTION
1. ASP become to Active State.
2. A loss of connectivity (SCTP Association) happens.
3. Check A ASPM messages are sent on stream 0.
4. Check B ASP is moved to Down State.
5. Check C Interface Id Ranges AND/OR Interface Id List can be used 
   indistinctly in ASP-Active and ACK(ASP-Active) messages.

[KAM] - should add to test.  SCTP communication restored.  ASP
should go back to Active state without input from Test Interface?

5.2 ERROR management

5.2.1 Invalid Version Error

----------------------------------------------------------------------
 TITLE:      ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Invalid Version Error
----------------------------------------------------------------------
 PURPOSE:   To check that if any message with Invalid version is 
    received at the ASP then ASP responds with ERROR message containing 
    cause "Invalid Version" and diagnostic information filled with the 
    version that the SG supports.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Active (The same Test Case could be done with ASP being 
    Up). 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                SM 
 
                              ASP is Active 

 Message XXXX   ------------>
(Version = 2)      
				
                 <----------- 	ERROR			
				Cause = Invalid Version

TEST DESCRIPTION
1. A message is received from SG with an invalid version in the Common 
   Message Header.
2. Check A ASP sends an Invalid Version Error message to SG.

5.2.2 Unsupported Message Type

----------------------------------------------------------------------
 TITLE:     ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Unsupported Message Type 
----------------------------------------------------------------------
 PURPOSE:  To check that if a message with an undefined message type is 
    received at AS, AS responds with ERROR message containing cause 
    "Unsupported Message Type".To check that if an error is received then 
    this error is reported to the User.Further action at the MGC are 
    implementation dependent.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Active (The same Test Case could be done with ASP being 
    Up). 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                 LMG

                              ASP is Active 

 Message XXXX ---------------->
 Msg Class= any valid value
 Msg Type= 199

           <---------------    ERROR
                            Cause = 
			    Unsupported 
			    Message Type

                                   Error     ------->   

TEST DESCRIPTION
1. A message with an undefined message typeis received at ASP from SG.
2. Check A AS responds with ERROR message containing cause 
   "Unsupported Message Type"
3. Check B Error is reported to the User

5.2.3 Unsupported Message Class

----------------------------------------------------------------------
 TITLE:     ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Unsupported Message Class 
----------------------------------------------------------------------
 PURPOSE:   To check that if a message with message class not defined
    is received at AS, AS responds with ERROR message containing cause 
    "Unsupported Message Class".  To check that if an error is received 
    then this error is reported to the User.  Further action at the MGC 
    are implementation dependent.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Active (The same Test Case could be done with ASP being 
    Up).
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                 LMG

                              ASP is Active 

 Message XXXX ---------------->
 Msg Class=199
 Msg Type= any valid value

           <---------------    ERROR
                            Cause = 
			    Unsupported 
			    Message Class

                                   Error     ------->   

TEST DESCRIPTION
1. A  message with message type not defined is received at ASP is 
   received from SG.
2. Check A AS responds with ERROR message containing cause 
   "Unsupported Message Type"
3. Check B Error is reported to the User

5.2.4 Unexpected QPTM message

----------------------------------------------------------------------
 TITLE:     ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Unexpected QPTM message
----------------------------------------------------------------------
 PURPOSE:  To check that if a QPTM message from an SG is received while 
     ASP was in the Inactive state , the "Unexpected Message" error  
     would be sent by the ASP. (the ASP could optionally drop the 
     message and not send an Error)
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
     ASP. ASP is Inactive.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 3.3.3.1 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP                     LMG 
 
                              ASP is Inactive 

 DATA      -------------->

           <---------------    ERROR
 			       Unexpected Message 

                                   Error     ------->                                

TEST DESCRIPTION
1. A QPTM message from an SG is received. ASP is in Inactive State
2. Check A ERROR messages are sent.

5.3 ASP configuration

5.3.1 ASP configured to handle traffic for more than one AS

----------------------------------------------------------------------
 TITLE:     ASP configuration
----------------------------------------------------------------------
 SUBTITLE:  ASP configured to handle traffic for more than one AS
----------------------------------------------------------------------
 PURPOSE:   To check that if an ASP has been configured to handle 
    traffic for more than one AS. The IUA layer at the SG maintains the 
    availability state of all dynamically registered remote ASPs, in
    order to manage the SCTP Associations and the traffic between the 
    SG and ASPs.  As well, the active/inactive state of remote ASP(s) 
    are also maintained.  Active ASPs are those currently receiving 
    traffic from the SG.
----------------------------------------------------------------------
 TEST Configuration:  M2
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  An SCTP association is established between each 
    SG and ASP. ASP has been configured to handle traffic from two SG.
    ASP is Down for AS1 and AS2.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 1.3.3
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE  (ASP's view)
      
SG1                          SG2                        ASP1
(AS1= ASP1,ASP3,...,ASPn)    (AS1= ASP1,ASP2,...,ASPm)     
|                             |                          |
|                             |<-------ASP Up -----------|
|                             |--------ASP Up Ack------->|
|                             |                          |
|<---------------------------------ASP Up----------------|
|----------------------------------ASP Up Ack----------->|
|                             |                          |
|                             |                          |
|                             |<-------ASP Active--------|
|                             |--------ASP Active Ack--->|
|                             |                          |
|<---------------------------------ASP Active------------|
|----------------------------------ASP Active Ack------->|
|                             |                          |
|                             |                          |
|                             |<-----ASP Inactive--------|
|                             |------ASP Inactive Ack--->|
|                             |                          |
|<-------------------------------ASP Inactive------------|
|--------------------------------ASP Inactive Ack------->|
|                             |                          |
|                             |                          |

TEST DESCRIPTION
1. Send ASP-Up primitive from LMG to ASP. ASPUP message will be sent 
   from ASP to SG1. Send ACK(ASP-Up) from the SG. 
2. Repeat the above test case for SG2.
3. Repeat the test case for primitives like, ASP-Active and ASP-Inactive. 
   ASPAC and ASPIA messages will be sent from ASP to SGs with parameters
   passed from LMG (i.e Test Tool LMG functionality). 
4. Check A ASPAC message is received at the SG containing a list of 
   Interface Identifiers  that the sending ASP is configured/registered
   to receive from that SG. If no Interface Identifiers are included, 
   the message is for all provisioned Interface Identifiers within the
   AS(s) in which the ASP is provisioned.

5.4 Q.921/Q.931 primitives backhaul

5.4.1 Send and Receive Q.921/Q.931 primitives

----------------------------------------------------------------------
 TITLE:     Q.921/Q.931 primitives backhaul
----------------------------------------------------------------------
 SUBTITLE:  Establishing of a Data Link on a Signaling Channel.
 ----------------------------------------------------------------------
 PURPOSE:   To check that a Data Link on a Signaling Channel is 
     established and Traffic User PDUs can be exchanged.
----------------------------------------------------------------------
 TEST Configuration:  M1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and
     ASP. ASP is in ASP-Active state.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.1.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE  (ASP's view)
      
 SG                                    ASP                Traffic User 
                                  ASP is Active             (Q.931)
                                              <---------  DL-Establish Req
<------------------------------ Establish Request
Establish Confirm  ------------------------->
                                              --------->  DL-Establish Comf

                                              <---------  DL-Data Req
<-------------------------------- Data Request

Data Indication ---------------------------->
                                              --------->  DL-Data Ind

                                              <---------  DL-Data Req
<-------------------------------- Data Request
Data Indication ---------------------------->
                                              --------->  DL-Data Ind

                                              <---------  DL-Data Req
<-------------------------------- Data Request

                                              <---------  DL-Data Req
<-------------------------------- Data Request

Data Indication ---------------------------->
                                              --------->  DL-Data Ind

                                              <---------  DL-Release Req
<-------------------------------- Release Request 
                                     
Release Confirm  --------------------------->
                                              --------->  DL-Release Conf

TEST DESCRIPTION
1. MGC desires the D channel to be in-service,
   it will send the Establish Request message to establish a
   data link to the SG on the signalling channel. DL-Establish 
   Req Primitive is invoked at ASP to send Establish Request message
   to the SG. This message should be acknownledged by Establish Confirm 
   message.
2. Check A The message is sent on the SCTP stream that
   corresponds to the D channel (Interface Identifier).
3. Now (Q.931) DATA message from MGC and SG containing Protocol Data can
   be transmitted or received by the Data link.
4. Check B DATA message is received at MGC and SG containing the 
   data passed by the Traffic User
5. Invoke DL-Release Req Primitive from the LMG at ASP to send 
   Release Request message to the SG. This message should be 
   acknownledged by Release Confirm message. The Data Link is now 
   released.

6. Test Cases for Testing IUA at SG

6.1 AS management
	
6.1.1 ASP Transition to Active State

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  ASP reachs to Active State 
----------------------------------------------------------------------
 PURPOSE:   To check that if LMG sends primitive to send ASP management 
    messages to the SG then the corresponding message is sent to the SG.
    ASP sends the ASP status primitives messages sequence that
    transitions the ASP to the Active state.  After this sequence a new 
    sequence taking the ASP to the Down State will be sent.
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP.  ASP is down. 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                                ASP 
 
                                     
                 <-----------     ASPUP

ACK(ASP-Up)      ------------>
                             

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

ACK(ASP-Active)  ------------>

                 <-----------     ASPIA

ACK(ASP-Inactive) ----------->

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

ACK(ASP-Down)     ------------>

TEST DESCRIPTION
1. Send ASP-Up Primitive message from ASP to SG.
2. SG should send an ACK(ASP-Up) in response to the ASPUP.
3. Check B ASPM messages are sent on stream 0.
4. Repeat the test case for primitives like, ASP-Active and ASP-Down. 
   ASPDN, ASPAC and ASPUP messages will be sent from ASP to
   SG.
5. Check C Interface Id Ranges AND/OR Interface Id List can be used 
   indistinctly in ASP-Active, ASP-Inactive, ACK(ASP-Active) and 
   ACK(ASP-Inactive) messages.

6.1.2  ASP Active Before ASP Up

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  ASP Active sent Before ASP Up
----------------------------------------------------------------------
 PURPOSE:   To check that ASP Active is rejected if ASP not in Up 
    state.
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is down.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                                ASP 
 
                 <-----------     ASPAC

ACK(ASP-Down)    ------------>

TEST DESCRIPTION
1. Send ASPAC message from ASP to SG.
2. SG should send an ACK(ASP-Down) in response to the ASPAC message on
   stream 0.

6.1.3 Notify AS Pending

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  Notify AS Pending
----------------------------------------------------------------------
 PURPOSE:   To check that Notify (AS-Pending) will be sent if Active
    ASP transitions to Inactive.
----------------------------------------------------------------------
 TEST Configuration:   S2
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP associations are established between SG and 
    both ASPs. ASPs are down.
----------------------------------------------------------------------
 Reference:  RFCXXXX Clause 4.3.2 
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                            ASP1                     ASP2 
 
               <-----------   ASPUP

ACK(ASP-Up)    ------------>

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

ACK(ASP-Up)    -------------------------------------->

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

ACK(ASP-Active) ------------>

                <-----------  ASPIA

ACK(ASP-Inactive) ------------>

Notify (AS-Pending) --------------------------------->

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

ACK(ASP-Active) ------------------------------------->

TEST DESCRIPTION
1. ASP Up sent from both ASPs.
2. ASP1 sends ASP Active to transition to Active State.
3. ASP1 sends ASP Inactive to transition to Inactive State.
4. SG sends a NTFY(AS-Pending) message to ASP2.
5. ASP2 sends ASP Active (if and when it is willing to transition to 
   Active state).

6.1.4 Notify Alternate ASP Active

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  Notify Alternate ASP Active
----------------------------------------------------------------------
 PURPOSE:   To check that SG will send Notify (Alternate ASP Active)
    if one ASP overrides another ASP.
----------------------------------------------------------------------
 TEST Configuration:   S2
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP associations are established between SG and 
    both ASPs.  ASPs are Down.
----------------------------------------------------------------------
 Reference:  RFCXXXX Clause 4.3.2 
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

 SG                            ASP1                     ASP2 
 
               <-----------   ASPUP

ACK(ASP-Up)    ------------>

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

ACK(ASP-Up)    -------------------------------------->

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

ACK(ASP-Active) ------------>

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

ACK(ASP-Active) ------------------------------------->

Notify (Alt ASP Active) ---->

TEST DESCRIPTION
1. Both ASPs transition to Up state.
2. ASP1 transitions to Active state.
3. ASP2 transitions to Active state.
4. SG sends a NTFY(Alternate ASP Active) to ASP1 to notify it that
   ASP2 has overridden it.

6.1.5 SCTP Communication Down Indication

----------------------------------------------------------------------
 TITLE:     AS management
----------------------------------------------------------------------
 SUBTITLE:  SCTP Communication Down Indication
----------------------------------------------------------------------
 PURPOSE:   To check that if the local SCTP sends this indication due to 
    the loss of connectivity to the ASP's peer, ASP will be moved to 
    Down State.
    SCTP CDI is understood as either a SHUTDOWN COMPLETE notification 
    and COMMUNICATION LOST notification from the SCTP.
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP.  ASP is Up. 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP 
 
                 <----------- ASPAC

ACK(ASP-Active)  ------------>

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

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

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

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

<=====SCTP COMM LOST====>
			
	ASP moves to Down State

<=====SCTP COMM RESTORED====>
			
                 <----------- ASPAC

ACK(ASP-Active)  ------------>

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

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

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

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

TEST DESCRIPTION
1. ASP become to Active State.
2. Two D channels established.
3. A loss of connectivity (SCTP Association) occurs.
4. Check B ASP is moved to Down State.  Note effect on D channel state.
5. A restoration of connectivity (SCTP Association) occurs.
6. ASP should re-establish previous ASP state and D channel state.

6.2 ERROR management

6.2.1 Invalid Version Error

----------------------------------------------------------------------
 TITLE:      ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Invalid Version Error
----------------------------------------------------------------------
 PURPOSE:   To check that if any message with Invalid version is 
    sent from SG if it receives a message that contains a version it
    does not support.
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                               ASP     
 
              <-----------       ASP Up 
                              (Version = 2)
 Error        ------------>
(Invalid Version)      
				

TEST DESCRIPTION
1. A message is received by SG with an invalid version in the Common 
   Message Header.
2. Check A SG sends an Invalid Version Error message to ASP.

6.2.2 Unsupported Message Type

----------------------------------------------------------------------
 TITLE:     ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Unsupported Message Type 
----------------------------------------------------------------------
 PURPOSE:  To check that if a message with an undefined message type is 
    received at SG, SG responds with ERROR message containing cause 
    "Unsupported Message Type".  
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Active (The same Test Case could be done with ASP being 
    Up). 
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP         

                              ASP is Active 

              <-----------     Message XXXX 
                              (Msg Class = any valid value, Msg Type = 199)
 Error        ------------>
(Unsupported Message Type)      
 

TEST DESCRIPTION
1. A message with an undefined message type is sent from ASP to SG.
2. Check A SG responds with ERROR message containing cause 
   "Unsupported Message Type".

6.2.3 Unsupported Message Class

----------------------------------------------------------------------
 TITLE:     ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Unsupported Message Class 
----------------------------------------------------------------------
 PURPOSE:   To check that if a message with message class not defined
    is received at SG, SG responds with ERROR message containing cause 
    "Unsupported Message Class".  
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Active (The same Test Case could be done with ASP being 
    Up).
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP         

                              ASP is Active 

              <-----------     Message XXXX 
                              (Msg Class = 199, Msg Type = any valid value)
 Error        ------------>
(Unsupported Message Class)      
 

TEST DESCRIPTION
1. A  message with message class that is not defined is received by SG. 
2. Check A SG responds with ERROR message containing cause 
   "Unsupported Message Type".

6.2.4 Invalid Interface Identifier

----------------------------------------------------------------------
 TITLE:     ERROR Management
----------------------------------------------------------------------
 SUBTITLE:  Invalid Interface Identifier 
----------------------------------------------------------------------
 PURPOSE:   To check that the SG will respond with Error (Invalid
    Interface Identifier) if the ASP sends a message for an Invalid
    Interface Identifier (one that is not configured on SG).  
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP. ASP is Active (The same Test Case could be done with ASP being 
    Up).
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.3.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 

 SG                              ASP         

                              ASP is Active 

              <-----------     Establish Request 
                              ( with invalid Interface Identifier)
 Error        ------------>
(Invalid Interface Identifier)      
 

TEST DESCRIPTION
1. ASP sends Establish Request with an invalid Interface Identifier. 
2. Check A SG responds with ERROR message containing cause 
   "Invalid Interface Identifier".

6.2.5 Unexpected QPTM message

----------------------------------------------------------------------
 TITLE:     ERROR management
----------------------------------------------------------------------
 SUBTITLE:  Unexpected QPTM message
----------------------------------------------------------------------
 PURPOSE:  To check that if a QPTM message is sent from ASP while
     ASP is not Active, the SG will send "Unexpected Message" error
     in response. 
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and 
    ASP.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 3.3.3.1 
----------------------------------------------------------------------

 EXPECTED MESSAGE SEQUENCE 

  SG                                ASP 
 
                                     
                <-----------       ASPUP

ACK(ASP-Up)     ------------>
                             

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

Error (Unexpected Msg) ----->

TEST DESCRIPTION
1. Send ASP-Up Primitive message from ASP to SG.
2. Check A ASPUP message will be received at the SG. 
3. Send a QPTM (i.e. Establish Request) message from the MGC.
4. Check A ERROR message with Unexpected Message is sent.

6.3 ASP configuration

6.3.1 SG supports more than one ASP (optional)

----------------------------------------------------------------------
 TITLE:     ASP configuration
----------------------------------------------------------------------
 SUBTITLE:  SG configured to support >1 ASP
----------------------------------------------------------------------
 PURPOSE:   To check that if an SG can support more than one ASP.  In
    this case, one ASP will support a number of Interface Identifiers
    and the other ASP will support other Interface Identifiers.  
    Note:  The Interface Identifiers must not overlap between ASPs.
----------------------------------------------------------------------
 TEST Configuration:  S2 (ASPs are independent, not in failover 
    configuration)
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  An SCTP association is established between each 
    SG and ASP.   Both ASPs are Down.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 1.3.3
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE 
      
 SG                            ASP1                     ASP2 
 
               <-----------   ASPUP

ACK(ASP-Up)    ------------>

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

ACK(ASP-Up)    -------------------------------------->

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

ACK(ASP-Active) ------------>

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

ACK(ASP-Active) ------------------------------------->

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

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

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

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

TEST DESCRIPTION
1. Both ASPs transition to Active state. 
2. Both ASPs bring a D channel in-service.

6.4 Q.921/Q.931 primitives backhaul

6.4.1 Send and Receive Q.921/Q.931 primitives

----------------------------------------------------------------------
 TITLE:     Q.921/Q.931 primitives backhaul
----------------------------------------------------------------------
 SUBTITLE:  Establishing of a Data Link on a Signaling Channel.
 ----------------------------------------------------------------------
 PURPOSE:   To check that a Data Link on a Signaling Channel is 
     established and Traffic User PDUs can be exchanged.
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and
     ASP. ASP is in ASP-Active state.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.1.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE  (ASP's view)
      
 SG                                    ASP         

                                  ASP is Active  
                                             
<------------------------------ Establish Request
Establish Confirm  ------------------------->

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

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

<-------------------------------- Data Request
<-------------------------------- Data Request

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

<-------------------------------- Release Request 
                                     
Release Confirm  --------------------------->

TEST DESCRIPTION
1. MGC desires the D channel to be in-service,
   it will send the Establish Request message to establish a
   data link to the SG on the signalling channel. DL-Establish 
   Req Primitive is invoked at ASP to send Establish Request message
   to the SG. This message should be acknownledged by Establish Confirm 
   message.
2. Check A The message is sent on the SCTP stream that corresponds to the 
   D channel (Interface Identifier).
3. Now (Q.931) DATA message from MGC and SG containing Protocol Data can
   be transmitted or received by the Data link.
4. Check B DATA message is received at MGC and SG containing the 
   data passed by the Traffic User
5. Invoke DL-Release Req Primitive from the LMG at ASP to send 
   Release Request message to the SG. This message should be 
   acknownledged by Release Confirm message. The Data Link is now 
   released.

6.4.2 Send Release Indication

----------------------------------------------------------------------
 TITLE:     Release Indication
----------------------------------------------------------------------
 SUBTITLE:  Release Indication Sent when Upon failure of Data Link
 ----------------------------------------------------------------------
 PURPOSE:   To check that a SG will send Release Indication when
     Data Link fails.
----------------------------------------------------------------------
 TEST Configuration:  S1
----------------------------------------------------------------------
 PRE-TEST CONDITIONS:  SCTP association is established between SG and
     ASP. ASP is in ASP-Active state.
----------------------------------------------------------------------
 Reference:  RFCXXXX  Clause 4.1.2 
----------------------------------------------------------------------
 EXPECTED MESSAGE SEQUENCE  
      
 SG                                    ASP         

                                  ASP is Active  
                                             
<------------------------------ Establish Request
Establish Confirm  ------------------------->

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

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

<-------------------------------- Data Request
<-------------------------------- Data Request

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

   <==== Data Link Disconnected ====>

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

TEST DESCRIPTION
1. MGC desires the D channel to be in-service,
   it will send the Establish Request message to establish a
   data link to the SG on the signalling channel. DL-Establish 
   Req Primitive is invoked at ASP to send Establish Request message
   to the SG. This message should be acknownledged by Establish Confirm 
   message.
2. Check A The message is sent on the SCTP stream that corresponds to the 
   D channel (Interface Identifier).
3. Now (Q.931) DATA message from MGC and SG containing Protocol Data can
   be transmitted or received by the Data link.
4. Check B DATA message is received at MGC and SG containing the 
   data passed by the Traffic User
5. Disconnect D channel physical interface.  SG should generate 
   Release Indication message. 

NEED TO ADD HEARTBEAT FAILURE

7. Acknowledgement

The authors are highly grateful to Maria Pilar Sanchez, Maria Sonia 
Vazquez, Pablo Alonso Martin, Maria de Miguel, Jaime Olivares and 
Antonio Alonso for their valuable comments and suggestions.

8. Author Address

Jose Luis Jimenez Ramirez            EMail ecejljr@ece.ericsson.se
Ericsson Spain s.a.                       
Torre Urbis.C/Ombu, 3
28045 Madrid
Spain

Ken Morneault                                EMail kmorneau@cisco.com
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA

9. References

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

[2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a
    Voice over Packet Network'

[3] Stream Control Transmission Protocol, RFC 2960, October 2000

[4] Architectural Framework for Signaling Transport, RFC 2719 ,
    October 1999

[5] ISDN Q.921-User Adaptation Layer, RFC XXXX, January 2001

[6] Site Security Handbook, RFC 2196, September 1997

[6] Security Architecture for the Internet Protocol, RFC 2401



OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-ietf-sigtran-iua-test-spec
Last modified: Wed, 07 Jan 2009 08:39:30 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.