| draft-mahajan-test-spec-m2ua-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-mahajan-test-spec-m2ua-00.txt.
INTERNET-DRAFT Sachin Jindal
Sunil Mahajan
Hughes Software Systems
July 20,2000
expires: Jan 20, 2001
Test Specification for MTP2 User Adaptation
<draft-mahajan-test-spec-m2ua-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 M2UA July 2000
Abstract
This document presents the test specification for M2UA (MTP2 User
Adaptation) prototcol (ver 03), which can be used to test M2UA
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 M2UA 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 M2UA-04 and any subsequent RFC published by IETF.
Sachin-Sunil, HSS [Page 2]
Internet Draft Test Specs for M2UA July 2000
Table of Contents
1 Introduction------------------------------------------------3
1.1 Terms Used--------------------------------------------------4
2 General Principles of m3ua Tests----------------------------4
2.1 Presentation of Test Descriptions---------------------------5
2.1.1 Pre-Test Condition------------------------------------------5
3 Test Configurations-----------------------------------------5
3.1 Configuration for Testing the m3ua at SG--------------------5
3.2 Configuration for Testing The m3ua at AS--------------------7
4 Test Cases--------------------------------------------------9
4.1 Test cases for testing m3ua at SG---------------------------9
4.1.1 Send and Receive transfer primitive in AS Active state------9
4.1.2 Stream selection--------------------------------------------10
4.1.3 AS Management-----------------------------------------------11
4.1.4 Link Management---------------------------------------------32
4.1.5 Invalid Message Handling------------------------------------42
4.1.6 Duplicate Message Handling----------------------------------58
4.1.7 DATA message from AS in ASP-Down State----------------------65
4.1.8 ASPM messages when SG has locked out the ASP----------------66
4.1.9 Message Routing---------------------------------------------67
4.1.10 Mode of Traffic Handling by ASP in ASPAC message------------69
4.1.11 Mode of Traffic Handling by ASP in ASPIA message------------72
4.1.12 ERROR Message Handling--------------------------------------73
4.1.13 SCTP Connection Management----------------------------------74
4.2 Test Cases for Testing m3ua at AS---------------------------76
4.2.1 Send and receive of transfer primitive in AS Active state---76
4.2.2 Stream Selection--------------------------------------------77
4.2.3 SCTP Connection Management----------------------------------78
4.2.4 AS Management-----------------------------------------------80
4.2.5 Invalid Message Handling------------------------------------85
4.2.6 Link Management---------------------------------------------94
4.2.7 Duplicate Message Handling----------------------------------100
4.2.8 DATA message from SG in ASP-Down State----------------------102
4.2.9 ERROR Handling----------------------------------------------103
4.2.10 ASP in more than one AS-------------------------------------104
4.2.11 ASP Handling more than one SG-------------------------------105
5 Acknowledgement---------------------------------------------107
6 Authors address---------------------------------------------107
7 References--------------------------------------------------107
1 Introduction
The M2UA is a protocol for the transport of any SS7 MTP2-User message
(i.e. MTP 3 message) 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).
Sachin-Sunil, HSS [Page 3]
Internet Draft Test Specs for M2UA July 2000
1.1 Terms Used
MTP2-User - A protocol that normally uses the services of MTP Level 2
(i.e. MTP3).
Interface - For the purposes of this document, an interface is a SS7
signaling link.
Association - An association refers to a SCTP association. The
association will provide the transport for the delivery of protocol
data units for one or more interfaces.
Backhaul - Refers to the transport of signaling from the point of
interface for the associated data stream (i.e., SG function in the MGU)
back to the point of call processing (i.e., the MGCU), if this is not
local.
Application Server (AS) - A logical entity serving a specific
application instance. An example of an Application Server is a MGC
handling the MTP Level 3 and call processing for SS7 links terminated
by the Signaling Gateways. Practically speaking, an AS is modeled at
the SG as an ordered list of one or more related Application Server
Processes (e.g., primary, secondary, tertiary, ...).
Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup
MGC instances.
Application Server Process Path (ASP Path or just Path) - A Path to a
remote Application Server Process instance. A Path maps 1:1 to an SCTP
association.
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.
Layer Management: Layer Management is a nodal function in an SG or ASP
that handles the inputs and outputs between the M2UA layer and a local
management entity.
Stream - A stream refers to an SCTP stream.
2 General Principles of M2UA 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
Sachin-Sunil, HSS [Page 4]
Internet Draft Test Specs for M2UA July 2000
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. Therefore, for testing individual Administrations
may unilaterally choose the tests to be performed
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. Seven test
configurations are defined (named A, B, C, D, E, F and G); they
are presented in clause 3.
Each test is precisely described. Nevertheless, some events not
directly concerning the point under test, or without direct link with
the test nature, are not explicitly described. In order to preserve the
test description implementation independence, certain flexibility has
been left in the test descriptions. This is particularly the case when
it is necessary to terminate the SCTP association (where it is only
mentioned "Terminate" with no more precision). The operator will choose
according to the implementation particularities and the events expected
in the test description, the appropriate Termination means (MML- Man
machine Language, provoked failure, etc.).
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.
Note: Where NIF has been written it means NIF + SM. In some
implementation these may be two entities and in some they may be
implemented in a 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 M2UA protocol.
These configurations and hence test cases have been divided on the
basis of M2UA at SG and M2UA at AS.
3.2 Configuration for testing the M2UA 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 interface identifier X and Y. AS is having
only one ASP ASP1.
Sachin-Sunil, HSS [Page 5]
Internet Draft Test Specs for M2UA July 2000
------------- --------------
| SG | | AS |
| under Test | | ------- |
| |-------------------------------|--| 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 different interface
identifiers. Configuration B is shown in figure 2. AS1 is handling the
traffic for interface identifier X and Y. AS2 is handling the traffic
for interface identifier P and Q. ASP1 is in both AS. ASP1 maintains
single association with SG for both AS1 and AS2.
--------------
| AS1 |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SG | | ------- |
| Under Test | --------------
| | --------------
| |-------------------------------| AS2 |
------------- | ------- |
| | 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 interface identifier X and Y. ASP1 and ASP2
may be in FAIL-OVER mode or LOADSHARE mode of traffic handling.
--------------
| AS |
------------- | ------- |
| |-------------------------------|-| ASP1 | |
| SG | | ------- |
| Under Test | | ------- |
| | | | ASP2 | |
| |-------------------------------|- ------- |
------------- --------------
Fig 3: Configuration C
Sachin-Sunil, HSS [Page 6]
Internet Draft Test Specs for M2UA July 2000
3.2.4 Configuration D:
This configuration is used for all the procedures of tests concerning
two AS which are handling traffic for different interface identifiers.
Configuration D is shown in figure 4. AS1 is handling the traffic for
interface identifier X and Y. AS2 is handling the traffic for interface
identifier P and Q. ASP1 is in AS1 and ASP2 is in AS2.
--------------
| AS1 |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SG | | ------- |
| Under Test | --------------
| | --------------
| |-------------------------------| AS2 |
------------- | ------- |
| | ASP2 | |
| ------- |
--------------
Fig 4: Configuration D
3.3 Configuration for testing the M2UA at ASP
3.3.1 Configuration E:
This simple configuration is used for all the procedures of tests
concerning only one SG. Configuration E is shown in figure 6. ASP1 is
handling the traffic for interface identifier X and Y.
------------- --------------
| ASP1 | | SG |
| under Test | | |
| |-------------------------------| |
| | | |
------------- --------------
Fig 5: Configuration E
3.3.2 Configuration F:
This simple configuration is used for all the procedures of tests
concerning one ASP in two AS. Configuration F is shown in figure 6.
ASP1 is in two AS, AS1 and AS2. AS1 is handling traffic for interface
identifier X and Y and AS2 is handling traffic for interface identifier
P and Q.
------------- --------------
| ASP1 | | SG |
| under Test | | Configured |
| |-------------------------------| for AS1 and |
| | | AS2 |
------------- --------------
Fig 6: Configuration F
Sachin-Sunil, HSS [Page 7]
Internet Draft Test Specs for M2UA July 2000
3.3.3 Configuration G:
This simple configuration is used for all the procedures of tests
concerning one ASP connected to two SG. Configuration G is shown in
figure 7. ASP1 is connected to SG1 and SG2. Interface identifiers in
SG1 are X and Y. Interface identifiers in SG2 are also X and Y. ASP is
handling interface identifier X and Y of both SG1 and SG2.
--------------
| SG1 |
------------- | |
| |-------------------------------| |
| ASP1 | | |
| Under Test | --------------
| | --------------
| |-------------------------------| SG2 |
------------- | |
| |
| |
--------------
Fig 7: Configuration G
Sachin-Sunil, HSS [Page 8]
Internet Draft Test Specs for M2UA July 2000
4 Test Cases
4.1 Test Cases for Testing M2UA at SG
These test cases are used to test the M2UA at SG.
"Send and Receive of DATA Primitive in AS active state"
+ TEST NUMBER : 1.1
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.1.1
+ TITLE: DATA Primitive
+ SUBTITLE : Send and Receive of DATA Primitive
+ PURPOSE: To check that on receiving DATA primitive from ULP, DATA
message is sent to the AS. Also if DFATA message is received the Data
primitive is sent to the NIF
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Also arrange the data in SG such that NIF send
Data primitive to M2UA with interface identifier X.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
a) AS is Active
<----------- Send Data
<------------- DATA Interface Id X
b)
DATA -------------->
Interface Id X Receive Data --------->
TEST DESCRIPTION:
1. Send DATA Primitive from the NIF at SG side to send Protocol Data to
the ASP.
2. Check A: DATA message is received at the ASP containing the data and
the interface identifier X passed by the NIF.
3. Send DATA message containing Protocol Data and Interface Identifier
X.
4. Check B: DATA primitive is received at the NIF with the Protocol
Data and interface identifier.
Sachin-Sunil, HSS [Page 9]
Internet Draft Test Specs for M2UA July 2000
"Stream Selection"
+ TEST NUMBER : 1.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 1.5.3
+ TITLE : Stream Selection
+ SUBTITLE : Stream Selection
+ PURPOSE: To check that all the messages for the same link identifier
are sent on the same SCTP stream.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP with two streams and ASP is active. Also arrange the data in SG
such that NIF send three or more DATA primitive to M2UA containing
the same interface identifier value X.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF
ASP is active
<--------- Data
Check Stream id <------------- DATA Interface Id X
<--------- Data
Check Stream id <------------- DATA Interface Id X
<--------- Data
Check Stream id <------------- DATA Interface Id X
<--------- Data
Check Stream id <------------- DATA Interface Id Y
TEST DESCRIPTION:
1. Send three or more DATA Primitives with same interface identifier
value X from the NIF at SG side to send Protocol Data to the ASP.
2. Check A: DATA messages are received at the ASP containing the same
Stream Sequence number.
3. Send Data primitive with interface identifier Y.
4. Check B: The DATA message should be received on other stream.
5. Repeat the above case if number of streams between AS and SG is more
than two but AS is handling only two interface identifiers. One or
more stream may not be used for sending DATA message.
6. Repeat the above case if number of streams between AS and SG is two
but AS is handling four interface identifiers. Send DATA messages
for all interface identifiers. DATA messages should be sent on both
the streams and DATA messages for the same interface identifier are
sent on the same stream.
Sachin-Sunil, HSS [Page 10]
Internet Draft Test Specs for M2UA July 2000
"Data Send Primitive from NIF in AS Up State"
+ TEST NUMBER : 1.3.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.2
+ TITLE : AS management
+ SUBTITLE : DATA send Primitive from NIF in AS Up State
+ PURPOSE: To check that if AS is not active at SG and NIF sends Data
send Primitive to send DATA to that ASP then it receives a send
failure.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is in active state. Arrange the data in ASP such that
ASPIA message with interface identifier X and Type field equal to the
traffic handling mode defined at the SG for this AS is sent from ASP
to SG on stream 0. Arrange data in NIF at SG such that DATA primitive
with interface identifier X and protocol Data is sent to SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
ASPIA --------------->
(ASP1) M-ASP-Status -------->
<-------------- NTFY( ASP-Up)
<-------------- NTFY(AS-Up/AS-Pending)
<-------- Data
interface Id X
Send failure -------->
TEST DESCRIPTION:
1. Send ASPIA Message from ASP to the SG. ASP and AS will become Up at
the SG. Send Data send Primitive containing Protocol Data to send to
the AS.
2. Check A: Send failure should be received at the NIF and DATA message
should not be sent to AS.
3. Check B: NTFY message is received on stream 0.
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 11]
Internet Draft Test Specs for M2UA July 2000
"Data Send Primitive from NIF in AS Down State"
+ TEST NUMBER : 1.3.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : AS management
+ SUBTITLE : DATA send Primitive from NIF in AS Down State
+ PURPOSE: To check that if AS is down at SG and NIF sends Data send
Primitive to send DATA to that ASP then it receives a send failure.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that ASPDN
message with reason parameter 0x1 is sent from ASP to SG on stream 0.
Arrange data in NIF at SG such that DATA primitive with interface
identifier X and protocol Data is sent to SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
ASPIA --------------->
(ASP1) M-ASP-Status --------->
<--------------- NTFY( ASP-Up)
<--------------- NTFY(AS-Up/AS-Pending)
ASPDN --------------->
(ASP1) M-ASP-Status --------->
<--------------- NTFY( ASP-Down)
<-------------- NTFY(AS-Down/AS-Pending)
<-------- Data
Interface id X
Send failure -------->
Sachin-Sunil, HSS [Page 12]
Internet Draft Test Specs for M2UA July 2000
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 and AS will become down
at the SG. Send Data send Primitive containing Protocol Data to send
to the AS.
2. Check A: Send failure should be received at the NIF and DATA message
should not be sent to AS.
3. Check B: NTFY message is received on stream 0.
4. Repeat the above test if instead of sending ASPDN 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 13]
Internet Draft Test Specs for M2UA July 2000
"Timer T(r) Cancellation"
+ TEST NUMBER : 1.3.3
+ Reference: draft-ietf-sigtran-m2ua-03.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 ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Arrange data in ASP such that ASPIA and ASPAC
messages are sent on stream 0 from ASP to SG with interface
identifier X & Y and type parameter any valid value which is equal to
the traffic handling mode configured for AS at the SG. Let the value
of Timer T(r) is z sec.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is active
ASPIA ----------------->
(ASP1) M-ASP-Status -------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY(AS-Pending)
| Timer T(r) is started
|
| Time < z sec. <------- Data
| Message will be buffered
| <------- Data
| Message will be buffered
ASPAC --------------->
(ASP1) Status Ind -------->
<--------------- NTFY ( ASP-Active)
<--------------- NTFY(AS-Active)
<--------------- DATA
<--------------- DATA
Sachin-Sunil, HSS [Page 14]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPIA Message from ASP to the SG. AS will become Up at the SG.
Send Transfer Primitive containing Protocol Data with interface
identifier X to send to ASP.
2. Check A: DATA message will not be received at ASP.
3. Send ASPAC message before Timer T(r) expires.
4. Check B: DATA messages buffered at the SG will be received at ASP.
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 15]
Internet Draft Test Specs for M2UA July 2000
"Timer T(r) Expiry"
TEST NUMBER : 1.3.4
Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.5
TITLE : AS management
SUBTITLE : Timer T(r) Cancellation
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 and ASP is active. Arrange data in ASP such that ASPIA and ASPAC
messages are sent on stream 0 from ASP to SG with type field any valid
value which is equal to the traffic handling mode configured for AS at
the SG. Let value of Timer T(r) is z sec. The interface identifier
values in ASPIA and ASPAC messages are X and Y.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is active
ASPIA ----------------->
(ASP1) M-ASP-Status -------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY(AS-Pending)
| Timer T(r) is started
|
| Time < z sec. <------- Data
| Message will be buffered
| <------- Data
| Message will be buffered
ASPAC --------------->
(ASP1) M-ASP-Status -------->
<--------------- NTFY ( ASP-Active)
<--------------- NTFY(AS-Active)
<--------------- DATA
<--------------- DATA
ASPIA ---------------->
M-ASP-Status -------->
<--------------- NTFY (ASP-Up)
Sachin-Sunil, HSS [Page 16]
Internet Draft Test Specs for M2UA July 2000
<--------------- NTFY(AS-Pending)
|
|Time = z sec
|
|
- M-ASP-Status --------->
<--------------- NTFY(AS-Up)
<-------- Data
Send Failure ------->
TEST DESCRIPTION:
1. Send ASPIA Message from ASP to SG. ASP and AS will become Up at the
SG. Send Transfer Primitive containing Protocol Data with interface
id X. Send Transfer primitive from NIF to send some DATA to the ASP.
Message will be buffered at SG. Send ASPAC message from ASP before
timer T(r) expires. DATA message will be sent to ASP. Again send
ASPIA message from ASP.
2. Check A: Timer T(r) is started again i.e. only after z sec AS will
move to the AS-Down state.
3. Send Transfer Primitive from NIF to the SG. SG will send
Send-Failure.
4. Check B: DATA messages buffered at the SG will be received ASP.
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 M2UA July 2000
"Notify Message with ASP and AS Status"
+ TEST NUMBER : 1.3.5
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.2
+ TITLE : AS management
+ SUBTITLE : Notify Message with ASP 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 AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange data in ASP such that first ASPDN
message and then ASPUP, ASPAC and ASPIA messages are sent from ASP to
SG on stream zero. Reason parameter in ASPDN message is 0x1. Type
parameter in ASPAC and ASPIA message is equal to the traffic handling
mode configured for AS at the SG. Interface id in ASPIA and ASPAC is
X and Y. ALI parameter in ASPUP is M2UA.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM
ASP is active
ASPDN --------------->
(ASP1) M-ASP-Status ---------->
<--------------- NTFY( ASP-Down)
<--------------- NTFY(AS-Down)
ASPUP --------------->
(ASP1) M-ASP-Status ----------->
<--------------- NTFY( ASP-Up)
<-------------- NTFY (AS-Up)
ASPAC --------------->
(ASP1) M-ASP-Status ----------->
<-------------- NTFY( ASP-Active)
<-------------- NTFY (AS-Active)
Sachin-Sunil, HSS [Page 18]
Internet Draft Test Specs for M2UA July 2000
ASPIA --------------->
(ASP1) M-ASP-Status ----------->
<-------------- NTFY( ASP-Up)
<-------------- NTFY (AS-Up)
TEST DESCRIPTION:
1. Send ASPDN message for ASP from ASP to the SG.
2. Check A: NTFY messages with status ASP-Down and AS-Down will be
received at the ASP.
3. Check B: Send ASPUP message and check that NTFY with status ASP-Up
and AS-Up is received at ASP.
4. Check C: Send ASPAC message and check that NTFY with status
ASP-Active and AS-Active is received at ASP.
5. Check D: Send ASPIA message and check that NTFY with status ASP-Up
and AS-Up is received at ASP.
6. Check E: NTFY message is sent on stream 0.
7. Repeat the above test case if all messages from AS are sent on
stream other than zero.
8. Repeat the above test case if optional parameters like ALI in ASPUP,
interface identifier in ASPAC and ASPIA are not present. Response
should be same.
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 19]
Internet Draft Test Specs for M2UA July 2000
"ASPAC message with more than one Interface Identifier"
+ TEST NUMBER : 1.3.6
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.4
+ TITLE : AS management
+ SUBTITLE : ASPAC message with more than one interface identifier
+ PURPOSE: To check that If ASPAC message is received with more than
one Interface Identifier 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
ASP. Arrange the data in ASP such that ASPAC message is sent on
stream 0 from ASP to SG containing interface identifiers X, Y, P and
Q. Traffic handling mode in AS1 and AS2 configured at SG is Loadshare
and ASPAC message is sent with the Loadshare mode in Type parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS1 & AS2 is Up
ASPAC ------------------>
Interface Id X,Y,P,Q M-ASP-Status --------->
<----------------- NTFY( ASP-Active)
<----------------- NTFY(AS-Active)
<-------- Data
Interface Id X
<----------------- DATA
<-------- Data
Interface Id Q
<----------------- DATA
Sachin-Sunil, HSS [Page 20]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPAC Message containing interface identifiers X, Y, P and Q
from ASP to the SG.
2. Check A: NTFY messages should be received at ASP with status
ASP-Active and AS-active with interface identifier X, Y, P and Q.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is active in all the AS to which
this ASP belongs. This can be checked by sending DATA message with
interface identifiers X and P.
5. Repeat the above test case if interface identifier parameter is not
present in ASPAC message. The response should be same.
Note: Interface identifier is an optional parameter in the NTFY
message. In some implementation this parameter may not be present in
NTFY message. In that case two NTFY messages 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 21]
Internet Draft Test Specs for M2UA July 2000
"ASPAC message with Interface Identifiers less than configured"
+ TEST NUMBER : 1.3.7
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : AS management
+ SUBTITLE : ASPAC message with Interface Identifiers less than
configured
+ PURPOSE: To check that If ASPAC message is received with Interface
Identifiers less than it is configured for then NTFY message is
returned with those interface identifier and ASP is active only for
those interface identifiers
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. Arrange the data in ASP such that ASPAC message is sent on
stream 0 from ASP to SG containing interface identifiers X and Q.
Traffic handling mode in AS1 and AS2 configured at SG is Loadshare
and ASPAC message is sent with the Loadshare mode in Type parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS1 & AS2 is Up
ASPAC ------------------>
Interface Id X,Q M-ASP-Status --------->
<----------------- NTFY( ASP-Active)
<----------------- NTFY(AS-Active)
<-------- Data
Interface Id X
<----------------- DATA
<-------- Data
Interface Id P
Send Failure ---------->
Sachin-Sunil, HSS [Page 22]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPAC Message containing interface identifiers X and Q from ASP
to the SG.
2. Check A: NTFY messages should be received at ASP with status
ASP-Active and AS-active with interface identifier X and Q.
3. Check B: NTFY message is received on stream 0.
4. Check C: Check that state of ASP is active only for interface
identifier X and Q. Send DATA message with interface identifiers X
and Data primitive should be received at NIF. Send Data primitive
from NIF with interface identifier P. Send failure should be
received.
Note: Interface identifier is an optional parameter in the NTFY
message. In some implementation this parameter may not be present in
NTFY message. In that case response to ASPAC message is implementation
specific. An implementation may reject the ASPAC message or send ERROR
message with cause "Invalid Interface Identifier".
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 23]
Internet Draft Test Specs for M2UA July 2000
"ASPIA message with more than one Interface Identifier"
+ TEST NUMBER : 1.3.8
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : ASPIA message with more than one interface identifier
+ PURPOSE: To check that If ASPIA message is received with more than
one interface identifier 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
ASP and ASP is active. Arrange the data in ASP such that ASPIA
message is sent from ASP to SG on stream 0 containing interface
identifiers for AS1 and AS2. Traffic handling mode in AS1 and AS2
configured at SG is Loadshare and ASPAC message is sent with the
Loadshare mode in Type parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS1 & AS2 is Active
ASPIA ------------------>
Interface Id X,Y,P,Q M-ASP-Status --------->
<----------------- NTFY( ASP-Up)
<----------------- NTFY(AS-Up/AS-Pending)
<----------- Data
Interface Id X
Send Failure -------->
<------------ Data
interface id Q
Send Failure -------->
Sachin-Sunil, HSS [Page 24]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPIA Message containing interface identifiers P, Q, X and Y
from ASP to the SG.
2. Check A: NTFY messages will be received at the ASP with status
ASP-Up and AS-Up with interface id X, Y, P and Q.
3. Check B: NTFY message is sent on stream 0.
4. Check C: Check that state of ASP is Up in all the AS to which this
ASP belongs. This can be checked by sending Data primitive from NIF
at SG containing interface identifier X and P.
5. Repeat the above test case if interface identifier parameter is not
present in ASPIA message. The response should be same.
Note: Interface identifier is an optional parameter in NTFY message.
In some implementation this parameter may not be present in NTFY
message. In that case four NTFY messages with status AS-Up/ AS-Pending
will be received two for AS1 and two for AS2.
Note1: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 25]
Internet Draft Test Specs for M2UA July 2000
"ASPIA message with Interface Identifiers less than configured"
+ TEST NUMBER : 1.3.9
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : ASPIA message with Interface Identifiers less than
configured
+ PURPOSE: To check that If ASPIA message is received with Interface
Identifiers less than it is configured for then NTFY message is
returned with those interface identifier and ASP is Up only for those
interface identifiers
+ TEST CONFIGURATION: B
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is active. Arrange the data in ASP such that ASPIA
message is sent from ASP to SG on stream 0 containing interface
identifiers for AS1 and AS2. Traffic handling mode in AS1 and AS2
configured at SG is Loadshare and ASPAC message is sent with the
Loadshare mode in Type parameter.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
AS1 & AS2 is Active
ASPIA ------------------>
Interface Id X,Q M-ASP-Status --------->
<----------------- NTFY( ASP-Up)
<----------------- NTFY(AS-Up/AS-Pending)
<----------- Data
Interface Id X
Send Failure -------->
<----------- Data
interface id P
<---------------- DATA
Sachin-Sunil, HSS [Page 26]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPIA Message containing interface identifiers Q and X from ASP
to the SG.
2. Check A: NTFY messages will be received at the ASP with status
ASP-Up and AS-Up with interface id X and Q.
3. Check B: NTFY message is sent on stream 0.
4. Check C: Check that state of ASP is Up in all the AS to which this
ASP belongs. This can be checked by sending Data primitive from NIF
at SG containing interface identifier X and P.
5. Repeat the above test case if interface identifier parameter is not
present in ASPIA message. The response should be same.
Note: Interface identifier is an optional parameter in the NTFY
message. In some implementation this parameter may not be present in
NTFY message. In that case four NTFY messages with status AS-Up/
AS-Pending will be received two for AS1 and two for AS2.
Note1: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 27]
Internet Draft Test Specs for M2UA July 2000
"Notify Message with AS Status is sent only for AS State change - A"
+ TEST NUMBER : 1.3.10
+ Reference: draft-ietf-sigtran-m2ua-03.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: SG is having SCTP association with ASP1 and ASP2.
ASP1 is active while ASP2 is down. Arrange the data in AS such that
ASPUP, ASPAC, ASPIA and ASPDN messages are sent on stream 0 for ASP2.
ALI parameter in ASPUP message should be M2UA. Reason parameter in
ASPDN message should be 0x1.Type parameter in ASPAC and ASPIA message
should be same as the traffic handling mode configured for AS at SG.
Interface identifiers parameter should be having values X and Y.
EXPECTED MESSAGE SEQUENCE :
AS SG SM
Both ASP are active
ASPIA(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
Check: NTFY(AS-Up) is not received
M-ASP-Status --------->
ASPDN(ASP1) ----------------->
<---------------- NTFY( ASP-Down)
Check: NTFY(AS-Down) is not received
M-ASP-Status --------->
ASPUP(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
Check: NTFY(AS-Up) is not received
M-ASP-Status --------->
ASPAC(ASP1) ----------------->
<---------------- NTFY( ASP-Active)
Check: NTFY(AS-Active) is not received
M-ASP-Status --------->
Sachin-Sunil, HSS [Page 28]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPUP message for ASP2 from AS to the SG.
2. Check A: NTFY messages with status ASP-Up will be 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 ASPAC, ASPIA and
ASPDN for ASP2 from AS to SG. NTFY message with AS status should not
be received in any case.
Sachin-Sunil, HSS [Page 29]
Internet Draft Test Specs for M2UA July 2000
"Notify Message with AS Status is sent only for AS State change- B"
+ TEST NUMBER : 1.3.11
+ Reference: draft-ietf-sigtran-m2ua-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 received
if AS state has changed.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS. There are two ASP in AS, ASP1 and ASP2. 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
ASP1and ASP2 on stream 0. Fill the interface identifier X and Y 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)
M-ASP-Status --------->
ASPIA(ASP2) ----------------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-Up/AS-Pending)
M-ASP-Status --------->
ASPDN(ASP1) ----------------->
<---------------- NTFY( ASP-Down)
M-ASP-Status --------->
ASPDN(ASP2) ----------------->
<---------------- NTFY( ASP-Down)
<---------------- NTFY( AS-Down/AS-Pending)
Sachin-Sunil, HSS [Page 30]
Internet Draft Test Specs for M2UA July 2000
M-ASP-Status --------->
ASPUP(ASP1) ----------------->
<---------------- NTFY( ASP-Up)
M-ASP-Status --------->
ASPUP(ASP2) ----------------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-Up)
M-ASP-Status --------->
ASPAC(ASP1) ----------------->
<---------------- NTFY( ASP-Active)
M-ASP-Status --------->
ASPAC(ASP2) ----------------->
<---------------- NTFY( ASP-Active)
<---------------- NTFY( AS-Active)
M-ASP-Status --------->
TEST DESCRIPTION:
1. Send ASPIA message for ASP1 and ASP2 from ASP to the SG with
interface identifier X and Y and Type parameter any valid value.
2. Check A: NTFY messages with status ASP-Up and AS-Up are received at
the AS.
3. Repeat the above test case for other messages like ASPDN, ASPUP and
ASPAC for ASP1 and ASP2 from AS to SG.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 31]
Internet Draft Test Specs for M2UA July 2000
"Link Establish and Release Request and Confirmation"
+ TEST NUMBER : 1.4.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1
+ TITLE : Link management
+ SUBTITLE : Link Establish and Release Request and Confirmation
+ PURPOSE: To check that if Establish Request is received from ASP then
NIF are indicated that establish request has been received. Also if
NIF sends Establish confirm primitive then ESTABLISH CONFIRMATION
message is sent to the concerned ASP.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2.
Both ASPs are active. Arrange the data at ASP1 such that ESTABLISH
REQUEST and RELEASE REQUEST messages are sent to the SG with the
interface identifier X. Reason Parameter in the RELEASE REQUEST
message should be Release_Mgmt. Also arrange the data in NIF at SG
such that Establish Confirmation and Release Confirmation primitives
are sent to the SG with interface identifier X in response to the
received Establish and Release primitive. In Release Confirmation
fill the reason with Release_Mgmt.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
a)
ESTABLISH REQUEST --------------->
Establish ----------->
<--------- Establish confirm
Interface id X
<-------------- ESTABLISH CONFIRM
b)
RELEASE REQUEST --------------->
Reason= Release_Mgmt Release ----------->
<--------- Release confirm
Interface id X
<-------------- RELEASE CONFIRM
Sachin-Sunil, HSS [Page 32]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ESTABLISH REQUEST message from ASP1 to the SG with interface
identifier X.
2. Check A: Establish Request indication should be received at the NIF.
3. Send Establish confirm primitive from NIF at SG with interface id X.
4. Check B: ESTABLISH CONFIRMATION message is received only at ASP1 and
not at ASP2.
5. Repeat the above test case for RELEASE REQUEST message from ASP1 to
SG. Release Request indication should be sent to the NIF with the
reason received in RELEASE REQUEST message. Send Release
Confirmation Primitive from NIF with interface identifier X. RELEASE
CONFIRAMTION message will be received at ASP1 and not at ASP2.
Sachin-Sunil, HSS [Page 33]
Internet Draft Test Specs for M2UA July 2000
"Release indication Primitive from NIF"
+ TEST NUMBER : 1.4.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1
+ TITLE : Link management
+ SUBTITLE: Release indication Primitive from NIF
+ PURPOSE: To check that if Release indication Primitive is received
from NIF at SG then SG sends RELEASE INDICATION message to the
concerned ASP.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2.
Both ASP are Active. Also arrange the data in NIF at SG such that
Release Indication primitive is sent to the SG with interface
identifier X. In Release indication fill the reason with Release_Sios.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
<--------- Release Indication
Interface id X
<-------------- RELEASE INDICATION
TEST DESCRIPTION:
1. Send Release Indication Primitive from NIF in the SG containing the
interface identifier X.
2. Check A: RELEASE INDICATION message will be received at ASP1
containing the interface identifier passed to it from NIF.
3. Check B: RELEASE INDICATION message is received only at ASP1 and not
at ASP2.
4. Repeat the test case with different valid value of reason parameter
in Release Indication primitive. In these cases, RELEASE INDICATION
message will be sent to ASP1 with the reason value received from NIF.
5. Repeat the above test case with interface identifier P. In this case
message will be received at ASP2 and not at ASP1.
Sachin-Sunil, HSS [Page 34]
Internet Draft Test Specs for M2UA July 2000
"STATE Request primitive"
+ TEST NUMBER : 1.4.3
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 and 2.3.1.4
+ TITLE : Link management
+ SUBTITLE : STATE Request primitive
+ PURPOSE: To check that if State request message is received from ASP
then NIF is sent state primitive.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that STATE REQUEST
Message is sent from ASP to the SG with Interface identifier X and
State parameter Status_LPO_Set.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
STATE REQUEST --------------->
State = Status_LPO_Set State Request ----------->
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to SG with state parameter
Status_LPO_Set.
2. Check A: State Request primitive will be received at the NIF at SG
containing the interface identifier X and State received.
3. Repeat the above test case for other valid State parameter values.
Sachin-Sunil, HSS [Page 35]
Internet Draft Test Specs for M2UA July 2000
"STATE Confirm and Indication primitive"
+ TEST NUMBER : 1.4.4
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 and 2.3.1.4
+ TITLE : Link management
+ SUBTITLE : STATE Confirm and Indication primitive
+ PURPOSE: To check that if State Confirm primitive is received from
ULP at SG with interface identifier and State then STATE CONFIRM
message is sent from SG to all the ASP which are handling traffic for
that interface identifier.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2
and both ASP are active. Arrange the data in NIF at SG such that
State Confirm primitive with state as Status_LPO_Set is sent to SG
for interface identifier X.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
a)
STATE REQUEST --------------->
State = Status_LPO_Set State Request ----------->
<--------- State confirm
Status_LPO_Set
Interface id X
To AS1 <-------------- STATE CONFIRM
b)
<--------- State Indication
Event_Enter_RPO
Interface id X
<-------------- STATE INDICATION
Sachin-Sunil, HSS [Page 36]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send STATE REQUEST message from AS to SG with state status_LPO_Set.
Send State Confirm primitive from NIF at SG in its response with
state Status_LPO_Set and interface identifier X.
2. Check A: STATE CONFIRM message will be received at ASP1 with state
as Status_LPO_Set.
3. Check B: STATE CONFIRM message will not be received at ASP2.
4. Repeat the above test case for different valid values of State
Parameter. STATE CONFIRM message will be received at ASP1 with the
State parameter sent in State Confirm primitive from NIF at the SG.
5. Repeat the above test case for State Indication primitive with State
parameter Event_Enter_RPO. STATE INDICATION message with state
Event_Enetr_RPO will be received at AS1 and not at AS2. Repeat the
test case for different valid values of State Parameter.
6. Repeat the above test case for interface identifier P. In this case
STATE CONFIRM and STATE INDICATION messages will be received at ASP2
and not at ASP1.
Sachin-Sunil, HSS [Page 37]
Internet Draft Test Specs for M2UA July 2000
"RETRIEVAL REQUEST and CONFIRM message"
+ TEST NUMBER : 1.4.5
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.1 and 2.3.1.6
+ TITLE : Link management
+ SUBTITLE : RETRIEVAL REQUEST and CONFIRM Message
+ PURPOSE: To check that if RETRIEVAL REQUEST message is received from
ASP with action Action_Rtrv_BSN then SG sends Retrieval primitive to
the NIF. Also if Retrieval primitive is received from NIF then
RETRIEVAL CONFIRM message is sent to the ASP.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data at ASP such that RETRIEVAL
REQUEST message is sent from ASP to SG with interface identifier X
and action Action_Rtrv_BSN. Fsn_bsn parameter may be having any
value. Arrange the data in NIF such that Retrieval primitive is sent
from NIF at SG to M2UA with action Action_Rtrv_BSN.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
<--------- State Indication
Event_Enter_RPO
Interface id X
<-------------- STATE INDICATION
RETRIEVAL REQUEST --------------->
Action = Action_Rtrv_BSN Retrieval ----------->
Action_Rtrv_BSN
<--------- Retrieval
Action_Rtrv_BSN
<-------------- RETRIEVAL CONFIRM
Sachin-Sunil, HSS [Page 38]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send State Indication from NIF with State Event_Enter_RPO to M2UA at
SG. STAE INDICATION message will be received at the ASP.
2. Send RETRIEVAL REQUEST message from ASP to SG with action
Action_Rtrv_BSN and fsn_bsn field any value in response to STATE
INDICATION message.
3. Check A: NIF at SG will receive Retrieval primitive with action
Action_Rtrv_BSN and FSN received.
4. Send Retrieval primitive from NIF to M2UA at SG with action
Action_Rtrv_BSN and fsn_bsn any value.
5. Check B: RETRIEVAL CONFIRM message will be received at the ASP.
6. Repeat the above test case if fsn_bsn field in Retrieval primitive
is -1. This value should be received at the ASP in the fsn_bsn field
of the RETRIEVAL CONFIRM message.
7. Repeat the above test case with action Action_Rtrv_Msgs and
Action_Drop_Msgs. In case of these actions also fill the fsn_bsn
field with some value.
Sachin-Sunil, HSS [Page 39]
Internet Draft Test Specs for M2UA July 2000
"RETRIEVAL CONFIRM, INDICATION and COMLETE INDICATION messages"
+ TEST NUMBER : 1.4.6
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1, 2.3.1.6
and 2.3.1.7
+ TITLE : Link management
+ SUBTITLE : RETRIEVAL CONFIRM, INDICATION and COMPLETE INDICATION
Messages
+ PURPOSE: To check that if Retrieval Confirm Primitive is received
from NIF with Action Action_Rtrv_BSN and BSN number retrieved then SG
sends RETRIEVAL CONFIRM message to the concerned ASP with the action
and BSN number passed to it from NIF.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2
and both ASP are Active. Arrange data in NIF at SG such that Retrieval
primitive is sent to SG with interface identifier X, action
Action_Rtrv_BSN and BSN any value.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
RETRIEVAL REQUEST --------------->
Action = Action_Rtrv_Msgs Retrieval ----------->
Action_Rtrv_Msgs
<--------- Retrieval
Action_Rtrv_Msgs
<-------------- RETRIEVAL CONFIRM
Action_Rtrv_Msgs
<--------- Retrieval
MSU from retransmit
Queue and not last MSU
Interface Id X
<-------------- RETRIEVAL INDICATION
<--------- Retrieval
MSU from retransmit
Queue and last MSU
Interface Id X
<-------------- RETRIEVAL COMPLETE INDICATION
Sachin-Sunil, HSS [Page 40]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST message but with action Action_Rtrv_Msgs.
Retrieval primitive will be received at the NIF. Send Retrieval
primitive from NIF to the M2UA at SG in response. RETRIEVAL CONFIRM
message will be sent from SG to ASP.
2. Send Retrieval primitive containing MSU and it is not the last MSU
which will be told by the NIF.
3. Check A: RETRIEVAL INDICATION is received at the ASP1 with the PDU
containing the MSU received from NIF.
4. Send Retrieval primitive containing MSU and it is the last MSU which
will be told by the NIF.
5. Check B: RETRIEVAL COMPLETE INDICATION is sent to the ASP1 with the
PDU containing the MSU received from NIF.
6. Repeat the above test cases for interface identifier P. In this case
messages will be received at ASP2 and not at ASP1.
Sachin-Sunil, HSS [Page 41]
Internet Draft Test Specs for M2UA July 2000
"Invalid Version Error"
+ TEST NUMBER : 1.5.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 and 3.3.3.3
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Version Error
+ PURPOSE: To check that if any message with Invalid version is
received at the SG then SG responds with ERROR message containing
cause "Invalid Version" and diagnostic information filled with the
version the SG supports.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that ASPIA message
is sent to SG with the version other than Release 1.0 protocol. Type
parameter in ASPIA message should be same as is the traffic handling
mode configured for AS at the SG. Interface identifier parameter
should be X and Y.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
ASPIA ----------------->
Version = 2
<---------------- ERROR
Cause = Invalid Version
TEST DESCRIPTION:
1. Send ASPIA message ASP to SG containing version 2 in the common
header.
2. Check A: ERROR message will be received at 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 ASP to SG like
ASPAC, ASPUP, ASPDN, RETRIEVAL REQUEST, ESTABLISH REQUEST, RELEASE
REQUEST, STATE REQUEST and DATA.
Sachin-Sunil, HSS [Page 42]
Internet Draft Test Specs for M2UA July 2000
"Invalid Traffic Handling Mode Error"
+ TEST NUMBER : 1.5.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1, 3.3.3.4
and 3.3.3.5
+ 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 ASP is Active. Arrange the data in ASP such that ASPAC and
ASPIA messages are sent on stream 0 with Type field filled with
Loadshare mode of Traffic handling. Traffic Handling Mode at SG for
AS is Override Mode. Interface identifier parameter should be X and
common header should be valid.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
a)
ASPAC ----------------->
Type = Loadshare
<---------------- ERROR
Cause = Invalid Traffic Handling mode
b)
ASPIA ----------------->
Type = Loadshare
<---------------- ERROR
Cause = Invalid Traffic Handling mode
TEST DESCRIPTION:
1. Send ASPAC message from ASP to SG containing Type field Loadshare.
2. Check A: ERROR message will be received at 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 0x3.
5. Repeat all the above tests for ASPIA message with same parameters
that were used for ASPAC message.
Note: NTFY message with AS status may come before the NTFY message
with ASP status.
Sachin-Sunil, HSS [Page 43]
Internet Draft Test Specs for M2UA July 2000
"Invalid Traffic Handling Mode Error if there are two ASP in one AS"
+ TEST NUMBER : 1.5.3
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1, 3.3.3.4 and
3.3.3.5
+ 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 AS such that ASPAC
message for ASP1 is sent on stream 0 with Type field filled with
Override mode of Traffic handling and ASPAC message for ASP2 is sent
on stream 0 with Type field filled with Loadshare mode of Traffic
handling. Traffic Handling Mode defined at SG for AS is Override
Mode. Fill value X and Y in interface identifier parameter.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
ASPAC (ASP1) ----------------->
Type = Override
M-ASP-Status --------->
<---------------- NTFY( ASP-Active)
<---------------- NTFY( AS-Active)
ASPAC (ASP2) ----------------->
Type = Loadshare
<---------------- ERROR
Cause = Invalid Traffic Handling mode
Sachin-Sunil, HSS [Page 44]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPAC message from ASP1 to SG containing Type field Override.
2. Check A: NTFY messages with ASP-Up and AS-Up status are received at
the AS.
3. Send ASPAC message from ASP2 to SG containing Type field Loadshare.
4. Check B: ERROR message is received at the ASP containing cause
Invalid Traffic Handling Mode.
5. Repeat the above test cases for other values of Type field with
Traffic Handling Mode for AS at SG being different from this Type field.
6. Repeat the test case with Type field having value that is not
defined i.e. any value greater than 0x03.
7. 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 45]
Internet Draft Test Specs for M2UA July 2000
"Unrecognised Message Type"
+ TEST NUMBER : 1.5.4
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.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 ASP is Active. Arrange the data in ASP such that a message
with Message type not defined is sent to SG. Other parameters in the
message can be like any other valid message.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
Message ----------------->
Message Type = 0708
<---------------- ERROR
Cause = Invalid Message Type
DATA -------------->
Interface Id X Receive Data --------->
TEST DESCRIPTION:
1. Send a message with message type 0708 or any other value which is
not defined from ASP to SG.
2. Check A: ERROR message will be received at the ASP containing cause
"Invalid Message Type".
3. Check B: State of ASP at SG is not disturbed.
4. Repeat the above test case by sending ESTABLISH CONFIRMATION,
RELEASE CONFIRMATTION, RELEASE INDICATION, STATE CONFIRM, STATE
INDICATION, RETRIEVAL CONFIRM and RETRIEVAL INDICATION messages
which the SG is not expected to receive. In this case an error will
be reported to the SM and message will be discarded.
Sachin-Sunil, HSS [Page 46]
Internet Draft Test Specs for M2UA July 2000
"Invalid Interface Identifier in MAUP messages"
+ TEST NUMBER : 1.5.5
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 and 2.2
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Interface Identifier
+ PURPOSE: To check that if a message with "invalid interface
identifier" i.e. interface identifier not defined at SG is received
then SG responds with ERROR message containing cause "Invalid
Interface Identifier".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that DATA message
with interface identifier P is sent to SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
DATA ----------------->
Interface Id P
<---------------- ERROR
Cause = Invalid Interface Identifier
DATA -------------->
Interface Id X Receive Data --------->
TEST DESCRIPTION:
1. Send DATA message with interface identifier P that is not defined at
SG.
2. Check A: ERROR message will be received at ASP containing cause
"Invalid Interface Identifier".
3. Check B: State of ASP at SG is not disturbed.
4. Repeat the above test case for test configuration D. DATA message
is sent from ASP1 with Interface identifier P that is defined at SG
for ASP2. In this case also ERROR message should be received at ASP
with cause "Invalid Interface identifier".
5. Repeat the above test case for other messages like RELEASE REQUEST,
ESTABLISH REQUEST, STATE REQUEST and RETRIEVAL REQUEST. Other
parameters in these messages should be having valid values. Response
will be same in all cases.
Sachin-Sunil, HSS [Page 47]
Internet Draft Test Specs for M2UA July 2000
"Invalid interface Identifier parameter in ASPAC message"
+ TEST NUMBER : 1.5.6
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Parameter in ASPAC message
+ PURPOSE: To check that if ASPAC message with Invalid interface
identifier 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 interface identifier not equal to X and
Y is sent to the SG on stream 0.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
AS is Up
ASPAC ----------------->
Interface Id Q
<---------------- ERROR
Cause = Invalid Interface Identifier
ASPAC ----------------->
Interface Id X and Q
M-ASP-Status --------->
<---------------- NTFY( ASP-Active interface id X)
<---------------- NTFY( AS-Active interface id X)
<---------------- ERROR(Diagnostic field = Q)
Cause = Invalid Interface Identifier
TEST DESCRIPTION:
1. Send ASPAC message with interface identifier Q.
2. Check A: SG will take no action and will discard the ASPAC message.
3. Send ASPAC message with interface identifier X and Q.
4. Check B: NTFY messages will be received at the AS with status
ASP-Active and AS-Active for interface identifier X.
5. Repeat the above test case with ASPIA message in ASP Active state.
Response should be same.
Note: Interface identifier is an optional parameter in ASPAC message.
In some implementation this field may not come in ASPAC and ASPIA
message. In those implementation test case need not be run.
Note1: NTFY with AS status may come before the MTFY message with ASP
status.
Sachin-Sunil, HSS [Page 48]
Internet Draft Test Specs for M2UA July 2000
"Invalid Reason parameter in ASPDN message"
+ TEST NUMBER : 1.5.7
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1
+ 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
ASP and ASP is Active. Arrange the data in ASP such that ASPDN
message with Reason Parameter filled with value 02 or more is sent to
the SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
ASPDN ----------------->
Reason = 0x2
M-ASP-Status --------->
<---------------- NTFY( ASP-Down)
<---------------- NTFY( AS-Down)
TEST DESCRIPTION:
1. Send ASPDN message with Reason Parameter 0X2 from ASP to SG.
2. Check A: NTFY messages with status ASP-Down and AS-Down are received
at ASP.
Note1: NTFY with AS status may come before the NTFY message with ASP
status.
Sachin-Sunil, HSS [Page 49]
Internet Draft Test Specs for M2UA July 2000
"Invalid ALI parameter in ASPUP message"
+ TEST NUMBER : 1.5.8
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1
+ 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
ASP and ASP is Down. Arrange the data in ASP such that ASPUP message
with ALI Parameter filled with value other than M2UA is sent to SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
ASPUP ----------------->
ALI <> M2UA Message is discarded
DATA ----------------->
Interface id X Data ------------>
TEST DESCRIPTION:
1. Send ASPUP message with ALI Parameter not equal to M2UA.
2. Check A: ASPUP message will be discarded and no message will be
received at ASP.
3. Check B: State of ASP at SG is not disturbed.
Note: ALI is an optional parameter. In some implementation this
parameter may not come in ASPUP message. In these implementations this
test case need not be run.
Sachin-Sunil, HSS [Page 50]
Internet Draft Test Specs for M2UA July 2000
"Message length less than the length of mandatory Parameters"
+ TEST NUMBER : 1.5.9
+ Reference: draft-ietf-sigtran-m2ua-03.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: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that RELEASE
REQUEST message with length parameter filled with value equal to the
length of M2UA message header only.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
RELEASE REQUEST --------------->
Error -------->
DATA --------------->
Interface id X Data -------->
TEST DESCRIPTION:
1. Send RELEASE REQUEST message with length parameter filled with value
equal to the length of M2UA message header only.
2. Check A: RELEASE REQUEST message will be discarded and Error is
reported to SM.
3. Check B: State of ASP at SG is not disturbed.
4. Repeat the above test case for other messages like STATE REQUEST,
RETRIEVAL REQUEST.
Sachin-Sunil, HSS [Page 51]
Internet Draft Test Specs for M2UA July 2000
"Interface Identifier not present in MAUP and MGMT messages"
+ TEST NUMBER : 1.5.10
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Interface Identifier not present in MAUP and MGMT messages
+ PURPOSE: To check that if a MAUP or MGMT message without Interface
Identifier is sent to SG then SG responds with ERROR message "Invalid
Interface Id".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that RELEASE
REQUEST message without Interface Identifier (Tag 0x1 is not there
after common header) is sent to SG. Reason parameter is having valid
value.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
RELEASE REQUEST --------------->
<--------------- ERROR
Invalid Interface Id
DATA --------------->
Interface id X Data -------->
TEST DESCRIPTION:
1. Send RELEASE REQUEST message without interface identifier to the SG.
2. Check A: RELEASE REQUEST message will be discarded and ASP will
receive ERROR message with cause "Invalid Interface Id".
3. Check B: State of ASP at SG is not disturbed.
4. Repeat the above test case for other messages like STATE REQUEST,
RETRIEVAL REQUEST.
Note: A new Cause value in ERROR message can be added.
Sachin-Sunil, HSS [Page 52]
Internet Draft Test Specs for M2UA July 2000
"Length of Interface Identifier parameter in M2UA message header is
other than four"
+ TEST NUMBER : 1.5.11
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Length of Interface Identifier parameter in M2UA message
header is other than 4
+ PURPOSE: To check that if a MAUP or MGMT message with length field in
M2UA message header less than four is sent to SG then SG responds
with ERROR message with cause "Invalid Interface Id".
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that RELEASE
REQUEST message with length in M2UA message header less than four is
sent to SG. Reason parameter is having the RELEASE_MGMT.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
RELEASE REQUEST --------------->
length in M2Ua header = 3
<--------------- ERROR
Invalid Interface Id
DATA --------------->
Interface id X Data -------->
TEST DESCRIPTION:
1. Send RELEASE REQUEST message with length in M2UA message header less
than four to the SG.
2. Check A: RELEASE REQUEST message will be discarded and ERROR message
will be received at the ASP with cause "invalid Interface Id".
3. Check B: State of ASP at SG is not disturbed.
4. Repeat the above test case for other messages like STATE REQUEST,
RETRIEVAL REQUEST.
Sachin-Sunil, HSS [Page 53]
Internet Draft Test Specs for M2UA July 2000
"Invalid Reason Parameter in RELEASE REQUEST message"
+ TEST NUMBER : 1.5.12
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Reason Parameter in RELEASE REQUEST message
+ PURPOSE: To Check that if RELEASE REQUEST message is received with
invalid value of reason parameter then
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that RELEASE
REQUEST message with interface identifier X and invalid value of
Reason parameter is sent to SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
RELEASE REQUEST --------------->
Reason = 0xA
Release request -------->
TEST DESCRIPTION:
1. Send RELEASE REQUEST message with reason value 0xA, which is invalid,
to the SG.
2. Check A: Release Primitive will be received at NIF at SG.
Sachin-Sunil, HSS [Page 54]
Internet Draft Test Specs for M2UA July 2000
"Invalid State Parameter in STATE REQUEST message"
+ TEST NUMBER : 1.5.13
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid State Parameter in STATE REQUEST message
+ PURPOSE: To check that if STATE REQUEST message is received with
invalid value of State parameter then SG discards the STATE REQUEST
message
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that STATE
REQUEST message with interface identifier X and invalid value of
State parameter is sent to SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
STATE REQUEST --------------->
State = 0x6
DATA --------------->
Interface id X Data -------->
TEST DESCRIPTION:
1. Send STATE REQUEST message with state value 0x6, which is invalid,
to the SG.
2. Check A: STATE REQUEST message will be discarded and no message will
be received at ASP.
3. Check B: State of ASP at SG is not disturbed.
Sachin-Sunil, HSS [Page 55]
Internet Draft Test Specs for M2UA July 2000
"Invalid Action Parameter in RETRIEVAL REQUEST message"
+ TEST NUMBER : 1.5.14
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Action Parameter in RETRIEVAL REQUEST message
+ PURPOSE: To check that if RETRIEVAL REQUEST message is received with
invalid value of Action parameter then SG discards the RETRIEVAL
REQUEST message.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that RETRIEVAL
REQUEST message with interface identifier and invalid value of Action
parameter is sent to SG. Fsn_bsn parameter may be having any value.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
RETRIEVAL REQUEST --------------->
Action = 0x4
DATA --------------->
Interface id X Data -------->
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST message with action value 0x4, which is
invalid, to the SG.
2. Check A: RETRIEVAL REQUEST message will be discarded and no message
will be received at the ASP.
3. Check B: State of ASP at SG is not disturbed.
4. Repeat the above test case for invalid value of fsn_bsn field like
-2 etc. Response should be same.
Sachin-Sunil, HSS [Page 56]
Internet Draft Test Specs for M2UA July 2000
"ERROR message with invalid error code"
+ TEST NUMBER : 1.5.15
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : ERROR message with invalid error code
+ PURPOSE: To check that if ERROR message with Invalid Error code
parameter is received then M2UA at ASP doesn't take any action but
discard the message.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and AS is Active. Arrange the data in ASP such that ERROR message
with invalid error code parameter( error code > 0x6) is sent to the
SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is active
<--------- State Indication
Event_Enter_RPO
Interface id X
<-------------- STATE INDICATION
ERROR --------------->
Error Code = 0x6 Error -------->
TEST DESCRIPTION:
1. Send STATE INDICATION message from SG to the ASP. In response to
this message, send ERROR message with error code greater than or
equal to 0x6 from ASP to the SG.
2. Check A: Error will be reported to the SM.
3. Further actions are implementation dependent. Implementation may
close the association in this case.
Sachin-Sunil, HSS [Page 57]
Internet Draft Test Specs for M2UA July 2000
"ASPUP message in ASP-Up state"
+ TEST NUMBER : 1.6.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ 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
ASP and ASP is Down. Arrange the data in ASP such that ASPUP message
is sent to the SG two times on stream 0. ALI parameter in ASPUP
message should be M2UA.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Down
ASPUP ---------------->
M-ASP-Status --------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-Up)
ASPUP ----------------->
<----------------- NTFY( ASP-Up)
ASPAC ----------------->
M-ASP-Status --------->
<----------------- NTFY( ASP-Active)
<----------------- NTFY( AS-Active)
TEST DESCRIPTION:
1. Send ASPUP message to the SG in ASP-Down state. NTFY messages will
come from the SG with status ASP-Up and AS-Up. Send ASPUP message
again from the ASP.
2. Check A: NTFY message with status ASP-Up will be received at the ASP.
3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the
Up state. Send ASPAC message for the ASP 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 58]
Internet Draft Test Specs for M2UA July 2000
"ASPDN message in ASP-Down state"
+ TEST NUMBER : 1.6.2
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ 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 ASP
such that ASPDN message is sent on stream 0 to the SG two times with
the valid Reason Parameter.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Up
ASPDN ----------------->
M-ASP-Status --------->
<---------------- NTFY( ASP-Down)
<---------------- NTFY( AS-Down)
ASPDN ----------------->
<---------------- NTFY( ASP-Down)
ASPUP ----------------->
M-ASP-Status --------->
<---------------- 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 ASP.
2. Check A: NTFY message with status ASP-Down should be received at ASP.
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 59]
Internet Draft Test Specs for M2UA July 2000
"ASPAC message in ASP-Active state"
+ TEST NUMBER : 1.6.3
+ Reference: draft-ietf-sigtran-m2ua-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 ASP
such that ASPAC message with correct Type (Type is same as defined at
SG for the AS) and interface identifier X and Y is sent on stream 0
to the SG two times.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Up
ASPAC ----------------->
M-ASP-Status --------->
<---------------- NTFY( ASP-Active)
<---------------- NTFY( AS-Active)
ASPAC ----------------->
<---------------- NTFY( ASP-Active)
DATA ----------------->
Data --------->
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 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 Data
indication to the NIF.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 60]
Internet Draft Test Specs for M2UA July 2000
"ASPIA message in ASP-Up state"
+ TEST NUMBER : 1.6.4
+ Reference: draft-ietf-sigtran-m2ua-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 ASP.
+ 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 ASP such that ASPIA message with correct Type (Type is same as
defined at SG for the AS) and interface identifier X and Y is sent on
stream 0 to the SG two times.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
ASPIA ----------------->
M-ASP-Status --------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-up/Pending)
ASPIA ----------------->
<---------------- NTFY( ASP-Up)
ASPAC ----------------->
M-ASP-Status --------->
<---------------- 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 ASP.
2. Check A: NTFY message with status ASP-Up will be received at ASP.
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 NTFY message with status
ASP-Active should be received at ASP.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 61]
Internet Draft Test Specs for M2UA July 2000
"ASPAC message in ASP-Down state"
+ TEST NUMBER : 1.6.5
+ Reference: draft-ietf-sigtran-m2ua-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
ASP such that ASPAC message with correct Type (Type is same as
defined at SG for the AS) and interface identifier X and Y is sent to
the SG on stream 0.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Down
ASPAC ----------------->
<---------------- NTFY( ASP-Down)
ASPUP ----------------->
M-ASP-Status --------->
<---------------- 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 ALI M2UA for the ASP and SG
should respond with NTFY message with status ASP-Up.
4. Repeat the above test case for ASPIA message i.e. ASPIA message is
received in ASP-Down state with the same parameters as were in the
ASPAC message. Response should be same.
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
Sachin-Sunil, HSS [Page 62]
Internet Draft Test Specs for M2UA July 2000
"ASPUP message in ASP-Active state"
+ TEST NUMBER : 1.6.6
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5
+ 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 ASP and ASP
state is moved to ASP-up.
+ CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and ASP1 is Active. Arrange the data in ASP such that ASPUP message
with ALI parameter M2UA is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
ASPUP ----------------->
M-ASP-Status --------->
<---------------- NTFY( ASP-Up)
<---------------- NTFY( AS-Up)
ASPAC ----------------->
M-ASP-Status --------->
<---------------- 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.
Note: In some implementation there may be T(r) running on receiving
ASPUP 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 Data primitive.
Sachin-Sunil, HSS [Page 63]
Internet Draft Test Specs for M2UA July 2000
"ASPDN message in ASP-Active state"
+ TEST NUMBER : 1.6.7
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5
+ 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
ASP and ASP is Active. Arrange the data in ASP such that ASPDN
message with valid Reason parameter is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Active
ASPDN ----------------->
M-ASP-Status --------->
<---------------- NTFY( ASP-Down)
<---------------- NTFY( AS-Down/Pending)
ASPUP ----------------->
M-ASP-Status --------->
<---------------- 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 should be received at ASP.
3. Check B: State of ASP should become Down. Send Data primitive from
NIF with interface idnetifier X to send DATA to the ASP and send
failure should be received at the NIF.
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 Data primitive.
Sachin-Sunil, HSS [Page 64]
Internet Draft Test Specs for M2UA July 2000
"DATA message from AS in ASP-Down state"
+ TEST NUMBER : 1.7
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5
+ TITLE : DATA message in ASP-Down State
+ 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
ASP and ASP is Down. Arrange the data in ASP such that DATA message
with interface identifier X is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Down
DATA ----------------->
<----------------- NTFY(ASP-Down)
ASPUP ----------------->
M-ASP-Status --------->
<---------------- 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 no message will be
received at the ASP in response to DATA message.
3. Check that state of SG is not disturbed. Send ASPUP message with ALI
parameter M2UA. SG will respond with NTFY (ASP-Up).
Sachin-Sunil, HSS [Page 65]
Internet Draft Test Specs for M2UA July 2000
"ASPM messages when SG has locked the ASP for Management reason"
+ TEST NUMBER : 1.8
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5
+ TITLE : AS management
+ SUBTITLE : ASPM messages when SG has locked the ASP for Management
reason
+ PURPOSE: To check that if ASPM message is received when SG has locked
the ASP for management reason then NTFY message wit ASP-Down status is
sent to AS.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
AS and ASP1 may be in any state. Arrange the data in SG such that ASP
is locked at the SG. Arrange the data in AS such that ASPM message
with valid parameters are sent to the SG on stream 0
EXPECTED MESSAGE SEQUENCE :
AS SG SM + NIF
ASP is Down
<---------- 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.
Sachin-Sunil, HSS [Page 66]
Internet Draft Test Specs for M2UA July 2000
"Message Routing towards ASP"
+ TEST NUMBER : 1.9.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.5
+ TITLE : Message Routing
+ SUBTITLE : Message Routing towards ASP
+ PURPOSE: To check that if NIF sends a Data Transfer primitive
containing Protocol DATA to send to the ASP then it is sent to the
correct ASP.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2
and both ASP are Active. Also arrange the data in NIF at SG such that
Data transfer primitive is sent to M2UA at SG with Protocol Data and
interface identifier X.
EXPECTED MESSAGE SEQUENCE :
AS1 AS2 SG NIF
All AS are active
<---------- Data
Interface Id X
<---------------------------- DATA
<---------- Data
Interface Id Y
<---------------------------- DATA
<---------- Data
Interface Id P
<--------------- DATA
TEST DESCRIPTION:
1. Send Data Transfer primitive from NIF in the SG with interface id X.
2. Check A: DATA message will be received at the ASP1.
3. Repeat the above test case for Data Transfer primitive containing
Protocol Data and interface id Y. Data message should be received at
ASP1.
4. Repeat the above test case for Data Transfer primitive containing
Protocol Data and interface id P. Data message should be received at
ASP2.
Sachin-Sunil, HSS [Page 67]
Internet Draft Test Specs for M2UA July 2000
"Routing for DATA not matching any Interface id"
+ TEST NUMBER : 1.9.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.5
+ TITLE : Message Routing
+ SUBTITLE : Routing for DATA not matching any Interface id
+ PURPOSE: To check that if NIF sends a Data Transfer primitive
containing Protocol DATA and interface identifier not defined at the
SG then default routing is given to this message.
+ TEST CONFIGURATION: D
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2
and both ASP are Active. Arrange the data in NIF at SG such that Data
Transfer Primitive is sent to M2UA at SG with Protocol Data with
interface id Z which is not defined at SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG NIF + SM
AS is Active
<----------- Data
Interface Id Z
Error ---------->
TEST DESCRIPTION:
1. Send Data Transfer Primitive from NIF in the SG containing the
Protocol Data and interface id Z.
2. Check A: Error should be returned or some default routing will be
given to this protocol data.
Sachin-Sunil, HSS [Page 68]
Internet Draft Test Specs for M2UA July 2000
"Loadshare Mode of Traffic handling"
+ TEST NUMBER : 1.10.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1
+ 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 sent to the that ASP
in addition to all other ASPs which are handling the traffic.
+ TEST CONFIGURATION: C
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2.
ASP1 is active and ASP2 is Up. Arrange the DATA in AS such that it
sends ASPAC message for ASP2 with Loadshare mode and interface id X
and Y. 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 M-ASP-Stataus ------->
To ASP2 <--------------- NTFY(ASP-Active)
<----------- Data
Interface Id X
To ASP1 <--------------- DATA
<----------- Data
Interface Id Y
To ASP2 <--------------- DATA
ASPIA(ASP1) ---------------->
M-ASP-Stataus ------->
<--------------- NTFY(ASP-Up)
<----------- Data
Interface Id X
To ASP2 <--------------- DATA
<----------- Data
Interface Id Y
To ASP2 <--------------- DATA
Sachin-Sunil, HSS [Page 69]
Internet Draft Test Specs for M2UA July 2000
TEST DESCRIPTION:
1. Send ASPAC message with loadshare mode in type field and interface
id X and Y from AS to SG for ASP2.
2. Check A: SG should send NTFY message with status ASP-Active.
3. Check B: Traffic should also go ASP2 which has sent the ASPAC. Check
this by sending Transfer Ind from NIF at SG containing interface id
X and Y assuming traffic is load shared based on interface id.
Sachin-Sunil, HSS [Page 70]
Internet Draft Test Specs for M2UA July 2000
"Over-ride Mode of Traffic handling"
+ TEST NUMBER : 1.10.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1
+ 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: SG is having SCTP association with ASP1 and ASP2.
ASP1 is active and ASP2 is Up. Arrange the DATA in AS such that it
sends ASPAC message on stream 0 for ASP2 with Override mode and
interface id X and Y. Also mode of traffic handling for AS at SG is
Override.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP1 is Active
ASPAC(ASP2) ---------------->
Override Mode M-ASP-Status ------->
To ASP2 <--------------- NTFY(ASP-Active)
To ASP1 <--------------- NTFY(ASP-Up)
<----------- Data
Interface Id X
To ASP2 <--------------- DATA
<----------- Data
Interface Id Y
To ASP2 <--------------- DATA
TEST DESCRIPTION:
1. Send ASPAC message with override mode in type field and interface
identifier X and Y from AS to SG for ASP2.
2. Check A: SG should send NTFY message with status ASP-Active.
3. Check B: All traffic should also go to ASP2 which has sent the
ASPAC. Check this by sending Data Transfer from NIF at SG containing
interface identifier X and Y. DATA messages will be sent to ASP2.
Sachin-Sunil, HSS [Page 71]
Internet Draft Test Specs for M2UA July 2000
"Loadshare Mode of Traffic handling"
+ TEST NUMBER : 1.11.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1
+ 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: B
+ PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2.
ASP1 and ASP2 are active. Arrange the DATA in AS such that it sends
ASPIA message for ASP2 with Loadshare mode and interface id X and Y.
Also mode of traffic handling for AS at SG is Loadshare.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP1 & ASP2 are Active
ASPIA(ASP2) ---------------->
Loadshare Mode M-ASP-Stataus ------->
To ASP2 <--------------- NTFY(ASP-Up)
<----------- Data
Interface Id X
To ASP1 <--------------- DATA
<----------- Data
Interface Id Y
To ASP1 <--------------- DATA
TEST DESCRIPTION:
1. Send ASPIA message with loadshare mode in type field and interface
identifier X and Y from ASP2 to SG.
2. Check A: NTFY message with status ASP-Up should be received at the
AS.
3. Check B: All traffic should go ASP1. Check this by sending Data
Transfer from NIF at SG with Protocol Data containing interface
identifier X and y.
Sachin-Sunil, HSS [Page 72]
Internet Draft Test Specs for M2UA July 2000
"ERROR Handling"
+ TEST NUMBER : 1.12
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.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
ASP. ASP is active. Arrange data in ASP 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 ------->
DATA ----------------->
Interface id X Data --------->
TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from ASP to SG.
2. Check A: SM should receive error indication.
3. Check B: No other action should be taken at the SG. Check this by
sending DATA message from the ASP with interface identifier X and
Data primitive should be received at NIF at SG.
4. Repeat the test case for other cause values in ERROR message.
Response should be same.
Sachin-Sunil, HSS [Page 73]
Internet Draft Test Specs for M2UA July 2000
"SCTP Connection Establishment"
+ TEST NUMBER : 1.13.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1
+ TITLE : SCTP Connection Management
+ SUBTITLE : SCTP Connection Establishment
+ PURPOSE: To check that on receiving Communication Up primitive from
SCTP, SG M2UA will send M-SCTP-Establish indication to the SM.
+ TEST CONFIGURATION: A
+ PRE-TEST CONDITIONS: SCTP association is not established between SG
and ASP. Arrange the data in ASP such that SCTP association is
established between ASP and SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
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 ------------------>
M-ASP-Status -------->
<----------------- NTFY(ASP-Up)
<----------------- NTFY(AS-Up)
TEST DESCRIPTION:
1. Make an SCTP association between ASP and SG. SG will receive
Communication Up primitive from SCTP.
2. Check A: M-SCTP-Establish indication will be sent to the SM.
3. Send ASPUP message from ASP to SG
4. Check B: NTFY messages with status ASP-Up and AS-Up should be
received at the ASP.
Sachin-Sunil, HSS [Page 74]
Internet Draft Test Specs for M2UA July 2000
"SCTP Connection Termination"
+ TEST NUMBER : 1.13.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1
+ 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
ASP and ASP is active. Arrange for terminating the SCTP association
between ASP and SG.
EXPECTED MESSAGE SEQUENCE :
ASP SG SM + NIF
ASP is active
ASPDN ------------->
M-ASP-Status --------->
<----------------- NTFY(ASP-Down)
<----------------- NTFY(AS-Down/AS-Pending)
SCTP association is terminated
SG will receive Communication-Down primitive from SCTP
M-SCTP Status -------->
<-------- Data
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 data primitive
from the NIF to send some Protocol DATA. SG will report send failure.
Sachin-Sunil, HSS [Page 75]
Internet Draft Test Specs for M2UA July 2000
4.2 Test Cases for Testing M2UA at AS
These test cases are used to test the M2UA at AS.
"Send and Receive of Data Primitive in AS active state"
+ TEST NUMBER : 2.1
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.1.1
+ TITLE : Data Transfer Primitive
+ SUBTITLE : Send and receive of Data Transfer Primitive in AS active
state
+ PURPOSE: To check that on receiving Data primitive from SU, DATA
message is sent to the SG. Also if DFATA message is received the Data
primitive is sent to the SU.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP is in ASP-Active state. Arrange the data in ASP such that SU
sends Data primitive to M2UA with interface identifier X. Also arrange
data in SG such that DATA message with interface identifier X is sent
to ASP.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
ASP is Active
a)
<----------- Data
<------------- DATA Interface Id X
b)
DATA -------------->
Interface Id X Data --------->
TEST DESCRIPTION:
1. Send Data Primitive from the SU at ASP to send Protocol Data to SG.
2. Check A: DATA message is received at ASP with the data passed by the
SU and the interface identifier X.
3. Send DATA message from SG containing Protocol Data and interface
identifier X to the ASP.
4. Check B: Data primitive is received at SU with the Protocol Data and
interface identifier X.
Sachin-Sunil, HSS [Page 76]
Internet Draft Test Specs for M2UA July 2000
"stream Selection"
+ TEST NUMBER : 2.2
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 1.5.3
+ TITLE : Stream Selection
+ SUBTITLE : Stream Selection
+ PURPOSE: To check that all the messages for the same interface
identifier are sent on the same SCTP stream.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP with two streams. ASP is active. Also arrange the data in ASP
such that SU sends three or more Data primitive to M2UA containing
the same interface identifier X.
EXPECTED MESSAGE SEQUENCE :
SG ASP SU
AS is active
<--------- Data
Check Stream id <------------- DATA Interface Id X
<--------- Data
Check Stream id <------------- DATA Interface Id X
<--------- Data
Check Stream id <------------- DATA Interface Id X
<--------- Data
Check Stream id <------------- DATA Interface Id Y
TEST DESCRIPTION:
1. Send three or more data Primitive from the SU at SG side to send
Protocol Data to the SG with interface id X.
2. Check A: DATA messages are sent to the SG containing the same Stream
Sequence number.
3. Send data primitive with interface identifier Y.
4. Check B: DATA messages should be received on the other stream.
5. Repeat the above case if number of streams between AS and SG is more
than two but AS is handling only two interface identifiers. One or
more stream may not be used for sending DATA message.
6. Repeat the above case if number of streams between AS and SG is two
but AS is handling four interface identifiers. Send data primitives
for all interface identifiers. DATA messages should be sent on both
the streams and DATA messages for the same interface identifier are
sent on the same stream.
Note: How the message will be distributed on different streams is
implementation specific.
Sachin-Sunil, HSS [Page 77]
Internet Draft Test Specs for M2UA July 2000
"SCTP Connection Establishment"
+ TEST NUMBER : 2.3.1
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.2.1
+ 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: E
+ 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 M2UA 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 78]
Internet Draft Test Specs for M2UA July 2000
"SCTP Connection Termination"
+ TEST NUMBER : 2.3.2
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.2.1
+ 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 SM.
+ TEST CONFIGURATION: E
+ 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 -------->
<-------- Data
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 Transfer primitive from the
SU to send some Protocol DATA. ASP will report send failure.
Note: It is possible that SCTP connection is terminated without
exchanging the ASPDN message.
Sachin-Sunil, HSS [Page 79]
Internet Draft Test Specs for M2UA July 2000
"NTFY message is not received in response to ASPUP message"
+ TEST NUMBER : 2.4.1
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2
+ 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 time will report the SM.
+ TEST CONFIGURATION: E
+ 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 M2UA. Arrange data in SG such that NTFY message is not sent in
response to the ASPUP message.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<----------- ASP-Up
<------------ ASPUP
|
|time t1
<------------ ASPUP
|
|time t1
<------------ ASPUP
.
.
. n tries
.
M-ASP-Status ---------->
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. Value of time t1 and n is
also implementation dependent.
Sachin-Sunil, HSS [Page 80]
Internet Draft Test Specs for M2UA July 2000
"NTFY message with status ASP-Down is received in response to ASPUP
message"
+ TEST NUMBER : 2.4.2
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2
+ 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: E
+ 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 M2UA. 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 81]
Internet Draft Test Specs for M2UA July 2000
"ASP Management messages towards SG"
+ TEST NUMBER : 2.4.3
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3
+ 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: E
+ 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) ------------>
M-ASP-Status --------->
<--------- ASP-Down
<----------- ASPDN
NTFY(ASP-Down) ------------>
M-ASP-Status --------->
<--------- ASP-Up
<----------- ASPUP
NTFY(ASP-Up) ------------>
M-ASP-Status --------->
<--------- ASP-Active
<----------- ASPAC
NTFY(ASP-Active)------------>
M-ASP-Status --------->
TEST DESCRIPTION:
1. Send ASP-Inactive Primitive from SM in ASP to M2UA.
2. Check A: ASPUP message will be received at the SG. Send NTFY(ASP-Up)
in response to the ASPUP message.
3. Check B: ASPM messages are received on stream 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.
5. Repeat the above test case if NTFY message is sent on stream other
than 0.
Sachin-Sunil, HSS [Page 82]
Internet Draft Test Specs for M2UA July 2000
"NTFY message with interface ID less than present in ASPAC message sent
is received in response to ASPAC message"
+ TEST NUMBER : 2.4.4
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2
+ TITLE : AS management
+ SUBTITLE : NTFY message with interface ID less than present in ASPAC
message sent is received in response to ASPAC message
+ PURPOSE: To check that if NTFY message with interface Id less than
those present in ASPAC message is received in response to the ASPAC
message then ASP is marked active only for those interface ids.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Up. Also arrange the data in ASP such that SM sends
ASP Active primitive to the M2UA with interface id X and Y. Arrange
data in SG such that NTFY message is sent in response to the ASPAC
message with interface id X.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<--------- ASP-Active
Interface id X and Y
<----------- ASPAC
NTFY(ASP-Active)------------>
interface Id X
M-ASP-Status --------->
<--------- Data
interface Id X
<----------- DATA
<--------- Data
interface Id Y
Send Failure --------->
TEST DESCRIPTION:
1. Send ASP-Active primitive from SM at ASP with interface id X and Y.
ASP will send ASPAC message to the SG with interface id X and Y.
Send NTFY message from the SG with interface id X.
2. Check A: Status Indication should be received at the SM.
3. Check B: Status of ASP will be active only for the interface id X
and not for Y.
Note: This case is implementation specific. In some implementation
there may not be interface identifier parameter present in NTFY
message. In those implementation, this test case need not be run.
Sachin-Sunil, HSS [Page 83]
Internet Draft Test Specs for M2UA July 2000
"NTFY message with interface ID less than present in ASPIA message sent
is received in response to ASPIA message"
+ TEST NUMBER : 2.4.5
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2
+ TITLE : AS management
+ SUBTITLE : NTFY message with interface ID less than present in ASPIA
message sent is received in response to ASPAC message
+ PURPOSE: To check that if NTFY message with interface Id less than
those present in ASPAC message is received in response to the ASPIA
message then ASP is marked Up only for those interface ids.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Also arrange the data in ASP such that SM sends
ASP inactive primitive to the M2UA with interface id X and Y. Arrange
data in SG such that NTFY message is sent in response to the ASPIA
message with interface id X.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
<--------- ASP-Inactive
Interface id X and Y
<----------- ASPIA
NTFY(ASP-Up) ------------>
interface Id Y
M-ASP-Status --------->
<--------- Data
interface Id X
<----------- DATA
<--------- Data
interface Id Y
Send Failure --------->
TEST DESCRIPTION:
1. Send ASP-Inactive primitive from SM at ASP with interface id X and Y.
ASP will send ASPIA message to the SG with interface id X and Y.
Send NTFY message from the SG with interface id Y.
2. Check A: Status Indication should be received at the SM.
3. Check B: Status of ASP will be Up only for the interface id Y and
not for X.
Note: This case is implementation specific. In some implementation
there may not be interface identifier parameter present in NTFY message.
In those implementation, this test case need not be run.
Sachin-Sunil, HSS [Page 84]
Internet Draft Test Specs for M2UA July 2000
"Invalid Version Error"
+ TEST NUMBER : 2.5.1
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1 and 3.3.3.3
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Version Error
+ PURPOSE: To check that if any message with Invalid version is
received at the ASP then ASP responds with ERROR message containing
cause "Invalid Version" and diagnostic information filled with the
version the SG supports.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Also arrange the data in SG such that DATA
message with version other than release 1.0 is sent to the ASP.
Interface identifier in DATA message is X.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
DATA --------------->
Version = 2
<-------------- ERROR
Cause = Invalid Version
TEST DESCRIPTION:
1. Send DATA 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 Field Parameter in ERROR is filled with version
1.
4. Repeat the above test cases for other messages from SG to ASP like
ESTABLISH CONFIRM, RELEASE CONFIRM, RELEASE INDICATION, STATE
CONFIRM, STATE INDICATION, DATA RETRIEVAL CONFIRM, DATA RETRIEVAL
INDICATION and DATA RETRIEVAL COMPLETE INDICATION.
Sachin-Sunil, HSS [Page 85]
Internet Draft Test Specs for M2UA July 2000
"Unrecognised Message Type"
+ TEST NUMBER : 2.5.2
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.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: E
+ 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 --------------->
Interface Id X
Data --------->
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 86]
Internet Draft Test Specs for M2UA July 2000
"Invalid Interface identifier"
+ TEST NUMBER : 2.5.3
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.2 and 2.3.3.1
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid interface identifier
+ PURPOSE: To check that if a message with invalid interface identifier
i.e. ASP does not handle traffic for that interface identifier then
AS responds with ERROR message containing cause "Invalid interface
identifier".
+ TEST CONFIGURATION: E
+ 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 interface identifier is sent to ASP.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
DATA --------------->
Interface Id P
<-------------- ERROR
Cause = Invalid Interface Identifier
DATA --------------->
Interface Id X
Data --------->
TEST DESCRIPTION:
1. Send DATA message to the ASP with interface identifier which ASP
doesn't handle.
2. Check A: AS will respond with ERROR message containing cause Invalid
interface identifier.
3. Check B: State of ASP at AS is not disturbed.
4. Repeat the above test case for other messages like ESTABLISH
CONFIRM, RELEASE CONFIRM, RELEASE INDICATION, STATE CONFIRM, STATE
INDICATION, DATA RETRIEVAL CONFIRM, DATA RETRIEVAL INDICATION and
DATA RETRIEVAL COMPLETE INDICATION.
Sachin-Sunil, HSS [Page 87]
Internet Draft Test Specs for M2UA July 2000
"Invalid Reason parameter in RELEASE CONFIRM and INDICATION message"
+ TEST NUMBER : 2.5.4
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE: Invalid Reason parameter in RELEASE CONFIRM and INDICATION
message
+ PURPOSE: To check that if RELEASE CONFIRM and INDICATION messages
with Invalid Reason parameter is received then it is reported to the
upper layer.
+ TEST CONFIGURATION: E
+ 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
RELEASE CONFIRM ------------->
Reason = 0xA
Release Confirm -------->
TEST DESCRIPTION:
1. Send RELEASE CONFIRM message with Reason parameter not defined i.e.
value greater than 0x9.
2. Check A: Release primitive should be received at the SU.
3. Repeat the test case for RELEASE INDICATION message from SG to ASP
with invalid value of Reason parameter. Release indication primitive
will be received at the SU.
Sachin-Sunil, HSS [Page 88]
Internet Draft Test Specs for M2UA July 2000
"Invalid State Parameter in STATE CONFIRM message"
+ TEST NUMBER : 2.5.5
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid State Parameter in STATE CONFIRM message
+ PURPOSE: To check that if STATE CONFIRM message is received with
invalid value of State parameter then ASP discards the STATE CONFIRM
message.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that STATE CONFIRM
message with interface identifier X and invalid value of State
parameter is sent to SG.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<------ State Request
<------------ STATE REQUEST
STATE CONFIRM ------------->
State = 0x6
DATA ------------->
Interface Id X
Data ------->
TEST DESCRIPTION:
1. Send STATE REQUEST message with state value 0x5 to the SG. Send
state confirm message with state 0x6 in response to this message
from SG.
2. Check A: STATE CONFIRM message will be discarded and no message will
be received at SG.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case if STATE INDICATION message is sent from
SG to ASP with state parameter greater than 0xf.
Sachin-Sunil, HSS [Page 89]
Internet Draft Test Specs for M2UA July 2000
"Invalid Action Parameter in RETRIEVAL CONFIRM message"
+ TEST NUMBER : 2.5.6
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Invalid Action Parameter in RETRIEVAL CONFIRM message
+ PURPOSE: To check that if RETRIEVAL CONFIRM message is received with
invalid value of Action parameter then ASP discards the message.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that RETRIEVAL
CONFIRM message with interface identifier and invalid value of Action
parameter is sent to SG. Fsn_bsn parameter may be having any value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<------ Retrieval Request
<------------ RETRIEVAL REQUEST
RETRIEVAL CONFIRM ------------->
Action = 0x4
DATA ------------->
Interface Id X
Data ------->
TEST DESCRIPTION:
1. Send RETRIEVAL REQUEST message with action value 0x1 from ASP to SG.
Send RETRIEVAL CONFIRM message with action 0x4 in response to this
message from SG to ASP.
2. Check A: RETRIEVAL CONFIRM message will be discarded and no message
will be received at the ASP.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for invalid value of fsn_bsn field like
-2 etc. Response should be same.
Sachin-Sunil, HSS [Page 90]
Internet Draft Test Specs for M2UA July 2000
"ERROR message with invalid error code"
+ TEST NUMBER : 2.5.7
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : ERROR message with invalid error code
+ PURPOSE: To check that if ERROR message with Invalid Error code
parameter is received then M2UA at ASP doesn't take any action but
discard the message.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and AS is Active. Arrange the data in SG such that ERROR message
with invalid error code parameter( error code > 0x6) is sent to the
ASP.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<------ State Request
<------------ STATE REQUEST
ERROR ------------->
Error Code = 0x6
TEST DESCRIPTION:
1. Send STATE REQUEST message from ASP to the SG. In response to this
message, send ERROR message with error code greater than or equal to
0x6 from SG to the ASP.
2. Check A: Error will be reported to the SM.
3. Further actions are implementation dependent. Implementation may
close the association in this case.
Sachin-Sunil, HSS [Page 91]
Internet Draft Test Specs for M2UA July 2000
"Message length less than the length of mandatory Parameters"
+ TEST NUMBER : 2.5.8
+ Reference: draft-ietf-sigtran-m2ua-03.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: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that RELEASE
INDICATION message is sent to ASP with length parameter filled with
value equal to the length of M2UA message header only.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
RELEASE INDICATION ------------->
DATA ------------->
Interface Id X
Data ------->
TEST DESCRIPTION:
1. Send RELEASE INDICATION message with length parameter filled with
value equal to the length of M2UA message header only.
2. Check A: RELEASE INDICATION message will be discarded and no message
will be received at the ASP.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for other messages like STATE INDICATION,
RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, RELEASE
CONFIRMATION and RELEASE INDICATION.
Sachin-Sunil, HSS [Page 92]
Internet Draft Test Specs for M2UA July 2000
"Interface Identifier not present in MAUP messages"
+ TEST NUMBER : 2.5.9
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Interface Identifier not present in MAUP messages
+ PURPOSE: To check that if a MAUP message without Interface Identifier
is sent to ASP then ASP responds with ERROR message with cause
"Invalid Interface id'.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that RELEASE
INDICATION message without Interface Identifier (Tag 0x1 is not there
after common header) is sent to ASP. Reason parameter is having valid
value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
RELEASE INDICATION ------------->
<------------- ERROR
Invalid Interface Id
DATA ------------->
Interface Id X
Data ------->
TEST DESCRIPTION:
1. Send RELEASE INDICATION message without interface identifier to the
ASP.
2. Check A: RELEASE INDICATION message will be discarded and SG will
receive ERROR message with cause Invalid Interface Id.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for other messages like STATE INDICATION,
RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, RELEASE
CONFIRMATION and RELEASE INDICATION.
Note: A new Cause value may be added in the ERROR message.
Sachin-Sunil, HSS [Page 93]
Internet Draft Test Specs for M2UA July 2000
"Length of Interface Identifier parameter in M2UA message header is
other than four"
+ TEST NUMBER : 2.5.10
+ Reference: draft-ietf-sigtran-m2ua-03.txt
+ TITLE : Invalid Message Handling
+ SUBTITLE : Length of Interface Identifier parameter in M2UA message
header is other than 4
+ PURPOSE: To check that if a MAUP message with length field in M2UA
message header less than four is sent to ASP then ASP responds with
ERROR message with cause "Invalid Interface Id".
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in SG such that RELEASE
INDICATION message with length in M2UA message header less than four
is sent to ASP. Reason parameter is having the value RELEASE_MGMT.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
RELEASE INDICATION ------------->
Length in M2UA Header = 3
<------------- ERROR
Invalid Interface Id
DATA ------------->
Interface Id X
Data ------->
TEST DESCRIPTION:
1. Send RELEASE INDICATION message with length in M2UA message header
less than four to the ASP.
2. Check A: RELEASE INDICATION message will be discarded and ERROR
message will be received at the ASP with cause Invalid Interface Id.
3. Check B: State of ASP is not disturbed.
4. Repeat the above test case for other messages like STATE INDICATION,
RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, RELEASE
CONFIRMATION and RELEASE INDICATION.
Sachin-Sunil, HSS [Page 94]
Internet Draft Test Specs for M2UA July 2000
"Link Establish and Release Confirmation"
+ TEST NUMBER : 2.6.1
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1
+ TITLE : Link management
+ SUBTITLE : Link Establish and Release Confirmation
+ PURPOSE: To check that if Establish request is received from SU at
ASP then ESTABLISH REQUEST message is sent to ASP and if Establish
Confirmation is received from SG then SU is indicated that establish
indication has been received.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data at SG such that ESTABLISH
CONFIRMATION and RELEASE CONFIRMATION messages are sent to the SG
with the interface identifier X. Reason Parameter in the RELEASE
CONFIRMATION message should be Release_Mgmt.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
a)
<----------- Establish request
<----------- ESTABLISH REQUEST
ESTABLISH CONFIRMATION ------------->
Establish Confirm -------->
b)
<----------- Release request
<----------- RELEASE REQUEST
Reason = Release_Mgmt
RELEASE CONFIRMATION ------------->
Release Confirm -------->
TEST DESCRIPTION:
1. Send Establish request primitive from the SU at the ASP to M2UA.
2. Check A: ESTABLISH REQUEST message should be received at the SG.
Send ESTABLISH CONFIRMATION message to the ASP in response to the
received message with interface identifier X.
3. Check B: Establish confirmation indication should be received at the
SU.
4. Repeat the above test case for Release Request primitive from SU at
ASP to M2UA. RELASE REQUEST message should be received at SG. Send
RELEASE CONFIRMATION message in response to the received message.
Release Confirmation indication should be sent to the SU with the
reason received in RELEASE CONFIRMATION message.
Sachin-Sunil, HSS [Page 95]
Internet Draft Test Specs for M2UA July 2000
"Release Indication message"
+ TEST NUMBER : 2.6.2
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1
+ TITLE : Link management
+ SUBTITLE: Release Indication message
+ PURPOSE: To check that if RELEASE INDICATION message is received at
ASP then SU is reported of it.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data at SG such that RELEASE
INDICATION messages are sent to the ASP with the interface identifier
X. Reason Parameter in the RELEASE INDICATION message can be any
valid value.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
RELEASE INDICATION ------------->
Release Ind -------->
TEST DESCRIPTION:
1. Send RELEASE INDICATION message from SG to ASP with interface
identifier X.
2. Check A: Release ind primitive will be received at the SU with the
reason received in the message.
Sachin-Sunil, HSS [Page 96]
Internet Draft Test Specs for M2UA July 2000
"STATE REQUEST and CONFIRMATION message"
+ TEST NUMBER : 2.6.3
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 and 2.3.1.4
+ TITLE : Link management
+ SUBTITLE : STATE REQUEST and CONFIRMATION message
+ PURPOSE: To check that if State request primitive is received from SU
at ASP then STATE REQUEST message is sent from ASP to the SG with
state received from SU and if STATE CONFIRM message is received from
SG then SU is indicated of that.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that State
Request primitive is sent to M2UA from SU at ASP with state
Status_Emer_Set. STATE CONFIRM Message is sent from SG to the ASP
with Interface identifier X and State parameter Status_Emer_Set.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
a)
<----------- State request
Status_Emer_Set
<----------- STATE REQUEST
STATE CONFIRM ------------->
State Confirm -------->
b)
STATE INDICATION ------------->
State Indication-------->
TEST DESCRIPTION:
1. Send State request primitive from the SU at the ASP to M2UA.
2. Check A: STATE REQUEST message should be received at the SG. Send
STATE CONFIRM message to the ASP in response to the received message
with interface identifier X.
3. Check B: State confirmation indication should be received at the SU.
4. Repeat the above test case for STATE INDICATION message from SG to
ASP. State Indication should be received at the SU with the state
received in STATE INDICATION message.
Sachin-Sunil, HSS [Page 97]
Internet Draft Test Specs for M2UA July 2000
"Retrieval Request and Confirm"
+ TEST NUMBER : 2.6.4
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.1 and 2.3.1.6
+ TITLE : Link management
+ SUBTITLE : Retrieval Request and Confirm
+ PURPOSE: To check that if Retrieval request primitive is received
from SU at ASP with interface identifier and action Action_Rtrv_BSN
then RETRIEVAL REQUEST message is sent to SG and if RETRIEVAL CONFIRM
message is received from SG the SU is indicated of that.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that Retrieval
Request primitive is sent to M2UA from SU at ASP with action
Action_Rtrv_BSN. Also RETRIEVAL CONFIRM message is sent from SG to
the ASP with Interface identifier X and action parameter
Action_Rtrv_BSN.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<----------- Retrieval Request
Action_Rtrv_BSN
<------------ RETRIEVAL REQUEST
RETRIEVAL CONFIRM ------------->
Action_Rtrv_BSN Retrieval Confirm -------->
TEST DESCRIPTION:
1. Send Retrieval Request primitive from SU at ASP with action
Action_Rtrv_BSN and interface identifier X.
2. Check A: RETRIEVAL REQUEST message will be received at SG with
action Action_Rtrv_BSN.
3. Send RETRIEVAL CONFIRM message from SG to ASP with action
Action_Rtrv_BSN from SG to ASP and fsn_bsn field any value.
4. Check B: Retrieval confirm primitive will be received at SU.
5. Repeat the above test case for different valid values of action
Parameter.
Sachin-Sunil, HSS [Page 98]
Internet Draft Test Specs for M2UA July 2000
"Retrieval Indication and Retrieval Complete Indication "
+ TEST NUMBER : 2.6.5
+ Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.1 and 2.3.1.7
+ TITLE : Link management
+ SUBTITLE : Retrieval Indication and Retrieval Complete Indication
+ PURPOSE: To check that if RETRIEVAL INDICATION and RETRIEVAL COMPLETE
INDICATION messages are received from SG then SU are indicated of
that.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that Retrieval
Request primitive is sent to M2UA from SU at ASP with action
Action_Rtrv_MSGS. Also RETRIEVAL CONFIRM, RETRIEVAL INDICATION and
RETRIEVAL COMPLETE INDICATION messages are sent from SG to the ASP
with Interface identifier X .
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<----------- Retrieval Request
Action_Rtrv_Msgs
<------------ RETRIEVAL REQUEST
RETRIEVAL CONFIRM ------------->
Action_Rtrv_Msgs Retrieval Confirm -------->
RETRIEVAL INDICATION ------------>
Retrieval Indication-------->
RETRIEVAL COMPLETE ------------>
INDICATION Retrieval Complete Ind-------->
TEST DESCRIPTION:
1. Send Retrieval Request primitive from SU at ASP with action
Action_Rtrv_Msgs and interface identifier X. RETRIEVAL REQUEST
message will be received at SG.
2. Send RETRIEVAL CONFIRM, RETRIEVAL INDICATION and RETRIEVAL COMPLETE
INDICATION messages from SG to ASP with interface id X.
3. Check B: Retrieval indication and retrieval complete indication
primitive will be received at SU.
Sachin-Sunil, HSS [Page 99]
Internet Draft Test Specs for M2UA July 2000
"NTFY(ASP-Up) is received in response to ASPDN message"
+ TEST NUMBER : 2.7.1
+ Reference: draft-ietf-sigtran-m2ua-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: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Up. Arrange the data in SG such that NTFY (ASP-Up)
is sent to the ASP in response to ASPDN message with interface
identifier X.
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 100]
Internet Draft Test Specs for M2UA July 2000
"NTFY(ASP-Active) is received in response to ASPIA message"
+ TEST NUMBER : 2.7.2
+ Reference: draft-ietf-sigtran-m2ua-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: E
+ 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 interface identifier X is sent to ASP in response
to ASPIA message.
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 101]
Internet Draft Test Specs for M2UA July 2000
"DATA message from SG in ASP-Down state"
+ TEST NUMBER : 2.8
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ TITLE : DATA message in ASP-Down State
+ SUBTITLE : DATA message from SG in ASP-Down state
+ PURPOSE: To check that if DATA message is received in ASP-Down state
then it is discarded.
+ TEST CONFIGURATION: E
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP and ASP is Active. Arrange the data in ASP such that ASP inactive
and ASP down primitives are sent from SM to M2UA. Also arrange data
at SG such that NTFY and DATA message with interface identifier X and
Y is sent to the SG.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is active
<--------- ASP-Inactive
<----------- ASPIA
NTFY(ASP-Up) ------------>
M-ASP-Status -------->
<--------- ASP-Dowm
<----------- ASPDN
NTFY(ASP-Down) ------------>
M-ASP-Status -------->
DATA ------------>
Interface Id X
Error --------->
<----------- ASPDN
TEST DESCRIPTION:
1. Send ASP-Inactive primitive from SM to M2Ua at ASP. ASPIA message
will be received at SG. Send NTFY(ASP-Up) message to the ASP. Send
ASP-Down primitive from SM to the M2UA at ASP. ASPDN message will be
received at SG. Send NTFY(ASP-Down) in response to the ASP.
2. Send DATA message from the SG with interface identifier X.
3. Check A: DATA message should be discarded and ASPDN message should
be sent to SG.
Sachin-Sunil, HSS [Page 102]
Internet Draft Test Specs for M2UA July 2000
"ERROR Handling"
+ TEST NUMBER : 2.9
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ 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: E
+ 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
<------- Release Req
<--------------- RELEASE REQUEST
ERROR --------------->
Cause = invalid version Error -------->
TEST DESCRIPTION:
1. Send ERROR message with cause invalid version from SG to ASP.
2. Check A: AS should report the error to its SM.
3. Check B: Further actions at the SG are implementation specific.
4. Repeat the test case for other cause values in ERROR message.
Sachin-Sunil, HSS [Page 103]
Internet Draft Test Specs for M2UA July 2000
"ASP in more than one AS"
+ TEST NUMBER : 2.10
+ Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.4
+ TITLE : ASP TEST 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 interface identifiers are sent.
+ TEST CONFIGURATION: F
+ PRE-TEST CONDITIONS: SCTP association is established between SG and
ASP. ASP has been configured to handle traffic for interface
identifier X, Y, P and Q. ASP is active. Arrange data in ASP such
that ASP-Active is sent from SM with the list of AS or interface
identifiers ASP is configured for.
EXPECTED MESSAGE SEQUENCE :
SG ASP SM
ASP is Down
<--------- ASP-Up
<----------- ASPUP
NTFY(ASP-Up) ------------>
M-ASP-Status -------->
<--------- ASP-Active
<----------- ASPAC
Interface Id X,Y,P,Q
NTFY(ASP-Active) ------------>
M-ASP-Status -------->
<--------- ASP-inactive
<----------- ASPIA
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 interface
identifier P, Q, X and Y.
3. Repeat the above test case for ASP-Inactive primitive from SM. ASPIA
message should be sent to SG containing all interface identifier.
Sachin-Sunil, HSS [Page 104]
Internet Draft Test Specs for M2UA July 2000
"ASP in more than one SG"
+ TEST NUMBER : 2.11
+ Reference: draft-ietf-sigtran-m2ua-02.txt
+ TITLE : ASP TEST 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 SG then message are routed correctly among
the two SG
+ TEST CONFIGURATION: G
+ PRE-TEST CONDITIONS: ASP is having SCTP association with SG1 and SG2.
ASP is down. Arrange data in SM at ASP such that ASP-Up and
ASP-Active primitives are sent to M2UA for SG1 and SG2. Also Arrange
data in SG1 and SG2 such that NTFY messages are sent to ASP.
EXPECTED MESSAGE SEQUENCE :
SG1 SG2 ASP SM + SU
ASP is Down
<------- ASP-Up(for SG1)
<-------------------------- ASPUP
NTFY(ASP-Up) --------------->
M-ASP-Status ------->
<------- ASP-Up(for SG2)
<---------------- ASPUP
NTFY(ASP-Up) -------->
M-ASP-Status ------->
<------- ASP-Active(for SG1)
<-------------------------- ASPAC
NTFY(ASP-Active) --------------->
M-ASP-Status ------->
<------- ASP-Active(for SG2)
<---------------- ASPAC
NTFY(ASP-Active)------->
M-ASP-Status ------->
<------- Data
Sachin-Sunil, HSS [Page 105]
Internet Draft Test Specs for M2UA July 2000
<--------------------------- DATA SG1 and Interface id X
<------- Data
<------------- DATA SG2 and Interface id X
TEST DESCRIPTION:
1. Send ASP-Up primitive from SM to ASP for SG1 and SG2.
2. Check A: ASPUP message will be sent from ASP to SG1 and SG2. Send
NTFY (ASP-Up) from the SG1 and SG2. Now send ASP-Active primitive
from SM for SG1 and SG2.
3. Check B: ASPAC message is received at the SG1 and SG2.
4. Send Data primitive from SU to send data to SG1.
5. Check C: DATA message will be received at SG1.
6. Repeat the test set 5 to send data to SG2.
Sachin-Sunil, HSS [Page 106]
Internet Draft Test Specs for M2UA July 2000
5. Acknowledgement
Authors are highly grateful to Mukesh and Kuldeep 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] Ken Morneault, Mallesh Kalla, G. Sidebottom, Ram Dantu, Tom George,
SS7 MTP2-User Adaptation Layer (M2UA)
<draft-ietf-sigtran-m2ua-03.txt>
Sachin-Sunil, HSS [Page 107]
| ||||||||||||||||
| Last modified: Fri, 14 Nov 2014 10:14:09 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||