| draft-mahajan-test-spec-m3ua-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-mahajan-test-spec-m3ua-00.txt.
INTERNET-DRAFT Sachin Jindal
Sunil Mahajan
Hughes Software Systems
July 7,2000
expires: Jan 7, 2001
Test Specification for MTP3 User Adaptation
<draft-mahajan-test-spec-m3ua-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Sachin-Sunil, HSS [Page 1]
Internet Draft Test Specs for M3UA July 2000
Abstract
This document presents the test specification for M3UA (MTP3 User
Adaptation) prototcol (ver 02), which can be used to test M3UA
implementations for conformance to the protocol definition. The list
of test is exhaustive and covers almost all the categories of test.
This draft can also be used in conjunction with M3UA specification by
implementor of protocol as implementors guide, as the pictorial
representation of various scenarios help easy understanding of the
protocol.
Next revision of the draft will cover the additions done to the
protocol revision M3UA-03 and any subsequent RFC published by IETF.
Sachin-Sunil, HSS [Page 2]
Internet Draft Test Specs for M3UA July 2000
Table of Contents
1 Introduction------------------------------------------------3
1.1 Terms Used--------------------------------------------------3
2 General Principles of m3ua Tests----------------------------5
2.1 Presentation of Test Descriptions---------------------------5
2.1.1 Pre-Test Condition------------------------------------------6
3 Test Configurations-----------------------------------------6
3.1 Configuration for Testing the m3ua at SG--------------------6
3.2 Configuration for Testing The m3ua at AS--------------------10
4 Test Cases--------------------------------------------------12
4.1 Test cases for testing m3ua at SG---------------------------12
4.1.1 Send and Receive transfer primitive in AS Active state------12
4.1.2 Stream selection--------------------------------------------13
4.1.3 AS Management-----------------------------------------------14
4.1.4 MTP3 Management---------------------------------------------31
4.1.5 Invalid Message Handling------------------------------------36
4.1.6 Duplicate Message Handling----------------------------------47
4.1.7 ASPM messages when SG has locked out the ASP----------------55
4.1.8 Message Routing---------------------------------------------56
4.1.9 Mode of Traffic Handling by ASP in ASPAC message------------61
4.1.10 Mode of Traffic Handling by ASP in ASPIA message------------64
4.1.11 ERROR Message Handling--------------------------------------65
4.1.12 SCTP Connection Management----------------------------------66
4.1.13 SPMC management---------------------------------------------68
4.2 Test Cases for Testing m3ua at AS---------------------------70
4.2.1 Send and receive of transfer primitive in AS Active state---70
4.2.2 Stream Selection--------------------------------------------71
4.2.3 SCTP Connection Management----------------------------------72
4.2.4 AS Management-----------------------------------------------74
4.2.5 Invalid Message Handling------------------------------------78
4.2.6 SSNM Message Handling---------------------------------------85
4.2.7 Duplicate Message Handling----------------------------------90
4.2.8 ERROR Handling----------------------------------------------92
4.2.9 ASP in more than one AS-------------------------------------93
4.2.10 SG Redundancy-----------------------------------------------94
5 Acknowledgement---------------------------------------------96
6 Authors address---------------------------------------------96
7 References--------------------------------------------------96
1 Introduction
The M3UA is a protocol for the transport of any SS7 MTP3-User
signalling (e.g. ISUP and SCCP messages) over IP using the Stream
Control Transport Protocol (SCTP) or any other suitable transport
protocol.This protocol would be used between a Signalling Gateway (SG)
and an Application Service Provider (ASP) (e.g. Media Gateway
Controller - MGC) or IP-resident Database.
1.1 Terms Used
Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element
Sachin-Sunil, HSS [Page 3]
Internet Draft Test Specs for M3UA July 2000
handling all call processing for a unique range of PSTN trunks,
identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual
database element, handling all HLR transactions for a particular SS7
DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more
unique Application Server Processes, of which one or more is normally
actively processing traffic.
Application Server Process (ASP) - A process instance of an Application
Server. An Application Server Process serves as an active or standby
process of an Application Server (e.g., part of a distributed virtual
switch or database element). Examples of ASPs are processes (or process
instances of) MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP
end-point and may be configured to process signalling traffic within
more than one Application server.
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of MTP3-User
protocol data units and M3UA adaptation layer peer messages.
Routing Key: At the SG, the Routing Key describes a set of SS7
parameter/parameter-ranges that uniquely defines the range of
signalling traffic configured to be handled by a particular Application
Server. For example, where all traffic directed to a particular SS7
DPC, OPC and ISUP CIC_range(s) or SCCP SSN is to be sent to a
particular Application Server, that SS7 data defines the associated
Routing Key. Routing Keys are mutually exclusive in the sense that a
received SS7 signalling message cannot be directed to more than one
Routing Key. Also, a Routing Key cannot extend across more than a
single SS7 DPC, in order to more easily support SS7 Management
procedures. It is not necessary for the parameter ranges within a
particular Routing Key to be contiguous. For example, an ASP could be
configured to support call processing for multiple ranges of PSTN
trunks that are not represented by contiguous CIC values.
Routing Context : An Application Server Process may be configured to
process traffic within more than one Application Server. In this case,
the Routing Context parameter is exchanged beween the SG and the ASP,
identifying the relevant Application Server. From the perspective of
an ASP, the Routing Context uniquely identifies the range of traffic
associated with a particular Application Server, which the ASP is
configured to receive from the SG. There is a 1:1 relationship between
a Routing Context value and a Routing Key at an SG. Therefore the
Routing Context can be viewed as an index into an SG Table containing
the SG Routing Keys.
Fail-over - The capability to re-route signaling traffic as required to
an alternate Application Server Process, or group of ASPs, within an
Application Server in the event of failure or unavailability of a
currently used Application Server Process. Fail-back may apply upon
the return to service of a previously unavailable Application Server
Process.
Sachin-Sunil, HSS [Page 4]
Internet Draft Test Specs for M3UA July 2000
Signalling Point Management Cluster (SPMC): A complete set of
Application Servers represented to the SS7 network under the same SS7
Point Code. SPMCs are used to sum the availability/congestion/
User_Part status of an SS7 destination point code that is distributed
in the IP domain, for the purpose of supporting MTP3 management
procedures at an SG. In some cases, the SG itself may also be a member
of the SPMC. In this case, the SG availability/congestion/User_Part
status must also be taken into account when considering any supporting
MTP3 management actions.
MTP3-User - Any protocol normally using the services of the SS7 MTP3
(e.g., ISUP, SCCP, TUP, etc.).
Network Appearance: The Network Appearance identifies an SS7 network
context for the purposes of logically separating the signaling traffic
between the SG and the Application Server Processes over a common SCTP
Association. An example is where an SG is logically partitioned to
appear as an element in four separate national SS7 networks. A Network
Appearance implicitly defines the SS7 Point Code(s), Network Indicator
and MTP3 protocol type/variant/version used within a specific SS7
network partition. An physical SS7 route-set or link-set at an SG can
appear in only one network appearance. The Network Appearance is not
globally significant and requires coordination only between the SG and
the ASP.
Network Byte Order: Most significant byte first, a.k.a Big Endian.
Layer Management: Layer Management is a nodal function in an SG or ASP
that handles the inputs and outputs between the M3UA layer and a local
management entity.
Host - The computing platform that the ASP process is running on.
Stream - A stream refers to an SCTP stream.
2 General Principles of M3UA Tests
These tests aim to verify a given implementation of a protocol in
accordance with the relevant draft. The specification is independent of
a given implementation and does not generally imply any modification of
the endpoint under test. However, it is recognized that certain tests
require capabilities of the system that are not explicitly defined in
the draft, and these capabilities may not be present in all
implementations. As a consequence, certain tests may not be possible in
all implementations.
2.1 Presentation of test descriptions
Each test description includes the environment in which the point under
test must be inserted in order to pass the test. Nine test
configurations are defined (named A, B, C, D, E, F, G, H and I); they
are presented in clause 3.
Each test is precisely described. Nevertheless, some events not
Sachin-Sunil, HSS [Page 5]
Internet Draft Test Specs for M3UA July 2000
directly concerning the point under test, or without direct link with
the test nature, are not explicitly described. In order to preserve the
test description implementation independence, certain flexibility has
been left in the test descriptions. This is particularly the case when
it is necessary to terminate the SCTP association (where it is only
mentioned "Terminate" with no more precision). The operator will choose
according to the implementation particularities and the events expected
in the test description, the appropriate Termination means (MML- Man
machine Language, provoked failure, etc.).
2.1.1 Pre Test Condition
Before starting the test we need to get the setup into a condition from
where test can be started. These conditions are specified in Pre-Test
condition in each test.
Note: Routing Context and Routing Key has been used interexchangably.
In case of message it is Routing Context and in the test configuration
it is Routing Key.
Note: Where NIF has been written, it means that NIF+SM. In some
implementation these may be two entities and in some, they may be
implemented in single entity.
3 Test Configurations:
The set of tests described in this Recommendation assumes that the
point under test is inserted in a test environment called "test
configuration".
3.1 Presentation of test configurations:
There are different configurations for testing the M3UA protocol. These
configurations and hence test cases have been divided on the basis of
M3UA at SG and M3UA at AS.
3.2 Configuration for testing the M3UA at SG:
3.2.1 Configuration A:
This simple configuration is used for all the procedures of tests
concerning only one AS. Configuration A is shown in figure 1. AS is
handling the traffic for routing context P and N/w Appearance A. AS is
having only one ASP ASP1.Point Code of SG is Z. Routing Context P may
be based on the following information:
1. DPC
2. DPC+CIC+SIO
3. DPC+SIO
4. DPC+SSN
Sachin-Sunil, HSS [Page 6]
Internet Draft Test Specs for M3UA July 2000
------------- --------------
| SG | | AS DPC = X |
| under Test | | ------- |
| DPC = Z |-------------------------------|--| ASP1 | |
| | | ------- |
------------- --------------
Fig 1: Configuration A
3.2.2 Configuration B:
This configuration is used for all the procedures of tests concerning
one ASP in two AS which are handling traffic for both AS. Configuration
B is shown in figure 2. AS1 is handling the traffic for routing context
P and N/w Appearance A. AS2 is handling the traffic for routing context
Q and N/w Appearance A. ASP1 is in both AS. Point Code of SG is Z.
Routing Context P and Q may be based on the following information:
1. DPC
2. DPC+CIC+SIO
3. DPC+SIO
4. DPC+SSN
--------------
| AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SG | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC Y |
------------- | ------- |
| | ASP1 | |
| ------- |
--------------
Fig 2: Configuration B
3.2.3 Configuration C:
This configuration is used for all the procedures of tests concerning
two or more ASP in one AS. Configuration C is shown in figure 3. AS is
handling the traffic for routing context P and N/w Appearance A. ASP1
and ASP2 can be in FAIL-OVER mode or LOADSHARE mode of traffic
handling. Point Code of SG is Z.Routing Context P may be based on the
following information:
1. DPC
2. DPC+CIC+SIO
3. DPC+SIO
4. DPC+SSN
Sachin-Sunil, HSS [Page 7]
Internet Draft Test Specs for M3UA July 2000
--------------
| AS DPC X |
------------- | ------- |
| |-------------------------------|-| ASP1 | |
| SG | | ------- |
| Under Test | | ------- |
| DPC Z | | | ASP2 | |
| |-------------------------------|- ------- |
------------- --------------
Fig 3: Configuration C
Sachin-Sunil, HSS [Page 7]
Internet Draft Test Spec For M3UA May 2000
3.2.4 Configuration D:
This configuration is used for all the procedures of tests concerning
two or more AS which are handling traffic for different network
appearance and different routing context. Configuration D is shown in
figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and
AS3 is handling traffic for N/w appearance B. AS1 is handling traffic
for Routing Context P, AS2 is handling traffic for Routing Context Q
and AS3 is handling traffic for Routing Context R.
--------------
| AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SG | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC Y |
------------- -------+ | ------- |
| | | ASP2 | |
| | ------- |
| --------------
| --------------
| | AS3 DPC T |
+-----------------------|- ------- |
| | ASP 3 | |
| ------- |
--------------
Fig 4: Configuration D
Sachin-Sunil, HSS [Page 8]
Internet Draft Test Specs for M3UA July 2000
3.2.5 Configuration E:
This configuration is used for all the procedures of tests concerning
two AS which are handling traffic for two Routing Contexts.
Configuration E is shown in figure 5. AS1 is handling the traffic for
routing context P. AS2 is handling the traffic for Routing Context Q.
ASP1 is in AS1 and ASP2 is in AS2. Routing Contexts are sharing the
point code.
--------------
| AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SG | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC X |
------------- | ------- |
| | ASP2 | |
| ------- |
--------------
Fig 5: Configuration E
3.2.6 Configuration F:
This configuration is used for all the procedures of tests concerning
AS serving different SIO. Configuration F is shown in figure 6. AS1 is
handling the traffic for routing context P, AS2 is handling for routing
context Q and AS3 for routing context R. All AS are handling traffic
for N/w appearance A. Point Code of SG is Z. AS1 and AS2 are serving
the SIO ISUP but different CIC range and AS3 is serving the SIO SCCP.
--------------
| AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SG | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC X |
------------- -------+ | ------- |
| | | ASP2 | |
| | ------- |
| --------------
| --------------
| | AS3 DPC X |
+-----------------------|- ------- |
| | ASP 3 | |
| ------- |
--------------
Fig 6: Configuration F
Sachin-Sunil, HSS [Page 9]
Internet Draft Test Specs for M3UA July 2000
3.3 Configuration for testing the M3UA at AS
3.3.1 Configuration G:
This simple configuration is used for all the procedures of tests
concerning only one SG. Configuration G is shown in figure 7. Point
Code of SG is Z. ASP is handling the traffic for routing context P.
Routing Context P may be based on the following information:
1. DPC
2. DPC+CIC+SIO
3. DPC+SIO
4. DPC+SSN
------------- --------------
| ASP1 | | SG |
| under Test | | DPC = Z |
| DPC = X |-------------------------------| |
| | | |
------------- --------------
Fig 7: Configuration G
3.3.2 Configuration H:
This configuration is used for all the procedures of tests concerning
two SGs connected to the same ASP and handling traffic for the same DPC
in the SEP network. Configuration H is shown in figure 8. SG1 and SG2
are handling the traffic for N/w Appearance A. Point Code of SG1 is Y
and of SG2 is Z. Routing Context P may be based on the following
information:
1. DPC
2. DPC+CIC+SIO
3. DPC+SIO
4. DPC+SSN
--------------
| SG1 |
------------- | DPC Y |
| |-------------------------------| |
| ASP1 | | |
| Under Test | --------------
| DPC X | --------------
| |-------------------------------| SG2 |
------------- | DPC Z |
| |
| |
--------------
Fig 8: Configuration H
Sachin-Sunil, HSS [Page 10]
Internet Draft Test Specs for M3UA July 2000
3.3.1 Configuration I:
This simple configuration is used for all the procedures of tests
concerning one ASP in two AS. Configuration I is shown in figure 9.
Point Code of SG is Z. ASP1 is in two AS, AS1 and AS2. AS1 is handling
traffic for routing context P and AS2 is handling traffic for routing
context Q. Routing Context P and Q may be based on the following
information:
1. DPC
2. DPC+CIC+SIO
3. DPC+SIO
4. DPC+SSN
------------- --------------
| ASP1 | | SG |
| under Test | | DPC = Z |
| DPC = X |-------------------------------| |
| | | |
------------- --------------
Fig 9: Configuration I
Sachin-Sunil, HSS [Page 11]
Internet Draft Test Specs for M3UA July 2000
4 Test Cases
4.1 Test Cases for Testing M3UA at SG
These test cases are used to test the M3UA at SG.
"Send and Receive Transfer Primitive in AS Active State"
+ TEST NUMBER : 1.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.2.1 and 1.6
+ TITLE : MTP-Transfer Primitive
+ SUBTITLE : Send and Receive Transfer Primitive in AS Active State
+ PURPOSE: To check that on receiving Transfer primitive from NIF, DATA
message is sent to the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS. ASP1 is active. Also arrange the data in SG such that upper
layers send MTP-Transfer indication primitive to M3UA with data to be
sent to DPC X and N/w Appearance A.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
a) ASP is Active
<----------- MTP-Transfer
<------------- DATA N/w appearance A
b)
DATA -------------->
MTP-Transfer --------->
TEST DESCRIPTION:
1. Send Transfer Request Primitive from the NIF at SG side to send
Protocol Data to the ASP1.
2. Check A: DATA message should be received at the ASP1 containing the
data passed by the NIF and the Network Appearance.
3. Send DATA message from ASP containing Protocol Data and Network
Appearance A that is known to SG.
4. Check B: Transfer primitive is received at the NIF with the Protocol
Data.
5. Repeat the test step 3 if N/w Appearance parameter is not present in
the DATA message sent from ASP to SG.
Note: Network Appearance is an optional parameter. In some
implementation this parameter will not be present in DATA
message sent from SG to ASP.
Sachin-Sunil, HSS [Page 12]
Internet Draft Test Specs for M3UA July 2000
"Stream Selection"
+ TEST NUMBER : 1.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.3
+ TITLE : Stream Selection
+ SUBTITLE : Stream Selection
+ PURPOSE: To check that all the messages for the same call are sent on
the same SCTP stream.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS with two or more streams. ASP1 is active. Also arrange the data in
SG such that NIF send three or more Transfer indication primitive to
M3UA with N/w Appearance A containing the Data with same CIC value
to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
ASP is active
<--------- MTP-Transfer
Check Stream id <------------- DATA Data with CIC X
<--------- MTP-Transfer
Check Stream id <------------- DATA Data with CIC X
<--------- MTP-Transfer
Check Stream id <------------- DATA Data with CIC X
TEST DESCRIPTION:
1. Send three or more Transfer Request Primitive from the NIF at SG
side to send Protocol Data to the ASP. In the Protocol Data CIC
values should be same in all Transfer Request primitive assuming
load sharing across streams is based on CIC.
2. Check A: DATA messages are received at the ASP1 containing the same
Stream Sequence number.
3. Repeat the above test with same SLS value in Protocol Data in all
Transfer Request primitive assuming load sharing across the streams
is based on SLS.
4. Repeat the above test case with different CIC values and different
SLS values. DATA messages should be sent on different streams.
Note: How the messages will be distributed on different streams based
on CIC and SLS is implementation dependent.
Sachin-Sunil, HSS [Page 13]
Internet Draft Test Specs for M3UA July 2000
"Transfer Request Primitive from NIF in AS Up State"
+ TEST NUMBER : 1.3.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : AS management
+ SUBTITLE : Transfer Request from NIF in AS Up State
+ PURPOSE: To check that If ASP is Up at SG and NIF sends Transfer
Primitive to send to that AS then it receives a send failure.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP1 is active. Also arrange the data in ASP such that ASPIA
message is sent from ASP1 to SG on stream 0. The Type field in APSIA
can be any valid value which is equal to the traffic handling mode
for the AS at the SG and Routing Context should be P.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
ASPIA --------------->
(ASP1) Status Ind -------->
<-------------- NTFY( ASP-Up)
<-------------- NTFY(AS-Up/AS-Pending)
<-------- MTP-Transfer
Send failure -------->
TEST DESCRIPTION:
1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to Up
state at the SG. Send MTP-Transfer Primitive with N/w Appearance A
containing Protocol Data with DPC X.
2. Check A: Send failure should be received at the NIF and DATA message
should not be sent to ASP.
3. Repeat the above test if ASPIA message is sent without Routing
Context Parameter. NTFY(ASP-Up) and NTFY(AS-Up) should be received
at the ASP with either all routing contexts configured at the SG or
with no routing context for the ASP.
4. Repeat the above test if instead of sending ASPIA message, SCTP
association between ASP and SG is removed.
Note: In some implementation there may be T(r) running on receiving
ASPDN or ASPIA message for the last ASP and for that time AS will
be in AS-Pending state. In that case let the timer T(r) expire
before sending the Transfer primitive.
Sachin-Sunil, HSS [Page 14]
Internet Draft Test Specs for M3UA July 2000
"MTP-Transfer Request Primitive from NIF in AS Down State"
+ TEST NUMBER : 1.3.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.1.1
+ TITLE : AS management
+ SUBTITLE : MTP-Transfer Request from NIF in AS Down State
+ PURPOSE: To check that if AS is down at SG and NIF sends MTP-Transfer
Primitive to send to that AS then it receives a send failure.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP1 is active. Also arrange the data in ASP such that ASPDN
message is sent from ASP1 to SG on stream 0. The Reason parameter in
ASPDN message can be any valid value.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
ASPIA --------------->
(ASP1) Status Ind --------->
<-------------- NTFY( ASP-Up)
<-------------- NTFY(AS-Up/AS-Pending)
ASPDN --------------->
(ASP1) Status Ind --------->
<-------------- NTFY( ASP-Down)
<-------------- NTFY(AS-Down/AS-Pending)
<-------- MTP-Transfer
Send failure -------->
TEST DESCRIPTION:
1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to Up
state at the SG.
2. Send ASPDN message from ASP to the SG. ASP will move to down state at
the SG. Send MTP-Transfer Primitive with N/w Appearance A containing
Protocol Data with DPC X.
3. Check A: Send failure should be received at the NIF and DATA message
should not be sent to ASP.
Note: In some implementation there may be T(r) running on receiving
ASPDN message for the last ASP and for that time AS will
be in AS-Pending state. In that case let the timer T(r) expire
before sending the MTP-Transfer primitive.
Sachin-Sunil, HSS [Page 15]
Internet Draft Test Specs for M3UA July 2000
"Timer T(r) Cancellation"
+ TEST NUMBER : 1.3.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : Timer T(r) Cancellation
+ PURPOSE: To check that after last ASP becomes inactive then SG
buffers the messages from NIF for time T(r) and if ASPAC comes before
its expiry then all buffered messages are sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP1 is active. Arrange the data in ASP such that ASPIA and
ASPAC messages are sent from ASP1 to SG on stream 0. The Type field
in APSIA and ASPAC can be any valid value and Routing Context should
be P. Let the value of Timer T(r) be z sec.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is active
ASPIA ----------------->
(ASP1) Status Ind -------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY(AS-Pending)
| Timer T(r) is started
|
| Time < z sec. <------- MTP-Transfer
| Message will be buffered
| <------- MTP-Transfer
| Message will be buffered
ASPAC --------------->
(ASP1) Status Ind -------->
<--------------- NTFY ( ASP-Active)
<--------------- NTFY(AS-Active)
<--------------- DATA
<--------------- DATA
Sachin-Sunil, HSS [Page 16]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASPIA Message from ASP1 to SG. ASP will become Up at the SG.
2. Send MTP-Transfer Primitive from NIF with N/w Appearance A
containing Protocol Data to be sent to DPC X.
3. Check A: DATA message will not be received at ASP.
4. Send ASPAC message containing N/w Appearance A before Timer T(r)
expires.
5. Check B: DATA messages buffered at the SG will be sent to the AS.
Note: This case is implementation specific. In some implementation
there may not be any Timer T(r) running. In that case there is no
need to run this test case.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 17]
Internet Draft Test Specs for M3UA July 2000
"Timer T(r) Expiry"
+ TEST NUMBER : 1.3.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : Timer T(r) Expiry
+ PURPOSE: To check that timer T(r) is cancelled on receiving ASPAC
message from the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP1 is active. Arrange data in ASP such that ASPIA and ASPAC
messages are sent from ASP1 to SG on stream 0. The Type field in
APSIA and ASPAC can be any valid value and Routing Context should be
P. Let the value of Timer T(r) is z sec.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is active
ASPIA ----------------->
(ASP1) Status Ind -------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY(AS-Pending)
| Timer T(r) is started
|
| Time < z sec. <------- MTP-Transfer
| Message will be buffered
| <------- MTP-Transfer
| Message will be buffered
ASPAC --------------->
(ASP1) Status Ind -------->
<--------------- NTFY ( ASP-Active)
<--------------- NTFY(AS-Active)
<--------------- DATA
<--------------- DATA
ASPIA ---------------->
Status Ind -------->
<--------------- NTFY (ASP-Up)
Sachin-Sunil, HSS [Page 18]
Internet Draft Test Specs for M3UA July 2000
<--------------- NTFY(AS-Pending)
|
|Time = z sec
|
|
- Status Ind --------->
<--------------- NTFY(AS-Up)
<-------- MTP-Transfer
Send Failure ------->
TEST DESCRIPTION:
1. Send ASPIA Message from AS to the SG. AS will be in AS-Pending state
at the SG.
2. Send MTP-Transfer Primitive with N/w appearance A containing
protocol Data to send to DPC X. Message will be buffered at SG.
3. Send ASPAC message from ASP before timer T(r) expires. DATA message
will be received at ASP.
4. Again send ASPIA message from ASP.
5. Check A: Timer T(r) is started again i.e. only after z sec AS will
move to the AS-Up state.
6. Send MTP-Transfer Primitive from NIF with N/w appearance A
containing protocol Data to send to DPC X. SG will send Send Failure.
7. Repeat the above test case if ASPDN message with any valid Reason
parameter is sent instead of ASPIA message.
Note: This case is implementation specific. In some implementation
there may not be any Timer T(r) running. In that case there is no
need to run this test case.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 19]
Internet Draft Test Specs for M3UA July 2000
"Notify Message with ASP and AS Status"
+ TEST NUMBER : 1.3.5
+ Reference: draft-ietf-sigtran-m3ua-03.txt Clause 3.3.3
+ TITLE : AS management
+ SUBTITLE : Notify Message with ASP and AS status
+ PURPOSE: To check that if ASPDN, ASPUP, ASPAC and ASPIA messages are
received in ASP-Active, ASP-Down, ASP-Up and ASP-Active state
respectively then NTFY message with correct status is sent to ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Also arrange the data in ASP such that ASPDN,
ASPUP, ASPAC and ASPIA messages are sent from ASP to SG for ASP and
these are sent on stream zero. The value of N/w Appearance is A and
Routing Context is P in all the messages and other parameters are
having valid values.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM
ASP is active
ASPDN --------------->
(ASP1) Status Ind ---------->
<-------------- NTFY( ASP-Down)
<-------------- NTFY(AS-Down)
ASPUP --------------->
(ASP1) Status Ind ----------->
<-------------- NTFY( ASP-Up)
<-------------- NTFY (AS-Up)
ASPAC --------------->
(ASP1) Status Ind ----------->
<-------------- NTFY( ASP-Active)
<-------------- NTFY (AS-Active)
Sachin-Sunil, HSS [Page 20]
Internet Draft Test Specs for M3UA July 2000
ASPIA --------------->
(ASP1) Status Ind ----------->
<-------------- NTFY( ASP-Up)
<-------------- NTFY (AS-Up)
TEST DESCRIPTION:
1. Send ASPDN message for ASP1 from ASP to the SG.
2. Check A: Two NTFY messages will be received at the ASP, with status
ASP-Down and AS-Down.
3. Send ASPUP message with ALI parameter M3UA and check that SG
responds with NTFY with status ASP-Up and AS-Up. Repeat the test
case with ALI parameter not present in ASPUP message.
4. Send ASPAC message with Routing Context P and check SG responds with
NTFY with status ASP-Active and AS-Active. Repeat the test case with
Routing Context parameter not present in ASPAC message.
5. Send ASPIA message and check that SG responds with NTFY with status
ASP-Up and AS-Up.
6. Check E: NTFY message is received on stream 0.
7. Repeat the above test case if all messages from ASP are sent on
stream other than zero.
Note: In some cases on receiving ASPIA the NTFY(AS-Pending) may come in
place of NTFY(AS-Up). This is implementation Specific.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 21]
Internet Draft Test Specs for M3UA July 2000
"Received DAUD Message "
+ TEST NUMBER : 1.3.6
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.3
+ TITLE : AS management
+ SUBTITLE : Received DAUD message
+ PURPOSE: To check that if DAUD message is received from ASP then SG
sends Status Request primitive to the NIF and state of ASP is not
changed at SG.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP1 is active. Also arrange the data in ASP such that DAUD
message is sent to the SG with Network Appearance A and Affected DPC
any value.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
AS is active
DAUD ------------->
Status Request ------>
<------ Pause/Resume/State
<------------ DUNA/DAVA/SCON
TEST DESCRIPTION:
1. Send DAUD message with N/w appearance A and affected DPC any value
from ASP to the SG.
2. Check A: Status Request Primitive is received at SM with the DPC and
N/w appearance received in the DAUD message.
3. Check B: State of AS will not be changed at SG. Send Pause/Resume
primitive with N/w appearance A and SG should send DUNA/DAVA message
to the ASP1.
4. Repeat the above test case if DAUD message is sent without N/w
Appearance parameter. Response should be same as in the above case.
Note: DUNA/DAVA/SCON message may be sent by M3UA itself in response to
DAUD message depending upon the implementation.
Sachin-Sunil, HSS [Page 22]
Internet Draft Test Specs for M3UA July 2000
"ASPAC message with more than one Routing Context"
+ TEST NUMBER : 1.3.7
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.4
+ TITLE : AS management
+ SUBTITLE : ASPAC message with more than one Routing Context
+ PURPOSE: To check that if ASPAC message is received with more than
one Routing Context then status of ASP is active in all the AS to
which this ASP belongs.
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1. ASP1 is belonging to two AS, AS1 and AS2. AS1 is handling
traffic for routing context P and AS2 is handling traffic for routing
context Q. ASP1 is in Up state i.e. AS1 and AS2 are in the AS-Up
state at SG. Also arrange the data in ASP1 such that ASPAC message is
sent from ASP1 to SG on stream 0 containing Routing Context P and Q.
Fill any valid value in the Type parameter which is same as
configured for AS1 and AS2 at the SG and it should be same for both
AS.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS1 & AS2 is Up
ASPAC ------------------>
Routing Context P and Q Status Ind --------->
<----------------- NTFY( ASP-Active)
<----------------- NTFY(AS-Active)
<-------- MTP-Transfer
for Routing Context P
<----------------- DATA
<-------- MTP-Transfer
for Routing Context Q
<----------------- DATA
Sachin-Sunil, HSS [Page 23]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASPAC Message with routing contexts P and Q to the SG.
2. Check A: Two NTFY messages should be received at ASP with status
ASP-Active and AS-Active with routing contexts P and Q.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is active in AS1 and AS2. This can
be checked by sending DATA messages containing protocol DATA for
both Routing Contexts.
Note: Routing Context is an optional parameter in the NTFY message.
Some implementation may not send this parameter in the NTFY
message. In that case two NTFY message with status
AS-Up/AS-Pending will be received one for AS1 and other for AS2.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 24]
Internet Draft Test Specs for M3UA July 2000
"ASPIA message with more than one Routing Context"
+ TEST NUMBER : 1.3.8
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : ASPIA message with more than one Routing Context
+ PURPOSE: To check that If ASPIA message is received with more than
one Routing Context then status of ASP is up in all the AS to which
this ASP belongs.
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS. ASP1 is belonging to two AS, AS1 and AS2. AS1 is handling traffic
for routing context P and AS2 is handling traffic for routing context
Q. ASP1 is in Active state i.e. AS1 and AS2 are in the AS-Active
state at SG. Also arrange the data in ASP1 such that ASPIA message is
sent on stream 0 from ASP1 to SG containing Routing Context P and Q.
Fill any valid value in the Type parameter which is same as
configured for AS1 and AS2 in SG and it should be same for both AS.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS1 & AS2 is Active
ASPIA ------------------>
Routing Context P and Q Status Ind --------->
<----------------- NTFY( ASP-Up)
<----------------- NTFY(AS-Up/AS-Pending)
<-------- MTP-Transfer
Routing Context P
Send Failure -------->
<-------- MTP-Transfer
Routing Context Q
Send Failure -------->
Sachin-Sunil, HSS [Page 25]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASPIA Message containing routing contexts P and Q from ASP1 to
the SG.
2. Check A: NTFY message should be received at the ASP with status
ASP-Up and AS-Up/AS-Pending with routing contexts P and Q.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is Up in AS1 and AS2. This can be
checked by sending MTP-Transfer primitive from NIF at SG containing
protocol DATA for both Routing Contexts.
Note: Routing Context is an optional parameter in the NTFY message.
Some implementation may not send this parameter in the NTFY
message. In that case two NTFY message with status
AS-Up/AS-Pending will be received one for AS1 and other for AS2.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 26]
Internet Draft Test Specs for M3UA July 2000
"Notify Message with AS Status is sent only for AS State change -A"
+ TEST NUMBER : 1.3.9
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.1.2
+ TITLE : AS management
+ SUBTITLE : Notify Message with AS Status is sent only for AS State
change
+ PURPOSE: To check that NTFY message with AS state change is not sent
if there is no change in the state of the AS.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS. Both ASP are having SCTP association with SG and are active in
the AS. Arrange data in AS such that ASPUP, ASPAC, ASPIA and ASPDN
messages are sent to the SG from ASP1 on stream 0. Fill the routing
contexts P and Type parameter any valid value which is same
configured for AS at the SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM
Both ASP are active
ASPIA(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
Check: NTFY(AS-Up) is not received
Status Ind --------->
ASPDN(ASP1) ----------------->
<---------------- NTFY( ASP-Down)
Check: NTFY(AS-Down) is not received
Status Ind --------->
ASPUP(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
Check: NTFY(AS-Up) is not received
Status Ind --------->
ASPAC(ASP1) ----------------->
<---------------- NTFY( ASP-Active)
Check: NTFY(AS-Active) is not received
Status Ind --------->
Sachin-Sunil, HSS [Page 27]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASPIA message for ASP1 from ASP to the SG with routing context
P and Type parameter any valid value.
2. Check A: NTFY messages with status ASP-Up is received at the AS and
NTFY message with status AS-Up is not received as AS is already Up.
3. Repeat the above test case for other messages like ASPDN, ASPUP and
ASPAC for ASP1 from AS to SG.
Sachin-Sunil, HSS [Page 28]
Internet Draft Test Specs for M3UA July 2000
"Notify Message with AS Status is sent only for AS State change -B"
+ TEST NUMBER : 1.3.10
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.1.2
+ TITLE : AS management
+ SUBTITLE : Notify Message with AS Status Change
+ PURPOSE: To check that NTFY message with AS state change is sent
if AS state has changed.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS. Both ASP are having SCTP association with SG and are active in
the AS. Arrange data in AS such that ASPUP, ASPAC, ASPIA and ASPDN
messages are sent to the SG from ASP1 and ASP2 on stream 0. Fill the
routing contexts P and Type parameter any valid value which is same
configured for AS at the SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM
Both ASP are active
ASPIA(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
Status Ind --------->
ASPIA(ASP2) ----------------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-Up/AS-Pending)
Status Ind --------->
ASPDN(ASP1) ----------------->
<---------------- NTFY( ASP-Down)
Status Ind --------->
ASPDN(ASP2) ----------------->
<---------------- NTFY( ASP-Down)
<---------------- NTFY( AS-Down/AS-Pending)
Status Ind --------->
Sachin-Sunil, HSS [Page 29]
Internet Draft Test Specs for M3UA July 2000
ASPUP(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
Status Ind --------->
ASPUP(ASP2) ----------------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-Up)
Status Ind --------->
ASPAC(ASP1) ----------------->
<---------------- NTFY( ASP-Active)
Status Ind --------->
ASPAC(ASP2) ----------------->
<---------------- NTFY( ASP-Active)
<---------------- NTFY( AS-Active)
Status Ind --------->
TEST DESCRIPTION:
1. Send ASPIA message for ASP1 and ASP2 from ASP to the SG with routing
context P and Type parameter any valid value.
2. Check A: NTFY messages with status ASP-Up and AS-Up is received at
the AS.
3. Check B: NTFY messages are received on stream 0.
3. Repeat the above test case for other messages like ASPDN, ASPUP and
ASPAC for ASP1 from AS to SG.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 30]
Internet Draft Test Specs for M3UA July 2000
"MTP-Pause Indication Primitive:"
+ TEST NUMBER : 1.4.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.1
+ TITLE : MTP3 management
+ SUBTITLE : MTP-Pause Indication Primitive
+ PURPOSE: To check that if MTP-Pause indication primitive is received
from NIF at SG then SG sends DUNA message to the concerned AS.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B. Also arrange the data in NIF at SG such that
MTP-Pause Indication Primitive is sent to the AS with Network
Appearance A and B and affected DPC any value.
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 AS3 SG NIF
All AS are active
<---------- MTP-Pause
N/w Appearance A
Affected DPC T
<---------------------------- DUNA
<----------------- DUNA
<---------- MTP-Pause
N/w Appearance B
Affected DPC T
<--------- DUNA
TEST DESCRIPTION:
1. Send MTP-Pause indication Primitive message from NIF in the SG
containing the Network Appearance A and Affected DPC T.
2. Check A: DUNA message will be received at the ASP1 and ASP2
containing the network Appearance A and Affected DPC T.
3. Check B: DUNA message is received at both AS AS1 and AS2 which are
handling traffic for the same network appearance.
4. Check C: DUNA message is received on the Stream number 0.
5. Repeat the above test case with N/w Appearance B. In this case DUNA
message should be sent to AS3.
Sachin-Sunil, HSS [Page 31]
Internet Draft Test Specs for M3UA July 2000
"MTP-Resume Indication Primitive"
+ TEST NUMBER : 1.4.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.1
+ TITLE : MTP3 management
+ SUBTITLE : MTP-Resume Indication Primitive
+ PURPOSE: To check that if MTP-Resume indication primitive is received
from NIF at SG then SG sends DAVA message to the concerned AS.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B. Also arrange the data in NIF at SG such that
MTP-Resume Indication Primitive is sent to the AS with Network
Appearance A and B and affected DPC any value.
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 AS3 SG NIF
All AS are active
<---------- MTP-Resume
N/w Appearance A
Affected DPC T
<---------------------------- DAVA
<----------------- DAVA
<---------- MTP-Resume
N/w Appearance B
Affected DPC T
<--------- DAVA
TEST DESCRIPTION:
1. Send MTP-Resume indication Primitive from NIF in the SG containing
the Network Appearance A and Affected DPC T.
2. Check A: DAVA message is received at AS1 and AS2 containing the
network Appearance A and Affected DPC T.
3. Check B: DAVA message is received at AS1 and AS2
4. Check C: DAVA message is received on the Stream number 0.
5. Repeat the test case for N/w appearance B and affected destination
any value. Check that message is being sent to AS3.
Sachin-Sunil, HSS [Page 32]
Internet Draft Test Specs for M3UA July 2000
"MTP-Status Indication Primitive with Route Congested"
+ TEST NUMBER : 1.4.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.1
+ TITLE : MTP3 management
+ SUBTITLE : MTP-Status Indication Primitive with Route Congested
+ PURPOSE: To check that if MTP-Status indication primitive with Route
Congested parameter is received from NIF at SG then SG sends SCON
message to the concerned AS.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B. Also arrange the data in NIF at SG such that
MTP-Status indication Primitive is sent to the SG with cause Routing
Congested, affected DPC, Congestion level and Network Appearance.
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 AS3 SG NIF
All AS are active
<---------- MTP-Status
N/w Appearance A
DPC T Cong Level 0
<---------------------------- SCON
<----------------- SCON
<---------- MTP-Status
N/w Appearance B
DPC T Cong Level 2
<--------- SCON
TEST DESCRIPTION:
1. Send MTP-Status indication Primitive from NIF in the SG containing
the Network Appearance A, cause Route congestion, Affected DPC X and
congestion Level 2.
2. Check A: SCON message is received at the AS1 and AS2 containing the
network Appearance A, Affected DPC X, Congestion Level 2 passed to it
from NIF.
3. Check B: SCON message is received at AS1 and AS2.
4. Check C: SCON message is received on the Stream number 0.
5. Repeat the above test case for all congestion level 0,1,2 and 3.
SCON message will be received with congestion level passed from NIF.
6. Repeat the above test case with different congestion level for
different affected DPC. SCON message should contain the correct
congestion level for each affected destination.
7. Repeat the above test case with N/w appearance B. SCON message will
be received at AS3.
Sachin-Sunil, HSS [Page 33]
Internet Draft Test Specs for M3UA July 2000
"MTP-Status Indication Primitive with User Part Unavailable"
+ TEST NUMBER : 1.4.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.1
+ TITLE : MTP3 management
+ SUBTITLE : MTP-Status Indication Primitive with User Part Unavailable
+ PURPOSE: To check that if MTP-Status indication primitive with cause
User Part Unavailable is received from NIF at SG then SG sends DUPU
message to the concerned AS.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are
handling traffic for N/w appearance A and AS3 is handling traffic for
N/w Appearance B. Also arrange the data in NIF at SG such that
MTP-Status indication Primitive is sent to the SG with cause User
Part Unavailable Unknown, affected DPC, SIO for ISUP and network
appearance A. Assume routing context is DPC+SIO based.
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 AS3 SG NIF
All AS are active
<---------- MTP-Status
N/w Appearance A
DPC S
<---------------------------- DUPU
<----------------- DUPU
<---------- MTP-Status
N/w Appearance B
DPC S
<--------- DUPU
Sachin-Sunil, HSS [Page 34]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send MTP-Status indication Primitive from NIF in the SG containing
the Network Appearance A, cause User Part Unavailable, Affected DPC
S and SIO for ISUP.
2. Check A: SG will send DUPU message containing the network Appearance
A, Affected DPC S, cause unknown and user ISUP.
3. Check B: DUPU message is received at AS1 and AS2.
4. Check C: DUPU message is received on the Stream number 0.
5. Repeat the above test case with cause values Unequipped Remote User
and Inaccessible Remote User and other parameters being the same as
in the above tests. DUPU message will be received with these cause
values.
6. Repeat the above test case with SIO values TUP, Broadband ISUP,
Satellite ISUP and Reserved.
7. Repeat the above test case if MTP-Status is sent with N/w appearance
B. DUPU message will be sent to AS3.
Sachin-Sunil, HSS [Page 35]
Internet Draft Test Specs for M3UA July 2000
"Invalid Version Error"
+ TEST NUMBER : 1.5.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Version Error
+ PURPOSE: To check that if any message with Invalid version is
received at the SG then SG responds with ERROR message containing
cause "Invalid Version" and diagnostic information filled with the
version the SG supports.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Also arrange the data in ASP such that ASPIA
message is sent with the version other than Release 1.0 protocol to
SG. Type field can be any valid value and fill the routing context
with any value.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is active
ASPIA ---------------->
Version = 2
<--------------- ERROR
Cause = Invalid Version
TEST DESCRIPTION:
1. Send ASPIA message AS to SG containing version 2 in the common
header.
2. Check A: ERROR message is received at the ASP containing cause
Invalid Version.
3. Check B: Diagnostic Field Parameter in ERROR is filled with version
1.
4. Repeat the above test cases for other messages from AS to SG like
ASPAC, ASPUP, ASPDN, DAUD and DATA. In all these cases ERROR message
will be received with the same cause.
Sachin-Sunil, HSS [Page 36]
Internet Draft Test Specs for M3UA July 2000
"Invalid Traffic Handling Mode Error"
+ TEST NUMBER : 1.5.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Traffic Handling Mode Error
+ PURPOSE: To check that if ASPAC or ASPIA message is received with
Type parameter incompatible with the traffic handling mode currently
used in AS at SG, SG responds with ERROR message containing cause
"Invalid Traffic Handling Mode".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP1 is Up. Arrange the data in ASP such that ASPAC
message is sent with Type field filled with Loadshare mode of Traffic
handling. Traffic Handling Mode defined at SG for AS is Override.
Fill value P in Routing context parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Up
ASPAC ---------------->
Type = Loadshare
<--------------- ERROR
Cause = Invalid traffic Handling Mode
TEST DESCRIPTION:
1. Send ASPAC message from AS to SG containing Type field Loadshare.
Mode of Traffic handling for AS at SG is Override.
2. Check A: ERROR message is received at the ASP containing cause
Invalid Traffic Handling Mode.
3. Repeat the above test cases for other values of Type field with
Traffic Handling Mode for AS at SG being different from this Type
field.
4. Repeat the test case with Type field having value that is not
defined i.e any value greater than 0x03.
5. Repeat all the above tests for ASPIA message.
Sachin-Sunil, HSS [Page 37]
Internet Draft Test Specs for M3UA July 2000
"Invalid Traffic Handling Mode Error if there are two ASP in one AS"
+ TEST NUMBER : 1.5.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Traffic Handling Mode Error if there are two ASP
in one AS
+ PURPOSE: To check that if ASPAC or ASPIA message is received with
Type parameter incompatible with the traffic handling mode currently
used in AS at SG, SG responds with ERROR message containing cause
"Invalid Traffic Handling Mode".
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP1 and ASP2 are Up. Arrange the data in ASP such that ASPAC
message for ASP1 is sent with Type field filled with Override mode of
Traffic handling and ASPAC message for ASP2 is sent with Type field
filled with Loadshare mode of Traffic handling. Traffic Handling Mode
defined at SG for AS is Override Mode. Fill value P in Routing
context parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Up
ASPAC(ASP1)---------------->
Type = Override Status Ind ------->
<--------------- NTFY(ASP-Active)
<--------------- NTFY(AS-Active)
ASPAC(ASP2) ---------------->
Type = Loadshare
<--------------- ERROR
Cause = Invalid traffic Handling Mode
Sachin-Sunil, HSS [Page 38]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASPAC message from ASP1 to SG containing Type field Override.
2. Check A: NTFY messages is received at the ASP with status ASP-Active
and AS-Active.
3. Send ASPAC message from ASP2 to SG containing Type field Loadshare.
4. Check B: ERROR message is received at the ASP containing cause
Invalid Traffic Handling Mode.
3. Repeat the above test cases for other values of Type field with
Traffic Handling Mode for AS at SG being different from this Type.
4. Repeat the test case with Type field having value that is not
defined.
5. Repeat all the above tests for ASPIA message.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 39]
Internet Draft Test Specs for M3UA July 2000
"Unrecognised Message Type"
+ TEST NUMBER : 1.5.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Unrecognised Message Type
+ PURPOSE: To check that if a message with message type not defined is
received at SG, SG responds with ERROR message containing cause
"Invalid Message Type".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP1 is active. Arrange the data in ASP such that a message
with Message type not defined is sent to SG. Let the other parameters
in the message be like any other message.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is Active
Message ---------------->
Message Type=0408
<--------------- ERROR
Cause = Invalid Message Type
DATA ---------------->
N/w Appearance A
MTP-Transfer Ind ------->
TEST DESCRIPTION:
1. Send a message with message type 0408 or any other value which is
not defined from AS to SG
2. Check A: ERROR message is received at the ASP containing cause
Invalid Message Type.
3. Check B: State of AS at SG is not disturbed.
4. Repeat the above test cases by sending DUNA, DAVA, DUPU, SCON
messages from AS which the SG is not expected to receive. In this
case Error will be reported to the SM and Message will be discarded.
Sachin-Sunil, HSS [Page 40]
Internet Draft Test Specs for M3UA July 2000
"Invalid Network Appearance"
+ TEST NUMBER : 1.5.5
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Network Appearance
+ PURPOSE: To check that if a message with invalid network appearance
i.e. network appearance not defined at SG then SG responds with ERROR
message containing cause "Invalid Network Appearance".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data
in AS such that DATA message with Network Appearance other than A is
sent to SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Active
DATA ---------------->
N/w Appearance B
<--------------- ERROR
Cause = Invalid N/w Appearance
DATA ---------------->
N/w Appearance A
MTP-Transfer Ind ------->
TEST DESCRIPTION:
1. Send DATA message with network appearance B which is not defined at
SG.
2. Check A: ERROR message containing cause Invalid Network Appearance
should be received at AS.
3. Check B: State of AS at SG is not disturbed.
Note: Network Appearance parameter is optional. In some implementation
this parameter may not come in DATA message. In those
implementations, this test case need not be tested.
Sachin-Sunil, HSS [Page 41]
Internet Draft Test Specs for M3UA July 2000
"Invalid Reason parameter in ASPDN message"
+ TEST NUMBER : 1.5.6
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Reason Parameter in ASPDN message
+ PURPOSE: To check that if ASPDN message with Invalid Reason parameter
is received then ASPDN message is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data
in AS such that ASPDN message with Reason Parameter filled with value
03 or more is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Active
ASPDN ---------------->
Reason = 0x3 Status Ind -------->
<--------------- NTFY(ASP-Down)
<--------------- NTFY(AS-Down)
TEST DESCRIPTION:
1. Send ASPDN message with Reason Parameter 0x3 from ASP to SG.
2. Check A: NTFY messages with status ASP-Down and AS-Down are
received.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 42]
Internet Draft Test Specs for M3UA July 2000
"Invalid ALI parameter in ASPUP message"
+ TEST NUMBER : 1.5.7
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid ALI Parameter in ASPUP message
+ PURPOSE: To check that if ASPUP message with Invalid ALI parameter is
received then ASPUP message is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in
AS such that ASPUP message for the ASP1 with ALI Parameter filled
with value other than M3UA is sent to SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
AS is Active
ASPUP ---------------->
ALI <> M3UA
DATA ---------------->
N/w Appearance A
MTP-Transfer Ind ------->
TEST DESCRIPTION:
1. Send ASPUP message from ASP1 with ALI Parameter not equal to M3UA.
2. Check A: SG will take no action and will discard the ASPUP message.
3. Check B: State of AS at SG is not disturbed.
Note: ALI is an optional parameter. In some implementation this
parameter may not come in ASPUP message. In these implementation
this test case need not be run.
Sachin-Sunil, HSS [Page 43]
Internet Draft Test Specs for M3UA July 2000
"Invalid routing context parameter in ASPAC message"
+ TEST NUMBER : 1.5.8
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid routing context Parameter in ASPAC message
+ PURPOSE: To check that if ASPAC message with Invalid routing context
parameter is received then ASPAC message is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange the data in AS
such that ASPAC message with Routing Context P is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
AS is Up
ASPAC ---------------->
Routing context Q
ASPAC ---------------->
Routing context P and Q
Status Ind --------->
<--------------- NTFY(ASP-Active with routing context P)
<--------------- NTFY(AS-Active with routing context P)
TEST DESCRIPTION:
1. Send ASPAC message with routing context Q.
2. Check A: SG will take no action and will discard the ASPAC message.
3. Send ASPAC message with routing context P and Q.
4. Check B: NTFY message will be sent with status ASP-Active and
AS-Active for routing context P.
Note: Routing context is an optional parameter in ASPAC message. In
some implementation this field may not come in ASPAC message. In
those implementation this test case need not be run.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Note2: Routing context is an optional parameter in NTFY message. In
some implementation this field may not be present in NTFY
message. In those implementation this in response to ASPAC
message with routing context P and Q, NTFY message may not be
returned but ASPAC message may be discarded.
Sachin-Sunil, HSS [Page 44]
Internet Draft Test Specs for M3UA July 2000
"Invalid routing context parameter in ASPIA message"
+ TEST NUMBER : 1.5.9
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid routing context Parameter in ASPIA message
+ PURPOSE: To check that if ASPIA message with Invalid routing context
parameter is received then ASPIA message is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data
in AS such that ASPIA message with Routing Context Q is sent to the
SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
AS is Active
ASPIA ---------------->
Routing context Q
ASPIA ---------------->
Routing context P and Q
Status Ind --------->
<--------------- NTFY(ASP-Up with routing context P)
<--------------- NTFY(AS-Up with routing context P)
TEST DESCRIPTION:
1. Send ASPIA message with Routing Context Q.
2. Check A: SG will take no action and will discard the ASPIA message.
3. Send ASPIA message with Routing Context P and Q.
4. Check B: NTFY message will be sent with status ASP-Up and AS-Up for
routing context P.
Note: Routing context is an optional parameter in ASPIA message. In
some implementation this field may not come in ASPIA message. In
those implementation this test case need not be run.
Note2: Routing context is an optional parameter in NTFY message. In
some implementation this field may not be present in NTFY
message. In those implementation this in response to ASPIA
message with routing context P and Q, NTFY message may not be
returned but ASPIA message may be discarded.
Sachin-Sunil, HSS [Page 45]
Internet Draft Test Specs for M3UA July 2000
"Message length less than the length of mandatory Parameters"
+ TEST NUMBER : 1.5.10
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Message length less than the length of mandatory
parameters
+ PURPOSE: To check that if a message with value of length parameter
less than length of mandatory parameters is received then message is
discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Active state. Arrange the data in AS such that
ASPIA message with length parameter filled with value less than the
length of type parameter is sent on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
AS is Active
ASPIA ---------------->
Message Length = 2
DATA ---------------->
N/w appearance A
MTP-Transfer --------->
TEST DESCRIPTION:
1. Send ASPIA message with length parameter filled with value less than
the length of type field to the SG.
2. Check A: SG will take no action and will discard the ASPIA message.
3. Check B: State of AS at SG is not disturbed.
4. Repeat the above test case for other messages like ASPAC, ERROR,
ASPDN.
Sachin-Sunil, HSS [Page 46]
Internet Draft Test Specs for M3UA July 2000
"ASPUP message in ASP-Up state"
+ TEST NUMBER : 1.6.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.1
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPUP message in ASP-Up state
+ PURPOSE: To check that if ASPUP message is received in ASP-Up state
then NTFY message with status ASP-Up is sent to the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in
AS such that ASPUP message with valid ALI parameter is sent to the SG
two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Down
ASPUP ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up)
ASPUP ---------------->
<--------------- NTFY(ASP-Up)
ASPAC ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Active)
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPUP message to the SG in ASP-Down state. NTFY (ASP-Up) and
NTFY (AS-Up) messages will come from the SG. Send ASPUP message
again from the AS for the same ASP.
2. Check A: NTFY message with status ASP-Up should be received at AS.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in
the Up state. Send ASPAC message with valid Type and Routing Context
for the ASP1 and NTFY with ASP-Active should come.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 47]
Internet Draft Test Specs for M3UA July 2000
"ASPDN message in ASP-Down state"
+ TEST NUMBER : 1.6.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.2
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPDN message in ASP-Down state
+ PURPOSE: To check that if ASPDN message is received in ASP-Down state
then NTFY message with status ASP-Down is sent to the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange the data in AS
such that ASPDN message is sent to the SG two times with the valid
Reason Parameter on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Up
ASPDN ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Down)
<--------------- NTFY(AS-Down)
ASPDN ---------------->
<--------------- NTFY(ASP-Down)
ASPUP ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up)
TEST DESCRIPTION:
1. Send ASPDN message to the SG in ASP-Up state. NTFY (ASP-Down) and
NTFY (AS-Down) messages will come from the SG. Send ASPDN message
again from the AS for ASP1.
2. Check A: NTFY message with status ASP-Down should be received at AS.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Down state. Send ASPUP message with valid ALI for the ASP and NTFY
with status ASP-Up should come.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 48]
Internet Draft Test Specs for M3UA July 2000
"ASPAC message in ASP-Active state"
+ TEST NUMBER : 1.6.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPAC message in ASP-Active state
+ PURPOSE: To check that if ASPAC message is received in ASP-Active
state then NTFY message with status ASP-Active is sent to the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange the data in AS
such that ASPAC message with correct Type (Type is same as defined at
SG for the AS) and routing context P is sent to the SG two times on
stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Up
ASPAC ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Active)
<--------------- NTFY(AS-Active)
ASPAC ---------------->
<--------------- NTFY(ASP-Active)
DATA ---------------->
MTP-Transfer Ind ------->
TEST DESCRIPTION:
1. Send ASPAC message to the SG in ASP-Up state. NTFY (ASP-Active) and
NTFY (AS-Active) messages will come from the SG. Send ASPAC message
again from the AS for the same ASP.
2. Check A: NTFY (ASP-Active) message should be received at ASP.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Active state. Send DATA message for the ASP and SG should send
MTP-Transfer indication to the NIF.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 49]
Internet Draft Test Specs for M3UA July 2000
"ASPIA message in ASP-Up state"
+ TEST NUMBER : 1.6.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPIA message in ASP-Up state
+ PURPOSE: To check that if ASPIA message is received in ASP-Up state
then NTFY message with status ASP-Up is sent to the AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Active state i.e. AS1 is active. Arrange the data
in AS such that ASPIA message with correct Type(Type is same as
defined at SG for the AS) and Routing Context P is sent to the SG two
times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Active
ASPIA ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up/AS-Pending)
ASPIA ---------------->
<--------------- NTFY(ASP-Up)
ASPAC ---------------->
Status Ind ------->
<--------------- NTFY(ASP-Active)
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPIA message to the SG in ASP-Active state. NTFY (ASP-Up) and
NTFY (AS-Up) messages will come from the SG. Send ASPIA message
again from the AS for the same ASP.
2. Check A: NTFY message with status ASP-Up will come from SG.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Up state. Send ASPAC message with correct Type ((Type is same as
defined at SG for the AS) for the ASP1 and SG should respond with
NTFY message with status ASP-Active.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 50]
Internet Draft Test Specs for M3UA July 2000
"ASPAC message in ASP-Down state"
+ TEST NUMBER : 1.6.5
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPAC message in ASP-Down state
+ PURPOSE: To check that if ASPAC message is received in ASP-Active
state then message is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in
AS such that ASPAC message with correct Type (Type is same as defined
at SG for the AS) and routing context P is sent to the SG on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS is Down
ASPAC ---------------->
<--------------- NTFY(ASP-Down)
ASPUP ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up)
TEST DESCRIPTION:
1. Send ASPAC message to the SG in ASP-Down state.
2. Check A: NTFY with status ASP-Down should be received at the ASP.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Down state. Send ASPUP message with correct ALI for the ASP and SG
should respond with NTFY message with status ASP-Up and AS-Up.
4. Repeat the above test case for ASPIA message.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 51]
Internet Draft Test Specs for M3UA July 2000
"ASPUP message in ASP-Active state"
+ TEST NUMBER : 1.6.6
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPUP message in ASP-Active state
+ PURPOSE: To check that if ASPUP message is received in ASP-Active
state then NTFY message with status ASP-Up is sent to AS and ASP
state is moved to ASP-up.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and ASP1 is Active. Arrange the data in AS such that ASPUP message
with valid ALI parameter is sent to the SG on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is Active
ASPUP ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up/AS-Pending)
ASPAC ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Active)
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPUP message to the SG in ASP-Active state.
2. Check A: NTFY message with ASP-Up status should be received at ASP.
3. Check B: State of ASP should become ASP-Up. Send ASPAC message with
correct Type (Type is same as defined at SG for the AS) and routing
context P to the SG and SG should send NTFY with Status ASP-Active.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 52]
Internet Draft Test Specs for M3UA July 2000
"ASPDN message in ASP-Active state"
+ TEST NUMBER : 1.6.7
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : ASPDN message in ASP-Active state
+ PURPOSE: To check that if ASPDN message is received in ASP-Active
state then NTFY message with status ASP-Down is sent to AS and State
of ASP at SG becomes ASP-Down.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and ASP1 is Active. Arrange the data in AS such that ASPUP message
with valid Reason parameter is sent to the SG on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is Active
ASPDN ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Down)
<--------------- NTFY(AS-Down/AS-Pending)
ASPUP ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up)
TEST DESCRIPTION:
1. Send ASPDN message to the SG in ASP-Active state.
2. Check A: NTFY message with ASP-Down status is received at ASP.
3. Check B: State of ASP should become Down. Send ASPUP message with
ALI parameter to the SG and SG should send NTFY with Status ASP-Up.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 53]
Internet Draft Test Specs for M3UA July 2000
"DATA message from AS in ASP-Down state"
+ TEST NUMBER : 1.6.8
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : DATA message from AS in ASP-Down state
+ PURPOSE: To check that if DATA message is received in ASP-Down state
then it is discarded.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and ASP1 is Down. Arrange the data in AS such that DATA message
with N/w Appearance A is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is Dpwn
DATA ---------------->
<--------------- NTFY(ASP-Down)
ASPUP ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Up)
<--------------- NTFY(AS-Up)
TEST DESCRIPTION:
1. Send DATA message to the SG in ASP-Down state.
2. Check A: DATA message should be discarded and NTFY(ASP-Down) should
be received at the ASP.
3. Check that state of SG is not disturbed. Send ASPUP message with
valid ALI parameter on stream 0 and SG should respond with
NTFY(ASP-Up).
Sachin-Sunil, HSS [Page 54]
Internet Draft Test Specs for M3UA July 2000
"ASPM message when SG has locked out the ASP for management reason"
+ TEST NUMBER : 1.7
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.2
+ TITLE : AS management
+ SUBTITLE : ASPM message when SG has locked out the ASP for management
reason
+ PURPOSE: To check that if ASPM message is received when SG has locked
out the ASP for managemet reason then NTFY message with status
ASP-Down is sent to AS .
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and ASP may be in any state. Arrange the data in SG such that ASP
is locked out at the SG. Arrange the data in AS such that ASPM
messages with valid parameters are sent to the SG on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
<---------- Lock_ASP
ASPUP ---------------->
<--------------- NTFY(ASP-Down)
TEST DESCRIPTION:
1. Lock out the ASP at the SG by sending primitive for locking ASP
from SM. Now send ASPUP message with valid parameters from ASP to SG.
2. Check A: NTFY message with ASP-Down status is received at ASP.
3. Repeat the above test case for other ASPM messages like ASPAC, ASPIA
and ASPDN messages from ASP to the SG with valid parameters.
Response should be same.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 55]
Internet Draft Test Specs for M3UA July 2000
"Message Routing based on DPC"
+ TEST NUMBER : 1.8.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.1
+ TITLE : Message Routing
+ SUBTITLE : Message Routing towards ASP
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing
Protocol DATA to send to the AS then it is sent to the correct AS.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
all ASP i.e. ASP1, ASP2 and ASP3 and all ASP are in Active state.
Also arrange the data in NIF at SG such that MTP-Transfer Indication
Primitives is sent to the AS with following parameter combination:
Protocol Data and N/w Appearance A and DPC X
Protocol Data and N/w Appearance A and DPC Y
Protocol Data and N/w Appearance B and DPC Z
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 AS3 SG NIF
All AS are active
<---------- MTP-Transfer Ind
N/w Appearance A
DPC X
<---------------------------- DATA
<---------- MTP-Transfer Ind
N/w Appearance A
DPC Y
<---------------- DATA
<---------- MTP-Transfer Ind
N/w Appearance B
DPC Z
<-------- DATA
TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in SG containing the
Protocol Data with DPC X and N/w appearance A.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing
Protocol Data with DPC Y and N/w appearance A.
4. Repeat the above test case for MTP-Transfer Ind primitive containing
Protocol Data with DPC Z and N/w appearance B.
Sachin-Sunil, HSS [Page 56]
Internet Draft Test Specs for M3UA July 2000
"Message Routing based on DPC+CIC"
+ TEST NUMBER : 1.8.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.1
+ TITLE : Message Routing
+ SUBTITLE : Message Routing based on DPC+CIC
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing
Protocol DATA to send to the AS then it is sent to the correct AS.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
all ASP i.e. ASP1 and ASP2 and all ASP are in Active state. Routing
context P consists of DPC X and CIC 1 to 31. Routing context Q
consists of DPC X and CIC 33 to 63. Also arrange the data in NIF at
SG such that MTP-Transfer Indication Primitives is sent to the AS
with the following parameter combination:
Protocol Data with DPC X and CIC 3
Protocol Data with DPC X and CIC 35
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 SG NIF
All AS are active
<---------- MTP-Transfer Ind
DPC X CIC 3
<---------------------------- DATA
<---------- MTP-Transfer Ind
DPC X CIC 35
<---------------- DATA
TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing
the Protocol Data with DPC X and CIC value 3.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing
Protocol Data with DPC X and CIC value 35. DATA message should be
received at AS2
Sachin-Sunil, HSS [Page 57]
Internet Draft Test Specs for M3UA July 2000
"Message Routing based on DPC+SSN"
+ TEST NUMBER : 1.8.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.1
+ TITLE : Message Routing
+ SUBTITLE : Message Routing based on DPC+SSN
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing
Protocol DATA to send to the AS then it is sent to the correct AS.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
all ASP i.e. ASP1and ASP2 and all ASP are in Active state. Routing
context P consists of DPC X and SSN S. Routing context Q consists of
DPC X and SSN T. Also arrange data in NIF at SG such that MTP-Transfer
Indication Primitives is sent to the AS with the following parameter
combination:
Protocol Data with DPC X and SSN S
Protocol Data with DPC X and SSN T
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 SG NIF
All AS are active
<---------- MTP-Transfer Ind
DPC X SSN S
<---------------------------- DATA
<---------- MTP-Transfer Ind
DPC X SSN T
<---------------- DATA
TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing
the Protocol Data with DPC X and SSN value S.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing
Protocol Data with DPC X and SSN value T. DATA message should be
received at AS2
Sachin-Sunil, HSS [Page 58]
Internet Draft Test Specs for M3UA July 2000
"Message Routing based on DPC+SIO"
+ TEST NUMBER : 1.8.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.1
+ TITLE : Message Routing
+ SUBTITLE : Message Routing based on DPC+SIO
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing
Protocol DATA to send to the AS then it is sent to the correct AS.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
all ASP i.e. ASP1and ASP2 and all ASP are in Active state. Routing
context P consists of DPC X and SIO S. Routing context Q consists of
DPC X and SIO T. Also arrange the data in NIF at SG such that
MTP-Transfer Indication Primitives is sent to the AS with the
following parameter combination:
Protocol Data with DPC X and SIO S
Protocol Data with DPC X and SIO T
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 SG NIF
All AS are active
<---------- MTP-Transfer Ind
DPC X SIO S
<---------------------------- DATA
<---------- MTP-Transfer Ind
DPC X SIO T
<---------------- DATA
TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing
the Protocol Data with DPC X and SIO value S.
2. Check A: DATA message will be received at the AS1.
3. Repeat the above test case for MTP-Transfer Ind primitive containing
Protocol Data with DPC Y and SIO value T. DATA message should be
received at AS2
Sachin-Sunil, HSS [Page 59]
Internet Draft Test Specs for M3UA July 2000
"Routing for Data not matching any routing context"
+ TEST NUMBER : 1.8.5
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.1
+ TITLE : Message Routing
+ SUBTITLE : Routing for Data not matching any routing context
+ PURPOSE: To check that if NIF sends a MTP-Transfer message containing
Protocol DATA which does not match to any routing context then
default routing is given to this message.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1 and ASP2 and ASP and ASP2 are Active. Routing context P consists
of DPC X and SSN S. Routing context Q consists of DPC X and SSN T.
Also arrange the data in NIF at SG such that MTP-Transfer Indication
Primitives is sent to the AS with DPC X and SSN other than S or T.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
AS is Active
<----------- MTP-Transfer Ind
DPC X & SSN <> S or T
Error ---------->
TEST DESCRIPTION:
1. Send MTP-Transfer indication Primitive from NIF in the SG containing
the Protocol Data having DPC and SSN such that theu don't match any
routing key.
2. Check A: Error should be returned or some default routing will be
given to this message.
3. Repeat the above test case if routing context is defined based on
DPC+CIC. Send MTP-Transfer Ind from NIF containing protocol data with
DPC+CIC that doesn't match this routing key. Response will be same
as in the above case.
4. Repeat the above test case if routing context is defined based on
DPC+SIO. Send MTP-Transfer Ind from NIF containing protocol data with
DPC+SIO that doesn't match this routing key. Response will be same
as in the above case.
5. Repeat the above test case if routing context is defined based on
DPC. Send MTP-Transfer Ind from NIF containing protocol data with DPC
that doesn't match this routing key. Response will be same as in the
above case.
Sachin-Sunil, HSS [Page 60]
Internet Draft Test Specs for M3UA July 2000
"Loadshare Mode of Traffic handling in ASPAC message"
+ TEST NUMBER : 1.9.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 4.1.3 and 3.3.3.4
+ TITLE : Mode of Traffic Handling by ASP in ASPAC message
+ SUBTITLE : Loadshare mode of Traffic Handling
+ PURPOSE: To check that if an ASPAC message is received with Type
field containing Loadshare mode then traffic is distributed between
this ASP and all other active ASPs.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1 and ASP2. ASP1 is active. Arrange the DATA in AS such that it
sends ASPAC message for ASP2 with Loadshare mode and routing context
P on stream 0. Also mode of traffic handling for AS at SG is
Loadshare.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP1 is Active
ASPAC(ASP2) ---------------->
Loadshare Mode Stataus Ind ------->
<--------------- NTFY(ASP-Active)
<----------- MTP-Transfer Ind
DPC X & CIC S
To ASP1 <--------------- DATA
<----------- MTP-Transfer Ind
DPC X & CIC T
To ASP2 <--------------- DATA
ASPIA(ASP1) ---------------->
Stataus Ind ------->
<--------------- NTFY(ASP-Up)
<----------- MTP-Transfer Ind
DPC X & CIC S
To ASP2 <--------------- DATA
<----------- MTP-Transfer Ind
DPC X & CIC T
To ASP2 <--------------- DATA
Sachin-Sunil, HSS [Page 61]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASPAC message with Loadshare mode in type field and Routing
context P from AS to SG for ASP2.
2. Check A: NTFY message with status ASP-Active should be received at
AS.
3. Check B: Traffic should also go ASP2 which has sent the ASPAC. Check
this by sending MTP-Transfer Ind from NIF at SG containing different
CIC values assuming traffic is load shared based on the CIC.
4. Send ASPIA message from ASP1 to the SG. Check that all the traffic
is now going to ASP2.
Sachin-Sunil, HSS [Page 62]
Internet Draft Test Specs for M3UA July 2000
"Over-ride Mode of Traffic handling"
+ TEST NUMBER : 1.9.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.4
+ TITLE : Mode of Traffic Handling by ASP in ASPAC message
+ SUBTITLE : Over-ride mode of Traffic Handling
+ PURPOSE: To check that if an ASPAC message is received with Type
field containing override mode then all traffic is sent to that ASP
which sent ASPAC message.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS. ASP1 in AS is active. Arrange the DATA in AS such that it sends
ASPAC message with override mode and routing context P for ASP2 on
stream 0. Also mode of traffic handling for AS at SG is also
override mode.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP1 is Active
ASPAC(ASP2) ---------------->
Override Mode Stataus Ind ------->
To ASP2 <--------------- NTFY(ASP-Active)
To ASP1 <--------------- NTFY(ASP-Up)
<----------- MTP-Transfer Ind
DPC X & CIC S
To ASP2 <--------------- DATA
<----------- MTP-Transfer Ind
DPC X & CIC T
To ASP2 <--------------- DATA
TEST DESCRIPTION:
1. Send ASPAC message with override mode in type field and Routing
context P from AS to SG for ASP2.
2. Check A: NTFY message with status ASP-Active should be received at
AS.
3. Check B: All traffic should go to ASP2 which has sent the ASPAC.
Check this by sending MTP-Transfer Ind from NIF at SG.
Sachin-Sunil, HSS [Page 63]
Internet Draft Test Specs for M3UA July 2000
"Loadshare Mode of Traffic handling in ASPIA message"
+ TEST NUMBER : 1.10
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.5
+ TITLE : Mode of Traffic Handling by ASP in ASPIA message
+ SUBTITLE : Loadshare mode of Traffic Handling
+ PURPOSE: To check that if an ASPIA message is received with Type
field containing Loadshare mode then all traffic is sent to other
ASP.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1 and ASP2. ASP1 and ASP2 in AS are active and are in loadshare
mode of traffic handling. Arrange the DATA in AS such that it sends
ASPIA message with Loadshare mode and routing context P for ASP1 on
stream 0. Also mode of traffic handling for AS at SG is Loadshare.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP1 & ASP2 are Active
ASPIA(ASP2) ---------------->
Stataus Ind ------->
To ASP2 <--------------- NTFY(ASP-Up)
<----------- MTP-Transfer Ind
DPC X & CIC S
To ASP1 <--------------- DATA
<----------- MTP-Transfer Ind
DPC X & CIC T
To ASP1 <--------------- DATA
TEST DESCRIPTION:
1. Send ASPIA message with Loadshare mode in type field and Routing
context P from ASP1 to SG.
2. Check A: SG should send NTFY message with status ASP-Up.
3. Check B: All traffic should go to ASP1. Check this by sending
MTP-Transfer Ind from NIF at SG with Protocol Data containing
different SLS values.
Sachin-Sunil, HSS [Page 64]
Internet Draft Test Specs for M3UA July 2000
"ERROR Message Handling"
+ TEST NUMBER : 1.11
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : ERROR
+ SUBTITLE : Handling of Received Error
+ PURPOSE: To check that if an error is received then that is reported
to the SM and no action is taken against that.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1. ASP1 is active. Arrange data in AS such that ERROR with cause
invalid version is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is Active
ERROR ---------------->
cause=Invalid version
Error ------->
TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from ASP to SG.
2. Check A: Error should be reported to the SM.
3. Check B: Further action at the SG are implementation dependent.
SM may tear down the connection or no action may be taken.
4. Repeat the test case for other cause values in ERROR message.
Sachin-Sunil, HSS [Page 65]
Internet Draft Test Specs for M3UA July 2000
"SCTP Connection Establishment"
+ TEST NUMBER : 1.12.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.2
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Establishment
+ PURPOSE: To check that on receiving Communication Up primitive from
SCTP, SG M3UA will send M-SCTP-Establish indication to the SM.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is not established between SG
and ASP1. Also arrange the data in AS such that SCTP association is
established between ASP1 and SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM
SCTP Establish request to SCTP
SCTP association will be established by SCTP
SG will receive Communication-Up primitive from SCTP
M-SCTP-Establish Ind ------->
ASPUP ------------------>
Status Ind --------->
<----------------- NTFY(ASP-Up)
<----------------- NTFY(AS-Up)
TEST DESCRIPTION:
1. Make an SCTP association between ASP1 and SG. SG will receive
Communication Up primitive from SCTP.
2. Check A:SM receives M-SCTP-Establish indication.
3. Send ASPUP message with valid ALI from AS to SG
4. Check B: NTFY message with status ASP-Up should be received.
Sachin-Sunil, HSS [Page 66]
Internet Draft Test Specs for M3UA July 2000
"SCTP Connection Termination"
+ TEST NUMBER : 1.12.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.2
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Termination
+ PURPOSE: To check that on receiving SCTP-Communication Down
indication primitive from SCTP, AS will send the M-SCTP Status
primitive to the upper layer.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1. Arrange for terminating the SCTP association between ASP1 and
SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is active
ASPDN ------------->
Status Ind --------->
<----------------- NTFY(ASP-Down)
<----------------- NTFY(AS-Down/AS-Pending)
SCTP association is terminated
SG will receive Communication-Down primitive from SCTP
M-SCTP Status -------->
<-------- MTP-Transfer
Send Failure --------->
TEST DESCRIPTION:
1. Terminate the association between SG and AS.
2. Check A: SCTP association will be down and on receiving
Communication Down primitive from SCTP, M-SCTP Status indication
will be received at SM.
3. Check B: State of ASP will be down at the SG. Send MTP-Transfer
primitive from the NIF to send some Protocol DATA. SG will report
send failure.
Sachin-Sunil, HSS [Page 67]
Internet Draft Test Specs for M3UA July 2000
"Last ASP in a SPMC goes down"
+ TEST NUMBER : 1.13.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.5
+ TITLE : SPMC Management
+ SUBTITLE : Last ASP in a SPMC goes down
+ PURPOSE: To check that if last ASP in a SPMC goes down then SG gives
NIF the MTP-Pause indication.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1 and ASP2. ASP1 and ASP2 in AS are active. Arrange the DATA in AS
such that it ASPIA messages are sent from ASP to SG for ASP1 and ASP2
on stream 0.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP1 & ASP2 are Active
ASPIA(ASP1) ---------------->
Stataus Ind ------->
To ASP1 <--------------- NTFY(ASP-Up)
ASPIA(ASP2) ---------------->
Stataus Ind ------->
To ASP2 <--------------- NTFY(ASP-Up)
To AS <--------------- NTFY(AS-Up/Pending)
MTP-Pause -------->
TEST DESCRIPTION:
1. Send ASPIA and ASPDN messages for ASP1 and ASP2 from AS to SG.
2. Check A: SG should send MTP-Pause indication to the NIF when last
ASP goes down.
3. Repeat the above test case if SG and ASP are having the same point
code.
Sachin-Sunil, HSS [Page 68]
Internet Draft Test Specs for M3UA July 2000
"Last ASP serving a specific DPC+SIO goes down goes down"
+ TEST NUMBER : 1.13.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.5
+ TITLE : SPMC Management
+ SUBTITLE : Last ASP serving a specific DPC+SIO goes down goes down
+ PURPOSE: To check that if last ASP which is serving a specific
DPC + SIO goes down then SG gives NIF the Status indication with
user part unavailable.
+ TEST CONFIGURATION: F
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP1, ASP2 and ASP3. All ASP are active. Arrange the DATA in AS1 and
AS2 such that it ASPIA and ASPDN messages are sent from ASP to SG for
ASP1 and ASP2 on stream 0.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP1 & ASP2 are Active
ASPIA(ASP1) ---------------->
Stataus Ind ------->
To ASP1 <--------------- NTFY(ASP-Up)
ASPIA(ASP2) ---------------->
Stataus Ind ------->
To ASP2 <--------------- NTFY(ASP-Up)
To AS <--------------- NTFY(AS-Up/Pending)
Status Ind -------->
(user part unavailable)
TEST DESCRIPTION:
1. Send ASPIA and ASPDN messages for ASP1 and ASP2 from AS to SG.
2. Check A: SG should send Status indication to the NIF when last ASP
goes down.
3. Repeat the above test case if ASP3 goes down
Sachin-Sunil, HSS [Page 69]
Internet Draft Test Specs for M3UA July 2000
4.2 Test Cases for Testing M3UA at AS
These test cases are used to test the M3UA at AS.
"Send and Receive of MTP-Transfer Primitive in AS Active State"
+ TEST NUMBER : 2.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.2.1 and 1.6
+ TITLE : MTP-Transfer Primitive
+ SUBTITLE : Send and Receive of MTP-Transfer Primitive
+ PURPOSE: To check that on receiving MTP-Transfer primitive from SU,
DATA message is sent to the SG.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP is in ASP-Active state. Also arrange the data in ASP such
that SU send MTP-Transfer primitive to M3UA with N/w Appearance A.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is Active
a)
<----------- MTP-Transfer
<------------- DATA N/w appearance A
b)
DATA -------------->
MTP-Transfer --------->
TEST DESCRIPTION:
1. Send MTP-Transfer Request Primitive from the SU at ASP to send
Protocol Data to the SG.
2. Check A: DATA message is received at AS containing the data passed
by the SU and the Network Appearance.
3. Send DATA message from SG containing Protocol Data and N/w
Appearance A to the ASP.
4. Check B: MTP-Transfer primitive is received at SU with the Protocol
Data and N/w Appearance.
5. Repeat the test step 3 if DATA message is sent without N/w
appearance parameter. Response should be same as in 4.
Note: In some implementation, N/w appearance parameter may not be
there in the DATA message sent from ASP to SG.
Sachin-Sunil, HSS [Page 70]
Internet Draft Test Specs for M3UA July 2000
"Stream Selection "
+ TEST NUMBER : 2.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.3
+ TITLE : Stream Selection
+ SUBTITLE : Stream Selection
+ PURPOSE: To check that all the messages for the same call are sent
on the same SCTP stream.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP with two or more streams. ASP is active. Also arrange the data in
ASP such that SU sends three or more MTP-Transfer indication
primitive to M3UA containing the same CIC value and N/w Appearance A.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
AS is active
<--------- MTP-Transfer
Check Stream id <------------- DATA Data with CIC X
<--------- MTP-Transfer
Check Stream id <------------- DATA Data with CIC X
<--------- MTP-Transfer
Check Stream id <------------- DATA Data with CIC X
TEST DESCRIPTION:
1. Send three or more MTP-Transfer Request Primitive from the SU at SG
side to send Protocol Data to the AS. In the Protocol Data CIC
values should be same in all MTP-Transfer Request primitive. It is
assumed that load sharing across the streams is CIC based.
2. Check A: DATA messages are sent to the SG containing the same
Stream Sequence number.
3. Repeat the above test with same SLS value in Protocol Data in all
MTP-Transfer Request primitives assuming load sharing across the
streams is SLS based.
4. Repeat the above test case with different CIC values and different
SLS values. DATA messages should be sent on different streams.
Note: How the messages will be distributed on different streams based
on CIC and SLS is implementation dependent.
Sachin-Sunil, HSS [Page 71]
Internet Draft Test Specs for M3UA July 2000
"SCTP Connection Establishment"
+ TEST NUMBER : 2.3.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.2
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Establishment
+ PURPOSE: To check that on receiving M-SCTP-Establish primitive from
SM, ASP initiates and establishes an SCTP association with the SG.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is not established between SG
and ASP. Also arrange the data in ASP such that SM sends
M-SCTP-Establish primitive to M3UA with the SG id to which the
connection is to be established.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU + SM
<--------- M-SCTP-Establish Request
<------------------->
SCTP association will be established by SCTP
AS will receive Communication-Up primitive from SCTP
M-SCTP-Establish Ind------->
TEST DESCRIPTION:
1. Send M-SCTP-Establish Request Primitive from the SM at ASP side to
establish an SCTP association with the SG.
2. Check A: SCTP association will be established and M-SCTP-Establish
indication will be received at the SM.
Sachin-Sunil, HSS [Page 72]
Internet Draft Test Specs for M3UA July 2000
"SCTP Connection Termination"
+ TEST NUMBER : 2.3.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.2
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Termination
+ PURPOSE: To check that on receiving SCTP-Communication Down
indication primitive from SCTP, ASP will send the M-SCTP Status
primitive to the upper layer.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP is in active state. Also arrange the data in SG such that
SCTP association is terminated between SG and AS.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM + SU
ASP is active
<------------- ASPDN
NTFY(ASP-Down) -------------->
NTFY(AS-Down) -------------->
SCTP association is terminated
ASP will receive Communication-Down primitive from SCTP
M-SCTP Status -------->
<-------- MTP-Transfer
Send Failure --------->
TEST DESCRIPTION:
1. Terminate the association between SG and ASP.
2. Check A: SCTP association will be down and on receiving
Communication Down primitive from SCTP, M-SCTP Status indication
will be received at the SM.
3. Check B: State of ASP will be down. Send MTP-Transfer primitive from
the SU to send some Protocol DATA. ASP will report send failure.
Note: It may be possible that SCTP connection is terminated without
exchanging the ASPDN message.
Sachin-Sunil, HSS [Page 73]
Internet Draft Test Specs for M3UA July 2000
"NTFY message is not received in response to ASPUP message"
+ TEST NUMBER : 2.4.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.1
+ TITLE : AS management
+ SUBTITLE : NTFY message is not received in response to ASPUP message
+ PURPOSE: To check that if NTFY message is not received in response to
the ASPUP message then SG keeps on sending ASPUP message at an
interval for some time and after some tries will report the SM.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. Also arrange the data in ASP such that SM sends ASP Up primitive
to the M3UA. Arrange data in SG such that NTFY message with status
AS-Down is not sent in response to the ASPUP message.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<----------- ASP-Up
<------------ ASPUP
|
|time t1
<------------ ASPUP
|
|time t1
<------------ ASPUP
.
.
. n tries
.
Status Ind ---------->
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message to
the SG. Don't send NTFY message from the SG.
2. Check A: ASPUP message will be retransmitted to the SG.
3. Check B: Note the time for which ASPUP will be retransmitted.
4. Repeat the above test case for ASPDN message i.e. NTFY message is
not sent in response to ASPDN message.
Note: This case is implementation specific. In some implementation
there may not be any retransmission. Also the time for which it
will be retransmitted is implementation specific.
Sachin-Sunil, HSS [Page 74]
Internet Draft Test Specs for M3UA July 2000
"NTFY message with status ASP-Down is received in response to ASPUP
message"
+ TEST NUMBER : 2.4.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.1
+ TITLE : AS management
+ SUBTITLE : NTFY message with status ASP-Down is received in response
to ASPUP message
+ PURPOSE: To check that if NTFY message with status ASP-Down is
received in response to the ASPUP message then SG sends ASPUP message
again.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. Also arrange the data in ASP such that SM sends ASP Up primitive
to the M3UA. Arrange data in SG such that NTFY message with status
ASP-Down is sent in response to the ASPUP message on stream 0.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<----------- ASP-Up
<------------ ASPUP
NTFY(ASP-Down) ------------>
<------------ ASPUP
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message to
the SG. Send NTFY message with status ASP-Down from the SG.
2. Check A: ASPUP message will be retransmitted to the SG.
Note: This case is implementation specific. In some implementation
there may not be any retransmission.
Sachin-Sunil, HSS [Page 75]
Internet Draft Test Specs for M3UA July 2000
"ASP Management messages towards SG"
+ TEST NUMBER : 2.4.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : ASP Management messages towards SG
+ PURPOSE: To check that if SM sends primitive to send ASP management
messages to the SG then the corresponding message is sent to the SG.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP is active. Also arrange the data in ASP such that SM sends
different ASP status primitive to the ASP with valid parameters.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<--------- ASP-Inactive
<----------- ASPIA
NTFY(ASP-Up) ------------>
Status Ind --------->
<--------- ASP-Down
<----------- ASPDN
NTFY(ASP-Down) ------------>
Status Ind --------->
<--------- ASP-Up
<----------- ASPUP
NTFY(ASP-Up) ------------>
Status Ind --------->
<--------- ASP-Active
<----------- ASPAC
NTFY(ASP-Active) ------------>
Status Ind --------->
Sachin-Sunil, HSS [Page 76]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive from SM in ASP to M3UA.
2. Check A: ASPIA message will be received at the SG. Send NTFY(ASP-Up)
in response to the ASPUP message on stream 0.
3. Check B: ASPM messages are sent on strem 0.
4. Repeat the test case for other primitives like ASP-Down, ASP-Active
and ASP-Up. ASPDN, ASPAC and ASPUP messages will be sent from ASP to
SG with parameters passed from SM.
5. Repeat the above test case if NTFY messages are sent on stream other
than 0.
Sachin-Sunil, HSS [Page 77]
Internet Draft Test Specs for M3UA July 2000
"Invalid Version Error"
+ TEST NUMBER : 2.5.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Version Error
+ PURPOSE: To check that if any message with Invalid version is
received at the ASP then ASP responds with ERROR message containing
cause "Invalid Version" and diagnostic information filled with the
version the SG supports.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Also arrange the data in SG such that DUNA
message is sent on stream 0 with the version other than Release 1.0
protocol to the ASP. N/w appearance parameters in the DUNA message
should be A and affected DPC can be having any DPC.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
DUNA --------------->
Version = 2
<-------------- ERROR
Cause = Invalid Version
TEST DESCRIPTION:
1. Send DUNA message from SG to ASP containing version 2 in the common
header.
2. Check A: ERROR message containing cause Invalid Version will be
received at SG.
3. Check B: Diagnostic Parameter in ERROR is filled with version 1.
4. Repeat the above test cases for other messages from SG to ASP like
DAVA, SCON, DUPU, NTFY and DATA.
Sachin-Sunil, HSS [Page 78]
Internet Draft Test Specs for M3UA July 2000
"Unrecognised Message Type"
+ TEST NUMBER : 2.5.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Unrecognised Message Type
+ PURPOSE: To check that if a message with message type not defined is
received at AS, AS responds with ERROR message containing cause
"Invalid Message Type".
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that a message
with Message type not defined is sent to ASP. Let the other
parameters in the message be like any other message.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
Message --------------->
Message Type = 0408
<-------------- ERROR
Cause = Invalid Message Type
DATA --------------->
N/w Appearance A
MTP-Transfer Ind --------->
TEST DESCRIPTION:
1. Send a message with message type 0408 or any other value which is
not defined from SG to ASP.
2. Check A: ERROR message containing cause Invalid Message Type will be
received at the SG.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test cases by sending ASPUP, ASPDN, ASPAC, ASPIA
messages from AS which the ASP is not expected to receive. In this
case Error will be reported to the SM and Message will be discarded.
Sachin-Sunil, HSS [Page 79]
Internet Draft Test Specs for M3UA July 2000
"Invalid Network Appearance"
+ TEST NUMBER : 2.5.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Network Appearance
+ PURPOSE: To check that if a message with invalid network appearance
i.e. ASP does not handle traffic for that network appearance then AS
responds with ERROR message containing cause "Invalid Network
Appearance".
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that DATA message
with invalid value of Network Appearance is sent to ASP.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
DATA --------------->
N/w appearance B
<-------------- ERROR
Cause = Invalid Network Appearance
DATA --------------->
N/w Appearance A
MTP-Transfer Ind --------->
TEST DESCRIPTION:
1. Send DATA message to the ASP with network appearance which ASP
doesn't handle.
2. Check A: AS will respond with ERROR message containing cause Invalid
Network Appearance.
3. Check B: State of ASP at AS is not disturbed.
4. Repeat the above test case for other messages like DUNA, DAVA, DUPU
and SCON.
Sachin-Sunil, HSS [Page 80]
Internet Draft Test Specs for M3UA July 2000
"Invalid Congestion Level in SCON message"
+ TEST NUMBER : 2.5.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE: Invalid congestion level in SCON message.
+ PURPOSE: To check that if SCON message with Invalid congestion level
parameter is received then it is reported to the upper layer.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Arrange the data in SG such that SCON message
with congestion level with value 04 or more is sent to the ASP. In
N/w Appearance parameter in SCON message, fill value A and for
affected DPC fill any value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
SCON --------------->
Congestion Level 0x4
Status Ind -------->
DATA --------------->
N/w Appearance A
MTP-Transfer Ind --------->
TEST DESCRIPTION:
1. Send SCON message with congestion Level 0x4.
2. Check A: AS will pass the information in the SCON message to the SU
via Status Indication Primitive.
3. Check B: State of ASP is not disturbed.
Sachin-Sunil, HSS [Page 81]
Internet Draft Test Specs for M3UA July 2000
"Invalid Cause parameter in DUPU message"
+ TEST NUMBER : 2.5.5
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Cause parameter in DUPU message
+ PURPOSE: To check that if DUPU message with Invalid cause parameter
is received then error will be reported to SM.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that DUPU message
with invalid value of cause parameter is sent to ASP. In N/w
Appearance parameter fill value A and affected destination parameter
fill any value. In the user parameter fill any valid value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
DUPU --------------->
Cause 03
Error -------->
DATA --------------->
N/w Appearance A
MTP-Transfer Ind --------->
TEST DESCRIPTION:
1. Send DUPU message from the SG with cause value 03 or more to the ASP.
2. Check A: AS will take no action and will report error to the SM.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for invalid value of User parameter in
DUPU message(11 or more).
Sachin-Sunil, HSS [Page 82]
Internet Draft Test Specs for M3UA July 2000
"Invalid Routing Context in NTFY message"
+ TEST NUMBER : 2.5.6
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Routing Context in NTFY message
+ PURPOSE: To check that if NTFY message with Invalid Routing Context
parameter, i.e. ASP is not configured for that Routing Context, is
received then message is discarded.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is down. Arrange data in SG such that NTFY message with
invalid routing context i.e. routing context R is sent to ASP on
stream 0.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<--------- ASP-Up
<----------- ASPUP
NTFY(ASP-Up) ------------>
Routing Context R
<----------- ASPUP
TEST DESCRIPTION:
1. Send ASP-Up message from the SM at ASP. ASP will send ASPUP message
to the SG. Now send NTFY message with Status ASP-Up but with routing
context R.
2. Check A: NTFY message should be discarded and ASPUP message is
received again at the SG
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for Invalid Status Type and Invalid
Status Indication parameter in NTFY message to the ASP.
Sachin-Sunil, HSS [Page 83]
Internet Draft Test Specs for M3UA July 2000
"Message length less than the length of mandatory Parameters"
+ TEST NUMBER : 2.5.7
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Message length less than length of mandatory parameters
+ PURPOSE: To check that if a message with value of length parameter
less than length of mandatory parameters is received then message is
discarded.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and AS is Down. Arrange the data in SG such that NTFY message with
length parameter filled with value less than the length of Status
Type and Status Identificatin field.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<--------- ASP-Up
<----------- ASPUP
NTFY ------------>
Error ------->
<----------- ASPUP
TEST DESCRIPTION:
1. Send ASP-Up primitive from Sm to the M3UA at the ASP. ASPUP message
will be sent to the SG.
2. Send NTFY message with length field less than the length of Status
Type and Status Identification field.
3. Check A: ASP will take no action and will discard the NTFY message.
4. Check B: ASPUP message will be sent again.
Sachin-Sunil, HSS [Page 84]
Internet Draft Test Specs for M3UA July 2000
"Reception of SSNM messages"
+ TEST NUMBER : 2.6.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.2
+ TITLE : SSNM Message handling
+ SUBTITLE: Reception of SSNM messages
+ PURPOSE: To check that if SSNM message is received at the ASP then it
is reported to the ULP.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Also arrange the data in SG such that DUNA,
DAVA, DUPU and SCON messages are sent from the SG to the ASP with
valid parameters and they are sent on stream number 0.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
a)
DUNA --------------->
MTP-Pause Ind -------->
b)
DAVA --------------->
MTP-Resume Ind -------->
c)
SCON --------------->
MTP-Status Ind -------->
d)
DUPU --------------->
MTP-Status Ind -------->
TEST DESCRIPTION:
1. Send DUNA message from SG to ASP containing the Network Appearance A
and Affected DPC any value.
2. Check A: MTP-Pause indication primitive will be received at the SU.
3. Repeat the above test case for other messages like DAVA, SCON and
DUPU messages.
4. Repeat the above test case for one affected DPC and for more than
one affected DPC parameters.
5. Repeat the above test cases if all these messages are sent on stream
number other than zero. They should be accepted.
Note: Depending upon the number of affected destinations there may be
more than one MTP-Pause, MTP-resume and Status Indication.
Sachin-Sunil, HSS [Page 85]
Internet Draft Test Specs for M3UA July 2000
"DAUD message is not sent if SCON message is received with congestion
level 0 or undefined"
+ TEST NUMBER : 2.6.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.3
+ TITLE : SSNM Message Handling
+ SUBTITLE : DAUD message is not sent if SCON message is received with
congestion level 0 or undefined
+ PURPOSE: To check that if SCON message is received with congestion
level 0 or undefined then DAUD message is not sent on expiry of the
timer.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Also arrange the data in SG such that SCON
message with congestion level 0 is sent to the ASP. Network
Appearance parameter should be having value A and affected DPC can be
having any value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is active
SCON(Level 1) --------------->
| MTP-Status Ind -------->
|
|Timer expires
<--------------- DAUD
|
|
|Timer expires
<--------------- DAUD
SCON(Level 0) --------------->
|
|
|Timer expires
DAUD is not sent
TEST DESCRIPTION:
1. Send SCON message from the SG to the ASP. Don't send any other SSNM
message from the SG. Timer will be started at the ASP on receiving
SCON message.
2. Check A: DAUD message will not be received at the SG after expiry of
the timer.
3. Repeat the above test case if SCON message is sent without N/w
Appearance parameter. Response should be same.
Note: value of the timer is implementaion specific.
Sachin-Sunil, HSS [Page 86]
Internet Draft Test Specs for M3UA July 2000
"Timer which started on receiving DUNA message is reset on issuing DAUD
message"
+ TEST NUMBER : 2.6.3
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.3
+ TITLE : SSNM Message Handling
+ SUBTITLE : Timer which started on receiving DUNA message is reset on
issuing DAUD message
+ PURPOSE: To check that timer which started on receiving DUNA message
from the SG is reset on issuing DAUD message from the ASP.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Also arrange the data in SG such that DUNA
message is sent to the AS with Network appearance A and affected DPC
any value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is active
DUNA --------------->
| MTP-Pause -------->
|
|Timer expires
<--------------- DAUD
|
|
|Timer expires
<--------------- DAUD
TEST DESCRIPTION:
1. Send DUNA message from the SG to the ASP. Don't send any other SSNM
message from the SG. Timer will be started at the AS on receiving
DUNA message.
2. Check A: DAUD message containing the network Appearance A and
Affected DPC will be received at SG after expiry of the timer.
3. Check C: DAUD message is received on the Stream number 0.
4. Check D: Timer is started again after issuing DAUD message.
5. Repeat the above test case if DUNA message is sent without N/w
Appearance parameter. Response should be same.
6. Repeat the above test case if in place of DUNA message SCON message
with congestion level 1 or 2 or 3 is sent
Note: value of the timer is implementaion specific.
Sachin-Sunil, HSS [Page 87]
Internet Draft Test Specs for M3UA July 2000
"Timer which started on receiving DUNA message is reset on receiving
another DUNA message"
+ TEST NUMBER : 2.6.4
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.3
+ TITLE : SSNM Message Handling
+ SUBTITLE : Timer which started on receiving DUNA message is reset on
receiving another DUNA message
+ PURPOSE: To check that timer which started on receiving DUNA message
from the SG is reset on receiving another DUNA message from the SG.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Also arrange the data in SG such that DUNA
message is sent to the ASP with Network appearance A and affected DPC
two times on stream 0. First time it is sent with DPC X and second
time it is sent with DPC Y. ASP is handling traffic for both DPC X
and Y.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is active
DUNA(DPC = X) --------------->
|Timer starts MTP-Pause -------->
|
|
DUNA(DPC = Y) ------|---------> Timer is reset
| | MTP-Pause -------->
| |Timer expires
| No DAUD is sent
|
|Timer expires
<--------------- DAUD
TEST DESCRIPTION:
1. Send DUNA message with affected DPC X from the SG to the ASP. Timer
will be started at the AS on receiving DUNA message. Send another
DUNA message for DPC Y to the ASP before expiry of the timer.
2. Check A: Timer will be reset on receiving DUNA message and DAUD
message is received at the SG after expiry of the timer.
3. Check C: DAUD message is received on the Stream number 0.
4. Check D: Timer is started again after issuing DAUD message.
5. Repeat the above test case if DUNA message is sent both times with
same DPC and also DUNA message contains both the DPC.
6. Repeat the above test case if instead of sending DUNA second time,
SCON is sent with congestion level 1 or 2 or 3 and affected DPC X or
Y.
Note: It is assumed that timer is not DPC specific i.e. for every DPC a
new timer is not started. it is SG specific.
Sachin-Sunil, HSS [Page 88]
Internet Draft Test Specs for M3UA July 2000
"Timer which started on receiving DUNA message is stopped on receiving
DAVA message"
+ TEST NUMBER : 2.6.5
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.4.3
+ TITLE : SSNM Message Handling
+ SUBTITLE : Timer which started on receiving DUNA message is stopped
on receiving another DUNA message
+ PURPOSE: To check that timer which started on receiving DUNA message
from the SG is stopped on receiving DAVA message from the SG.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Also arrange the data in SG such that DUNA
message is sent to the ASP with Network appearance A and affected
DPC on stream 0. After DUNA message DAVA message is sent to the ASP on
stream 0.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is active
DUNA --------------->
|Timer starts MTP-Pause -------->
|
|
DAVA ------|---------> Timer is stopped
| | MTP-Resume -------->
| |Timer expires
| No DAUD is sent
|
|Timer expires
No DAUD is sent
TEST DESCRIPTION:
1. Send DUNA message with affected DPC X from the SG to the ASP. Timer
will be started at the ASP on receiving DUNA message. Send another
DAVA message for DPC X to the ASP before expiry of the timer.
2. Check A: Timer will be stopped on receiving DAVA message and DAUD
message is not sent to the SG after expiry of the timer.
Note: It is assumed that timer is not DPC specific i.e. for every DPC a
new timer is not started. it is SG specific.
Sachin-Sunil, HSS [Page 89]
Internet Draft Test Specs for M3UA July 2000
"NTFY(ASP-Up) is received in response to ASPDN message"
+ TEST NUMBER : 2.7.1
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : NTFY(ASP-Up) is received in response to ASPDN message
+ PURPOSE: To check that if NTFY (ASP-Up) message is received in
response to the ASPDN then the NTFY message is discarded and ASPDN is
sent again.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Up. Arrange data in SG such that NTFY (ASP-Up) is sent
to ASP in response to ASPDN message with routing context P on stream
0.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is Up
<--------- ASP-Down
<----------- ASPDN
NTFY(ASP-Up) ------------>
<----------- ASPDN
TEST DESCRIPTION:
1. Send ASP-Down Primitive to the ASP. ASPDN message will be sent to
the SG. Send NTFY message with status ASP-Up in response to the
ASPDN message.
2. Check A: ASPDN message is received at the SG.
3. Repeat the above test case if NTFY message is sent with status
ASP-Active.
Sachin-Sunil, HSS [Page 90]
Internet Draft Test Specs for M3UA July 2000
"NTFY(ASP-Active) is received in response to ASPIA message"
+ TEST NUMBER : 2.7.2
+ Reference: draft-ietf-sigtran-m3ua-02.txt
+ TITLE : Duplicate Message Handling
+ SUBTITLE : NTFY(ASP-Active) is received in response to ASPIA message
+ PURPOSE: To check that if NTFY (ASP-Active) message is received in
response to the ASPIA then the NTFY message is discarded and ASPIA is
sent again.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Arrange the data in SG such that NTFY
(ASP-Active) with routing context P is sent to ASP in response to
ASPIA message on stream 0.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<--------- ASP-Inactive
<----------- ASPIA
NTFY(ASP-Active) ------------>
<----------- ASPIA
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive to the AS. ASPIA message will be sent to
the SG. Send NTFY message with status ASP-Active in response to the
ASPIA message.
2. Check A: ASPIA message is received again at the SG.
3. Repeat the above test case if NTFY with ASP-Up is received in
response to the ASPIA message.
Sachin-Sunil, HSS [Page 91]
Internet Draft Test Specs for M3UA July 2000
"ERROR Handling"
+ TEST NUMBER : 2.8
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 2.5.1
+ TITLE : ERROR
+ SUBTITLE : Handling of Received Error
+ PURPOSE: To check that if an error is received then that is reported
to the SM and no action is taken against that.
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP is in active state at the SG. Arrange data in SG such that
ERROR with cause invalid version is sent to the AS.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is active
<------- ASP-Up
<--------------- ASPUP
ERROR --------------->
Cause = invalid version Error -------->
TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from SG to AS.
2. Check A: AS should report the error to its SM.
3. Check B: Further action at the SG are implementation dependent.
4. Repeat the test case for other cause values in ERROR message.
Sachin-Sunil, HSS [Page 92]
Internet Draft Test Specs for M3UA July 2000
"ASP in more than one AS"
+ TEST NUMBER : 2.9
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 3.3.3.4 and 3.3.3.5
+ TITLE : ASP configuration
+ SUBTITLE : ASP configured to handle traffic for more than one AS
+ PURPOSE: To check that if an ASP has been configured to handle
traffic for more than one AS then in ASPAC and ASPIA message more
than one routing context are sent.
+ TEST CONFIGURATION: I
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP has been configured to handle traffic for routing context P
and Q. ASP is Down. Arrange data in ASP such that ASP-Active is sent
from SM with the list of AS or routing context ASP is configured for.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is Down
<------- ASP-Up
<--------------- ASPUP
NTFY(ASP-Up) --------------->
<------- ASP-Active
<--------------- ASPAC(Routing context X and Y)
NTFY(ASP-Active) --------------->
<------- ASP-Inactive
<--------------- ASPIA(Routing context X and Y)
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to ASP. ASPUP message will be sent
from ASP to SG. Send NTFY (ASP-Up) from the SG. Now send ASP-Active
primitive from SM.
2. Check A: ASPAC message is received at the SG containing both the
routing context P and Q.
3. Repeat the above test case for ASP-Inactive primitive from SM. ASPIA
message should be sent to SG containing both the routing contexts.
Sachin-Sunil, HSS [Page 93]
Internet Draft Test Specs for M3UA July 2000
"SG in Primary/Backup case"
+ TEST NUMBER : 2.10
+ Reference: draft-ietf-sigtran-m3ua-02.txt Clause 1.5.2
+ TITLE : SG Redundancy
+ SUBTITLE : SG in Primary/Backup case
+ PURPOSE: To check that if an ASP is connected to the two SG, SG1 and
SG2 both configured to handle traffic for the same DPC but in
primary/backup mode and having same PC and SCTP association between
ASP and SG1 is down then ASP diverts all traffic towards SG2.
+ TEST CONFIGURATION: H
+ PRE-TEST CONDITIONS: ASP is having SCTP association with SG1 and SG2.
Both SG1 and SG2 are handling traffic for the same PC. SG1 is the
primary SG and SG2 is the backup SG. Arrange to disconnect the SCTP
association between ASP and SG1. Let SG1 is the primary SG.
EXPECTED MESSAGE SEQUENCE :
SG1 SG2 ASP SM + SU
ASP is Down
<------- ASP-Up(for SG1)
<-------------------------- ASPUP
<------- ASP-Up(for SG2)
<---------------- ASPUP
<------- ASP-Active(for SG1)
<-------------------------- ASPAC
<------- ASP-Active(for SG2)
<---------------- ASPAC
<------- MTP-Transfer
<--------------------------- DATA
<------- MTP-Transfer
<--------------------------- DATA
SCTP association between SG1 and ASP is down
Status --------->
<------- MTP-Transfer
<--------------- DATA
<------- MTP-Transfer
<--------------- DATA
Sachin-Sunil, HSS [Page 94]
Internet Draft Test Specs for M3UA July 2000
TEST DESCRIPTION:
1. Send MTP-Transfer primitive containing protocol Data from SU at ASP.
DATA message will be sent to the SG. Send MTP-Transfer primitive with
Protocol Data with different SLS values.
2. Check A: All DATA messages are received at SG1.
3. Terminate the SCTP association between ASP and SG1.
4. Check B: All traffic is being received at SG2.
5. Check that if SCTP association between SG1 and ASP is restored then
all traffic is received at SG1.
Sachin-Sunil, HSS [Page 95]
Internet Draft Test Specs for M3UA July 2000
5. Acknowledgement
Authors are highly greatful to Gautam, Nageshwara from HSS for their
valuable comments and encouragement.
6. Authors Address
Sachin Jindal, Sunil Mahajan
email: smahajan@hss.hns.com
Hughes Software Systems
Plot#31, Sector 18
Electronic City
Gurgaon, Haryana
INDIA - 122015
Tel# +91-124-6346666
Fax# +91-124-6342810
7. References
[1] G. Sidebottom, L. Ong, Guy Mousseau, Ian Rytina, Hanns-Juergen
Schwarzbauer, Ken Morneault, Mallesh Kalla
SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-02.txt>
Sachin-Sunil, HSS [Page 96]
| ||||||||||||||||
| Last modified: Thu, 12 Dec 2024 12:20:52 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||