| draft-hss-sigtran-sua-conformance08Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-hss-sigtran-sua-conformance08.txt.
INTERNET-DRAFT Dipak Aggarwal (Editor)
Internet Engineering Task Force Hughes Software Systems (HSS)
Issued: 2 November 2001
Expires: 2 May 2002
SS7 SCCP-User Adaptation Layer (SUA) Conformance Test plan
<Draft-hss-sigtran-sua08-conformance.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as 'work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This draft expires on 2 may 2002.
diaggarwal(editor) [Page 1]
Internet Draft SUA Conformance Test Plan [Page 2]
Abstract
The SUA is a protocol for the transport of any SS7 SCCP user
Signaling (e.g. TCAP, RANAP or RNSAP messages) over IP
Between two signaling endpoints. This protocol can also support
Transport of SCCP-user messages between two endpoints wholly
Contained within an IP network. Depending upon the upper layer
Protocol supported, the SUA will need to support SCCP
Connectionless service, SCCP connect-oriented service or
Both services.
Abstract.............................................................2
1. Introduction......................................................3
1.1 Scope...........................................................3
1.2 Terminology.....................................................3
2 General Principles of SUA Tests....................................6
2.1 Presentation of test descriptions...............................6
3 Test Configurations................................................7
3.1 Network Setups..................................................7
4 Test Cases........................................................12
4.1 Test cases for Testing of Connectionless Procedures............12
4.2 Test Cases for Testing of Connection-Oriented Messages.........23
4.3 Segmentation And Re-Assembly...................................57
4.4 Routing Procedures.............................................65
4.5 Relay node Functionality.......................................78
4.6 Timer validation...............................................80
4.7 ASPM Procedures................................................85
5 Acknowledgements.................................................124
6 Authors' Addresses...............................................124
7 References.......................................................124
Copyright Statement................................................125
diaggarwal(editor) [Page 2]
Internet Draft SUA Conformance Test Plan [Page 3]
1. Introduction
1.1 Scope
There is on-going integration of SCN networks and IP networks.
Network service providers are designing all IP architectures that
include support for SS7 and SS7-like signaling protocols. IP
provides an effective way to transport user data and for operators
to expand their networks and build new services. In these networks,
there may be some need for interworking between the SS7 and IP
domains.
This document details the Conformance of the SUA( SCCP User Adaptation
Layer) Protocol as per <draft-ietf-sigtran-sua-08.txt>
1.2 Terms Used
Signaling Gateway (SG) - Network element that terminates SCN
Signaling and transports SCCP-User signaling over IP to an IP
Signaling endpoint. A Signaling Gateway could be modeled as one
Or more Signaling Gateway Processes, which are located at the
Border of the SS7 and IP networks. Where an SG contains more than
one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7
network and to the supported Application Servers.
Application Server (AS) - A logical entity serving a specific
Routing Key. An example of an Application Server is a virtual IP
Database element handling all requests for an SCCP-user. The AS
Contains a set of one or more unique Application Server Processes,
Of which one or more is normally actively processing traffic.
Application Server Process (ASP) - An Application Server Process
Serves as an active or backup process of an Application Server
(e.g., part of a distributed signaling node or database element).
Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs. An ASP
Contains an SCTP end-point and may be configured to process traffic
Within more than one Application Server.
IP Server Process (IPSP) - A process instance of an IP-based
Application. An IPSP is essentially the same as an ASP, except that
It uses SUA in a peer-to-peer fashion. Conceptually, an IPSP does
Not use the services of a Signaling Gateway.
Signaling Gateway Process (SGP) - A process instance of a
Signaling Gateway. It serves as an active, load-sharing or
Broadcast process of a Signaling Gateway.
diaggarwal(editor) [Page 3]
Internet Draft SUA Conformance Test Plan [Page 4]
Signaling Process - A process instance that uses SUA to communicate
With other signaling process. An ASP, a SGP and an IPSP are all
Signaling processes.
Association - An association refers to an SCTP association. The
Association provides the transport for the delivery of SCCP-User
Protocol data units and SUA layer peer messages.
Routing Key - The Routing Key describes a set of SS7 parameters
And/or parameter-ranges that uniquely defines the range of
Signaling traffic configured to be handled by a particular
Application Server. An example would be where a Routing Key consists
Of a particular SS7 SCCP SSN plus an identifier to uniquely mark the
Network that the SSN belongs to, for which all traffic would be
Directed to a particular Application Server. Routing Keys are
Mutually exclusive in the sense that a received SS7 signaling
Message cannot be directed to more than one Routing Key. Routing
Keys can be provisioned, for example, by a MIB or registered using
SUA's dynamic registration procedures.
Routing Context - An Application Server Process may be configured to
Process traffic within more than one Application Server. In this
Case, the Routing Context parameter is exchanged between the SGP and
The ASP (or between two ASPs), identifying the relevant Application
Server. From the perspective of an SGP/ASP, the Routing Context
Uniquely identifies the range of traffic associated with a
Particular Application Server, which the ASP is configured to
Receive. There is a 1:1 relationship between a Routing Context values
And a Routing Key within an AS. Therefore the Routing Context can
Be viewed as an index into an AS Table containing the AS Routing
Keys. The Routing Context also uniquely identifies an SS7 entity
(Point code) into a SS7 network, as presented by the SGP.
Address Mapping Function (AMF) - The AMF is an implementation
Dependent function that is responsible for resolving the address
Presented in the incoming SCCP/SUA message to correct SCTP
Association for the desired endpoint. The AMF MAY use routing
Context / rouging key information as selection criteria for the
Appropriate 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-over may apply upon the return to service of a previously
Unavailable Application Server Process.
Network Byte Order - Most significant byte first, a.k.a. Big Endian.
diaggarwal(editor) [Page 4]
Internet Draft SUA Conformance Test Plan [Page 5]
Layer Management - Layer Management is a nodal function that handles
The inputs and outputs between the SUA layer and a local management
Entity.
Host - The computing platform that the SGP or ASP process is running
On.
Stream - A stream refers to an SCTP stream; a uni-directional
Logical channel established from one SCTP endpoint to another
Associated SCTP endpoint, within which all user messages are
Delivered in-sequence except for those submitted to the un-ordered
Delivery service.
Transport address - an address that serves as a source or
Destination for the unreliable packet transport service used by
SCTP. In IP networks, a transport address is defined by the
Combination of an IP address and an SCTP port number. Note, only
One SCTP port may be defined for each endpoint, but each SCTP
Endpoint may have multiple IP addresses.
diaggarwal(editor) [Page 5]
Internet Draft SUA Conformance Test Plan [Page 6]
2 General Principles of SUA Tests
These tests aim to verify a given implementation of a protocol in
Accordance with the relevant draft. The specification is independent of
A given implementation and does not generally imply any modification of
The endpoint under test. However, it is recognized that certain tests
Require capabilities of the system that are not explicitly defined in
The draft, and these capabilities may not be present in all
Implementations. As a consequence, certain tests may not be possible in
All implementations.
2.1 Presentation of test descriptions
Each test description includes the environment in which the point under
Test must be inserted in order to pass the test. Nine test
Configurations are defined (named A, B, C, D, E, F, G, H and I); they
Are presented in clause 3.
Each test is precisely described. Nevertheless, some events not
Directly concerning the point under test, or without direct link with
The test nature, are not explicitly described. In order to preserve the
Test description implementation independence, certain flexibility has
Been left in the test descriptions. This is particularly the case when
It is necessary to terminate the SCTP association (where it is only
Mentioned, "Terminate" with no more precision). The operator will choose
According to the implementation particularities and the events expected
In the test description, the appropriate Termination means (MML- Man
Machine Language, provoked failure, etc.).
2.1.1 Pre Test Condition
Before starting the test we need to get the setup into a condition from
Where test can be started. These conditions are specified in Pre-Test
Condition in each test.
Note: Routing Context and Routing Key has been used inter exchangably.
In case of message it is Routing Context and in the test configuration
It is Routing Key.
Note: Where NIF has been written, it means that NIF+SM. In some
Implementation these may be two entities and in some, they may be
Implemented in single entity.
diaggarwal(editor) [Page 6]
Internet Draft SUA Conformance Test Plan [Page 7]
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 Network Setups:
There are different Network setups under which the listed test
cases may be executed. The user may choose between any one of
them, or may wish to execute the cases in all the listed
Network Setups.
3.1.1 Configuration A: For Testing the IUT at SGP/IPSP
Configuration A.1 :
This simple configuration is used for all the procedures of tests
Concerning only one AS. Configuration A is shown in figure 1.
AS is Handling the traffic for routing context P and N/w
Appearance A. AS is Having only one ASP ASP1.Point Code of SGP
is Z. Routing Context P may Be based on the
following information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. Hostname.
------------- --------------
| SGP/IPSP | | AS DPC = X |
| under Test | | ------- |
| DPC = Z |-------------------------------|--| ASP1 | |
| | | ------- |
------------- --------------
Fig 1: Configuration A
Configuration A.2 :
This configuration is used for all the procedures of tests concerning
one ASP in two AS which are handling traffic for both AS. Configuration
B is shown in figure 2. AS1 is handling the traffic for routing context
P and N/w Appearance A. AS2 is handling the traffic for routing context
Q and N/w Appearance A. ASP1 is in both AS. Point Code of SGP/IPSP is Z.
Routing Context P and Q may be based on the following information:
1. DPC.
2. DPC+SSN.
diaggarwal(editor) [Page 7]
Internet Draft SUA Conformance Test Plan [Page 8]
3. Global Title GT.
4. hostname.
--------------
| AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SGP/IPSP | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC Y |
------------- | ------- |
| | ASP1 | |
| ------- |
--------------
Fig 2: Configuration B
Configuration A.3 :
This configuration is used for all the procedures of tests concerning
two or more ASP in one AS. Configuration C is shown in figure 3. AS is
handling the traffic for routing context P and N/w Appearance A. ASP1
and ASP2 can be in FAIL-OVER mode or LOADSHARE mode of traffic handling.
Point Code of SGP/IPSP is Z. Routing Context P may be based on the
following information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. hostname N
--------------
| AS DPC X |
------------- | ------- |
| |-------------------------------|-| ASP1 | |
| SGP/IPSP | | ------- |
| Under Test | | ------- |
| DPC Z | | | ASP2 | |
| |-------------------------------|- ------- |
------------- --------------
Fig 3: Configuration C
diaggarwal(editor) [Page 8]
Internet Draft SUA Conformance Test Plan [Page 9]
Configuration A.4 :
This configuration is used for all the procedures of tests concerning
two or more AS which are handling traffic for different network
appearance and different routing context. Configuration D is shown in
figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and
AS3 is handling traffic for N/w appearance B. AS1 is handling traffic
for Routing Context P, AS2 is handling traffic for Routing Context Q
and AS3 is handling traffic for Routing Context R.
--------------
| AS1 DPC X |
------------- | ------- |
| |-------------------------------| | ASP1 | |
| SGP/IPSP | | ------- |
| Under Test | --------------
| DPC Z | --------------
| |-------------------------------| AS2 DPC Y |
------------- -------+ | ------- |
| | | ASP2 | |
| | ------- |
| --------------
| --------------
| | AS3 RK 2, 3 |
+-----------------------|- ------- |
| | ASP 3 | |
| ------- |
--------------
Fig 4: Configuration D
3.1.2 Configuration B: For Testing the IUT at ASP
Configuration B.1 :
This simple configuration is used for all the procedures of tests
concerning only one SGP/IPSP. Configuration G is shown in figure 7. Point
Code of SGP is Z. ASP is handling the traffic for routing context P.
Routing Context P may be based on the following information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. Hostname.
diaggarwal(editor) [Page 9]
Internet Draft SUA Conformance Test Plan [Page 10]
------------- --------------
| ASP1 | | SGP/IPSP |
| Under Test | | DPC = Z |
| DPC = X |-------------------------------| |
| | | |
------------- --------------
Fig 7: Configuration G
Configuration B.2:
This configuration is used for all the procedures of tests concerning
Two SGPs/IPSPs connected to the same ASP and handling traffic for the
same DPC In the SEP network. Configuration H is shown in figure 8.
SG1/IPSP1 and SG2/IPSP2 are handling the traffic for N/w Appearance A.
Point Code of SG1/IPSP1 is Y and of SG2/IPSP2 is Z. Routing Context
P may be based on the following information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. Hostname.
--------------
| SG1/IPSP1 |
------------- | DPC Y |
| |-------------------------------| |
| ASP1 | | |
| Under Test | --------------
| DPC X | --------------
| |-------------------------------| SG2/IPSP2 |
------------- | DPC Z |
| |
| |
--------------
Fig 8: Configuration H
Configuration B.3:
This simple configuration is used for all the procedures of tests
Concerning one ASP in two AS. Configuration I is shown in figure 9.
Point Code of SGP/IPSP is Z. ASP1 is in two AS, AS1 and AS2. AS1 is handling
Traffic for routing context P and AS2 is handling traffic for routing
Context Q. Routing Context P and Q may be based on the following
Information:
1. DPC.
2. DPC+SSN.
3. Global Title GT.
4. Hostname.
diaggarwal(editor) [Page 10]
Internet Draft SUA Conformance Test Plan [Page 11]
------------- --------------
| ASP1 | | SGP/IPSP |
| Under Test | | DPC = Z |
| DPC = X |-------------------------------| |
| | | |
------------- --------------
Fig 9: Configuration I
Configuration Note: The SG can have same Point Code as one of
The AS in the SEP mode of operation.
diaggarwal(editor) [Page 11]
Internet Draft SUA Conformance Test Plan [Page 12]
4 Test cases
The order in which the Test Cases are executed are
dependent on the tester, however it is recommended that the
test cases should be executed in the following order:
1) ASPM Procedures.
2) Routing.
3) Segmentation and re-assembly.
4) Timer Validation.
5) Connectionless messages.
6) Connection oriented messages.
7) Relay node Functionality.
4.1 Test cases for Testing of Connectionless Procedures
4.1.1 "Connectionless Data Transfer for Protocol Class 0"
+ TEST NUMBER: 1.1
+ PURPOSE: To check that successful Connectionless Data transfer
occurs from one PC to another.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP and ASP. The IUT is running at Both the ASP
and the SGP. However the same MUST be executed at IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams).
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY (ASP-InActive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
diaggarwal(editor) [Page 12]
Internet Draft SUA Conformance Test Plan [Page 13]
<--------------- NTFY (ASP-Active)
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
N-UNITDATA REQ CLDT ------------->
---------> N-UNITDATA IND
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-DOWN state.
Check A: ASPUP-Ack message will come from SGP.
2. Send ASPAC message to the SGP in ASP-UP state.
Check A: ASPAC-Ack message will come from SGP.
Check B: NTFY message will come from SGP.
3. Send N-UNITDATA Primitive from the NIF at SGP to send to ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: Check the protocol class field in common message header.
It should be class 0.
4. Send CLDT message from ASP containing Protocol Data and Protocol Class 0.
Check C: N-UNITDATA Ind. Primitive is received at the NIF with
the Protocol Data.
Check D: Check the protocol class field in common message header.
It should be class 0.
Send different CLDT messages from both the directions several times.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 13]
Internet Draft SUA Conformance Test Plan [Page 14]
4.1.2 "CL Data response message generation for Protocol Class 0"
+ TEST NUMBER: 1.2
+ PURPOSE: To check that in case a CLDT Message is sent with an
invalid parameter value like Hop Counter = 0, it results
in a CLDR Message, in case the return option is set.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP .However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange the
data in SGP such that NIF sends Transfer request primitive to SUA
with Routing Context A, containing protocol class "0" , Hop
Counter as "0" and return option set as "1"( Bit 8 in the
protocol class parameter should be set to 1)to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
ERROR <------------- CLDT (hop Counter = 0)
CLDR ------------->
---------> N-NOTICE IND
TEST DESCRIPTION:
1. Send CLDT (with Hop Counter = 0) message from the NIF at SGP
to send to ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: Check that a CLDR Message is sent in response to this
CLDT Message, since we have Sent Hop Counter as "0" which
is invalid.
The Above Test case MUST be carried out for Invalid values
Of the following parameters For BOTH Protocol "0"
And protocol "1":
"Routing Context"
"Protocol Class"
diaggarwal(editor) [Page 14]
Internet Draft SUA Conformance Test Plan [Page 15]
"Source Address"
"Destination Address"
"Sequence Control"
"SS7 Hop Count"
"Importance"
"Message Priority"
"Correlation ID"
"Segmentation"
"Data"
diaggarwal(editor) [Page 15]
Internet Draft SUA Conformance Test Plan [Page 16]
4.1.3 "Connectionless Data response message not generated if return option is
not set for Protocol Class 0"
+ TEST NUMBER: 1.3
+ PURPOSE: To check that in case a CLDT Message is sent with an
invalid parameter value like Hop Counter = 0, it does
not results in a CLDR Message, in case the return
option is not set.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP .However
the same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange
the data in SGP such that NIF sends Transfer Request primitive
to SUA with Routing Context A, containing protocol class "0",
Hop Counter as "0" and return option set as "0"(Bit 8 in
the protocol class parameter should be set to 0) to be sent
to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
ERROR <------------- CLDT (hop Counter = 0)
CLDT ------------> ERROR
(Hop Counter = 0)
TEST DESCRIPTION:
1. Send CLDT (with Hop Counter = 0) Primitive from the NIF at SGP
to send to ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: Check that a CLDR Message is not sent in response to
this CLDT Message, since we have Sent Hop Counter as
"0" which is invalid, with return option set to "0".
The Above Test case MUST be carried out for Invalid values
Of the following parameters For BOTH Protocol "0"
And protocol "1":
diaggarwal(editor) [Page 16]
Internet Draft SUA Conformance Test Plan [Page 17]
"Routing Context"
"Protocol Class"
"Source Address"
"Destination Address"
"Sequence Control"
"SS7 Hop Count"
"Importance"
"Message Priority"
"Correlation ID"
"Segmentation"
"Data"
diaggarwal(editor) [Page 17]
Internet Draft SUA Conformance Test Plan [Page 18]
4.1.4 "Invalid Version check for Protocol Class 0"
+ TEST NUMBER: 1.4
+ PURPOSE: To check that in case a CLDT Message is received with an
Invalid version, the message is rejected, and an ERR message
Is generated with error code as "Invalid version".
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP .However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also Arrange the
data in SGP such that NIF sends Transfer Request primitive to
SUA with Routing Context A, Containing protocol class "0", SUA
version id as "10" to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
ERROR <------------- CLDT (SUA version = 10)
ERR -------->
(Invalid Version)
TEST DESCRIPTION:
1. Send CLDT(with version 10) message to the ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: Check that the message is ignored, since we have sent SUA
version as "10" which is invalid.
Check C: An Error message with error code "Invalid version" Should be
Received at the SGP.
diaggarwal(editor) [Page 18]
Internet Draft SUA Conformance Test Plan [Page 19]
4.1.5 "Mandatory Parameters Missing for CLDT for Protocol Class 0"
+ TEST NUMBER: 1.5
+ PURPOSE: To check that in case a CLDT Message is received without a
mandatory Parameter, the message is rejected, and an ERR
message with error code "Missing Parameter" should be generated.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP .However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange the
data in SGP such that NIF sends Transfer Request primitive to
SUA with Routing Context A, containing protocol class "0",
without the mandatory parameter Routing Context to be sent
to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
ERROR <------------- CLDT (mandatory parameter Routing
Context Missing)
ERR -------->
(Missing Parameter)
TEST DESCRIPTION:
1. Send CLDT(without the mandatory parameter) message to ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: Check that the message is ignored, since we have sent the message
without the mandatory parameter Routing Context which is invalid.
Check C: An Error message with error code "Missing Parameter" Should be
Received at the SGP.
Repeat the above test case for different parameters
"Protocol Class"
"Destination Address"
"Source Address"
"Sequence Control"
"Data"
diaggarwal(editor) [Page 19]
Internet Draft SUA Conformance Test Plan [Page 20]
Repeat the Above test case for CLDR Message for different Mandatory
parameters
"Routing Context"
"SCCP Cause"
"Source Address"
"Destination Address"
diaggarwal(editor) [Page 20]
Internet Draft SUA Conformance Test Plan [Page 21]
4.1.6 "Ordered Delivery for CLDT for Protocol Class 1"
+ TEST NUMBER: 1.6
+ PURPOSE: To check that CLDT Messages with Protocol class 1 are
delivered in order.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP .However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange the
data in SGP such that NIF sends Transfer Request primitive to
SUA with Routing Context A, containing protocol class "1" and
sequence control parameter set to "1", to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-UNITDATA IND <------------- CLDT
(Seq. Control 1)
N-UNITDATA IND <------------- CLDT
(Seq. Control 1)
N-UNITDATA IND <------------- CLDT
(Seq. Control 1)
TEST DESCRIPTION:
1. Send CLDT(with Seq Control 1) to the ASP.
Check A: CLDT messages should be received at the ASP1 in the same
order as was sent by the originating side.
diaggarwal(editor) [Page 21]
Internet Draft SUA Conformance Test Plan [Page 22]
4.1.7 "Messages greater than maximum length of Data in
CLDT for Protocol Class 0"
+ TEST NUMBER: 1.7
+ PURPOSE: To check that CLDT Messages with Protocol class 0 and length
of Data greater then maximum permissible length (3952 Ref Q.713
3.20) is rejected.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP .However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also
arrange the data such that Transfer Request primitive is
sent to SUA with Routing Context A, containing protocol
class "0" and Data length "3953", to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
CLDT ------------> ERROR
(Data Length 3953)
TEST DESCRIPTION:
1. Send CLDT(with Data length as 3953) to the SGP.
Check A: CLDT messages should be received at the SGP is rejected
as the length is greater than maximum length.
Repeat the Above Test case for Protocol Class "1" with different
values for the message length field.
diaggarwal(editor) [Page 22]
Internet Draft SUA Conformance Test Plan [Page 23]
4.2 Test Cases for Testing of Connection-Oriented Messages
4.2.1 "Successful connection establishment and termination"
+ TEST NUMBER: 2.1
+ PURPOSE: To check connection establishment and termination.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP and SGP. The IUT is running at both the ASP
and the SGP .However the same MUST be executed at IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(Ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
<--------- N-DISCONNECT REQ
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
RELCO------------>
(Dest ref. number "A") ---------> N-DISCONNECT IND
diaggarwal(editor) [Page 23]
Internet Draft SUA Conformance Test Plan [Page 24]
N-DATA REQ -------->
<--------- ERROR (Connection Does not exist)
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODT message should be received for Source Ref. number "A".
4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: RELRE message should be received at the ASP.
Check B: RELCO message should be received at the SGP.
5. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: Should result in error.
diaggarwal(editor) [Page 24]
Internet Draft SUA Conformance Test Plan [Page 25]
4.2.2 "Connection release during Connection Establishment"
+ TEST NUMBER: 2.2
+ PURPOSE: To check if the CORE message is responded with a COREF
Message the connection is not established.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP and the SGP. The IUT is running at both the
ASP and the SGP. However the same MUST be executed at IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-DISCONNECT REQ -------->
COREF------------>
(Dest ref. number "A") ---------> N-DISCONNECT IND
<--------- N-DATA REQ
------------> ERROR
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-DISCONNECT REQ Primitive from the ASP to SGP.
Check A: COREF message should be received at the ASP, with
refusal cause value.
The Above Test case should be carried out for Protocol Class "2" and "3".
diaggarwal(editor) [Page 25]
Internet Draft SUA Conformance Test Plan [Page 26]
4.2.3 "Connection oriented Data with mandatory parameter missing"
+ TEST NUMBER: 2.3
+ PURPOSE: To check if the CODT message is received with a
mandatory parameter missing it is responded with
an COERR Message.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the
test case at the ASP. The IUT is running at the ASP .However
the same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Arrange
the CODT message so that it does not contain the mandatory
parameter Routing Context.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-DATA REQ
<------------- CODT (Routing Context missing)
COERR------------>
(Error cause) ------------> ERROR
TEST DESCRIPTION:
1. Send N-DATA REQ (without protocol class parameter )Primitive from
the NIF at SGP to send to ASP.
Check A: CODT message should be received at the ASP.
Check B: COERR message should be received at the SGP, with error cause value.
The Above Test case should be carried out for Protocol Class "2" and "3".
The above Test case should also be carried for the messages listed below
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Message parameters to be checked for
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CODT Routing Context
Sequence Number(NOT in case of N-EXPED.DATA REQ)
Destination Reference Number
diaggarwal(editor) [Page 26]
Internet Draft SUA Conformance Test Plan [Page 27]
Data
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CODA Routing Context
Destination Reference Number
Receive Sequence number
Credit
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CORE Routing Context
Protocol Class
Source Reference Number
Destination Address
Sequence Number
Credit(in case of Protocol class 3)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COAK Routing Context
Protocol Class
Destination Reference Number
Source Reference Number
Sequence Number
Credit(in case of Protocol class 3)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COREF Routing Context
Destination Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RELRE Routing Context
Destination Reference Number
Source Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RELCO Routing Context
Destination Reference Number
Source Reference Number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RESRE Routing Context
Destination Reference Number
Source Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RESCO Routing Context
Destination Reference Number
Source Reference Number
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COERR Routing Context
Destination Reference Number
SCCP Cause
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
COIT Routing Context
Protocol Class
diaggarwal(editor) [Page 27]
Internet Draft SUA Conformance Test Plan [Page 28]
Source Reference Number
Destination Reference number
Sequence Number
Credit
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diaggarwal(editor) [Page 28]
Internet Draft SUA Conformance Test Plan [Page 29]
4.2.4 "Connection response message parameter validation"
+ TEST NUMBER: 2.4
+ PURPOSE: To check that if the CORE Message carries the Source address
then the COAK Message also carries the Destination address
parameter.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP and the SGP. The IUT is running at both the
ASP and the ASP. However the same MUST be executed at IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (With Source Address parameter present)
(Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Contains Dest. Address parameter)
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with Source address parameter present) Primitive
from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
Check A: COAK message should contain the Destination Address parameter.
The Above Test case should be carried out for Protocol Class "2" and "3".
diaggarwal(editor) [Page 29]
Internet Draft SUA Conformance Test Plan [Page 30]
4.2.5 "Connection Oriented Data Ack. Received in response to CODT
with Protocol Class 3, when the receive window becomes full"
+ TEST NUMBER: 2.5
+ PURPOSE: To check that a CODA message is received in response
to a CODT message in case of Protocol Class 3, when the
receive window becomes full.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP and the SGP. The IUT is running at both the
ASP and the SGP. However the same MUST be executed at IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(credit 3)
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(credit 3)
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(ref. number "A")
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(ref. number "A + 1")
N-DATA REQ -------->
diaggarwal(editor) [Page 30]
Internet Draft SUA Conformance Test Plan [Page 31]
CODT ------------>
---------> N-DATA IND
(ref. number "A + 2")
<------------- CODA
(Sequence number "A + 2")
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send 3 N-DATA REQ Primitive from the ASP to send to SGP.
Check A: 3 CODT messages should be received at the SGP.
Check B: CODA message should be received at ASP with
Source Ref. number "A + 2".
diaggarwal(editor) [Page 31]
Internet Draft SUA Conformance Test Plan [Page 32]
4.2.6 "Missequencing in Protocol Class 3 for send Seq. Number"
+ TEST NUMBER: 2.6
+ PURPOSE: To check that in case of protocol class 3 if mis-sequencing
Occurs, for send Seq. Number, then the connection
is reset by peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 3) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
---------> Error
N-RESET CONFRM IND <------------- RESCO
diaggarwal(editor) [Page 32]
Internet Draft SUA Conformance Test Plan [Page 33]
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 1 to the SGP Side.
4. Send CODT message with Seq. number 2 to the SGP Side.
Check A: CODT message should be received at the SGP.
5. Send CODT message with Seq. number 4 to the SGP Side.
Check A: CODT message should be received at the SGP.
Check B: RESCO Message should be received at the ASP side.
diaggarwal(editor) [Page 33]
Internet Draft SUA Conformance Test Plan [Page 34]
4.2.7 "Missequencing in Protocol Class 3 for Recv Seq. Number"
+ TEST NUMBER: 2.7
+ PURPOSE: To check that in case of protocol class 3 if mis-sequencing
occurs, for recv Seq. Number, then the connection is reset by peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (Ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 0)
(recv Seq. Number 2)
CODT ------------>
(Send Seq. Number 2) ---------> N-DATA IND
(recv Seq. Number 1) (Ref. number "A")
diaggarwal(editor) [Page 34]
Internet Draft SUA Conformance Test Plan [Page 35]
CODT ------------>
(Send Seq. Number 3) ---------> N-DATA IND
(recv Seq. Number 1) (Ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 1)
(recv Seq. Number 1)
ERROR<-----
RESRE------------> ---------> N-RESET IND
N-RESET CONFIRM<------------- RESCO
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. Send CODT message to the ASP Side.
Check A: CODT message should be received at the SGP.
Check B: Send Seq Number should be 0 and Recv. Seq. Number should be 2.
6. Send CODT message with Seq. number 0 to the SGP Side.
7. Send CODT message with Seq. number 1 to the SGP Side.
8. Send CODT message to the ASP Side, with RECV SEQ NUMBER AS 1.
Check A: peer should reset Connection.
diaggarwal(editor) [Page 35]
Internet Draft SUA Conformance Test Plan [Page 36]
4.2.8 "Missequencing in Protocol Class 3 for Recv Seq. Number,
in CODA message"
+ TEST NUMBER: 2.8
+ PURPOSE: To check that in case of protocol class 3 if mis-sequencing
occurs, for recv Seq. Number, then the connection
is reset by peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(Credit 2)
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Credit 2)
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
<------------- CODA
(Send Seq. Number 0)
(recv Seq. Number 2)
<------------- CODA
diaggarwal(editor) [Page 36]
Internet Draft SUA Conformance Test Plan [Page 37]
(Send Seq. Number 1)
(recv Seq. Number 1)
ERROR<-----
RESRE------------> ---------> N-RESET IND
N-RESET CONFIRM<------------- RESCO
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
Check A: CODA Message with Send Seq. Number 0 and recv Seq
number 2 should be received.
5. Send CODA message to the ASP Side, with Send Seq. Number as 0
and recv Seq number as 1.
Check A: Connection should be reset by peer.
diaggarwal(editor) [Page 37]
Internet Draft SUA Conformance Test Plan [Page 38]
4.2.9 "Missequencing in Protocol Class 3 for Recv Seq. Number,
greater than next sent seq. number"
+ TEST NUMBER: 2.9
+ PURPOSE: To check that in case of protocol class 3 if mis-sequencing
occurs, for recv Seq. Number, then the connection is reset by
peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
N-DATA IND<------------- CODT
(Send Seq. Number 0)
(recv Seq. Number 10)
ERROR<-----
diaggarwal(editor) [Page 38]
Internet Draft SUA Conformance Test Plan [Page 39]
RESRE------------> ---------> N-RESET IND
N-RESET CONFIRM<------------- RESCO
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. Send CODT message to the ASP Side, with RECV SEQ NUMBER AS 10.
Check A: Connection should be reset by peer.
diaggarwal(editor) [Page 39]
Internet Draft SUA Conformance Test Plan [Page 40]
4.2.10 "Flow Control Validation"
+ TEST NUMBER: 2.10
+ PURPOSE: To check Flow Control procedures in case of protocol class 3.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(credit 2)
(Expediate Data Selection Set)
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
N-DATA REQ -------->
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
N-DATA REQ -------->
ERROR<------
N-EXP-DATA REQ -------->
diaggarwal(editor) [Page 40]
Internet Draft SUA Conformance Test Plan [Page 41]
CODT ------------>
(Sequence Number Absent) ---------> N-EXP-DATA IND
(ref. number "A")
N-EXP-DATA IND <------------- CODA
(Sequence Number absent)
TEST DESCRIPTION:
1. Send CORE message from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. No CODT or CODA Message MUST be sent by peer.
6. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: Data Should be rejected by the stack.
diaggarwal(editor) [Page 41]
Internet Draft SUA Conformance Test Plan [Page 42]
4.2.11 "Missequencing in Protocol Class 3 for Send Seq. Number,
Outside Rx Window"
+ TEST NUMBER: 2.11
+ PURPOSE: To check that in case of protocol class 3 if mis-sequencing
occurs, for recv Seq. Number, then the connection is reset by peer.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(Credit 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Credit 3)
CODT ------------>
(Send Seq. Number 0) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
CODT ------------>
(Send Seq. Number 1) ---------> N-DATA IND
(recv Seq. Number 0) (ref. number "A")
CODT ------------>
(Send Seq. Number 10) ---------> Error
(recv Seq. Number 0)
N-RESET IND<------------- RESRE (Source ref. number "A")
RESCO------------> ---------> N-RESET CONFIRM IND
diaggarwal(editor) [Page 42]
Internet Draft SUA Conformance Test Plan [Page 43]
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message with Seq. number 0 to the SGP Side.
4. Send CODT message with Seq. number 1 to the SGP Side.
5. Send CODT message with Seq. number 10 to the SGP Side.
Check A: The Connection is reset by peer.
diaggarwal(editor) [Page 43]
Internet Draft SUA Conformance Test Plan [Page 44]
4.2.12 "Reset Connection procedures in Protocol Class 3"
+ TEST NUMBER: 2.12
+ PURPOSE: To check that in case of protocol class 3, Connection
can be reset by the user.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<------------- CODA
<--------- N-RESET REQ
N-RESET IND <------------- RESRE (Source ref. number "A")
(Protocol Class 3)
RESCO------------>
(Dest ref. number "A") ---------> N-RESET CONFIRM IND
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
diaggarwal(editor) [Page 44]
Internet Draft SUA Conformance Test Plan [Page 45]
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ(with Sequence number 1) Primitive from
the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODA message should be received at ASP with Source
Ref. number "A".
4. Send N-RESET REQ Primitive from the SGP to send to ASP.
Check A: RESRE message should be received at the ASP.
5. Send RESCO message from the ASP to send to SGP.
Check B: RESCO Message should be received at the SGP side.
diaggarwal(editor) [Page 45]
Internet Draft SUA Conformance Test Plan [Page 46]
4.2.13 "credit parameter negotiation in Protocol Class 3"
+ TEST NUMBER: 2.13
+ PURPOSE: To check the credit parameter negotiation in case
of protocol class 3.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(credit size 110)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(credit size 100) (credit size 100)
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with credit size as 130) Primitive from
the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK(with a different credit value than what is received,
credit = 100) message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT(with Sequence number 1) message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
diaggarwal(editor) [Page 46]
Internet Draft SUA Conformance Test Plan [Page 47]
4.2.14 "Connection Oriented Inactivity test in Protocol Class 3"
+ TEST NUMBER: 2.14
+ PURPOSE: To check the Connection Oriented Inactivity test
procedures in Protocol Class 3.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<<<< No Data transfer for "T(ias),Inactivity Send timer= 7 minutes" >>>>>
<------------- COIT
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message to the SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message to the SGP.
Check A: CODT message should be received at the SGP.
diaggarwal(editor) [Page 47]
Internet Draft SUA Conformance Test Plan [Page 48]
4. Send No Data for the inactivity Send Timer interval = 7 Minutes.
Check A: COIT message should flow from the SGP to the ASP.
diaggarwal(editor) [Page 48]
Internet Draft SUA Conformance Test Plan [Page 49]
4.2.15 "Connection Oriented Inactivity test invalid parameters
in Protocol Class 3"
+ TEST NUMBER: 2.15
+ PURPOSE: To check the Invalid Connection Oriented Inactivity test
procedures in Protocol Class 3.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
COIT ------------>
(Source ref. number "B")
---------> Error
N-RELEASE CONFRM IND<------------- RELCO
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with credit size as 130) Primitive from
the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
diaggarwal(editor) [Page 49]
Internet Draft SUA Conformance Test Plan [Page 50]
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
4. Send a COIT message with an invalid value of Dest. ref. number
(ref. number B).
Check A: peer should Release Connection. A RELCO Message should
be received.
The above Test case should be carried for Protocol class "2" and "3"
for the following parameters
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
parameter Behavior to be observed
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Source Reference Number Connection Released by Peer.
Protocol Class Connection Released by Peer.
Sequence Number(only in protocol class 3)Connection Reset by Peer.
Credit(only in protocol class 3) Connection Reset by Peer.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diaggarwal(editor) [Page 50]
Internet Draft SUA Conformance Test Plan [Page 51]
4.2.16 "Protocol Class negotiation"
+ TEST NUMBER: 2.16
+ PURPOSE: To check the protocol Class negotiation procedures in
SUA.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(Protocol Class 2) (Protocol Class 2)
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<------------- CODA
TEST DESCRIPTION:
1. Send N-CONNECT REQ(with protocol class 3) Primitive from the
NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message(with protocol class 2) from the ASP to send to SGP.
Check A: COAK message with protocol class 2, should be received at the SGP.
3. Send CODT message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODA message should be received at ASP.
diaggarwal(editor) [Page 51]
Internet Draft SUA Conformance Test Plan [Page 52]
4.2.17 "Connection refusal due to Route on DPC+SSN FAILURE,
no SSN available"
+ TEST NUMBER: 2.17
+ PURPOSE: To check that when routing is DPC+SSN based, and
the peer fails to locate a user, a COREF message is
sent back.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
Also arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A, containing
protocol class "0" to be sent to DPC "X" and SSN "Y". No user
should be registered with the SSN "Y" on the ASP side.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-CONNECT REQ
(Route on DPC+SSN)
<------------- CORE
(Route on DPC+SSN)
<------------
ERROR(no SSN found)
COREF ------------->
(Route on DPC+SSN FAILURE)---------> N-DISCONNECT IND
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to
DPC "X" and SSN "Y".
Check A: CORE message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: A COREF Message should be sent back with appropriate error
code, indicating no user with the desired SSN exists.
diaggarwal(editor) [Page 52]
Internet Draft SUA Conformance Test Plan [Page 53]
4.2.18 "Connection Oriented Data Ack. Received in response to
CODT with Protocol Class 3, when the other side sends data"
+ TEST NUMBER: 2.18
+ PURPOSE: To check that a CODA message is received in response
to a CODT message in case of Protocol Class 3, when
the other side sends data.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
(credit 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
(credit 3)
CODT ------------>
(ref. number "A") ---------> N-DATA IND
(ref. number "A")
CODT ------------>
(ref. number "A + 1") ---------> N-DATA IND
(ref. number "A + 1")
<--------- N-DATA REQ
<------------- CODT
(Sequence number "A + 1")
TEST DESCRIPTION:
diaggarwal(editor) [Page 53]
Internet Draft SUA Conformance Test Plan [Page 54]
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send 2 CODT messages from the ASP to send to SGP.
Check A: 2 CODT messages should be received at the SGP.
4. Send N-DATA REQ Primitive from the SGP to ASP.
Check B: CODT message should be received at ASP with
Source Ref. number "A + 1".
diaggarwal(editor) [Page 54]
Internet Draft SUA Conformance Test Plan [Page 55]
4.2.19 "No Response to RELRE Message"
+ TEST NUMBER: 2.19
+ PURPOSE: To check that if a RELRE message is sent and is not responded
with, it will retry a number of times and then release
the connection.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
---------> N-DATA IND
(ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
<--------- N-DISCONNECT REQ
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
(Starts timer T(rel))
(Starts timer T(interval))
<<<<< T(rel) expires >>>>>
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
diaggarwal(editor) [Page 55]
Internet Draft SUA Conformance Test Plan [Page 56]
(Starts timer T(rel))
<<<<< T(rel) expires >>>>>
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
(Starts timer T(rel))
<<<<< T(interval) expires >>>>>
N-DISCONNECT IND<------------- RELCO (Source ref. number "A")
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message from the ASP to send to SGP.
Check A: CODT message should be received at the SGP for
Source Ref. number "A".
4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: RELRE message should be received at the ASP.
Check B: No RELCO message MUST be sent to the SGP.
Check C: The RELRE message is retransmitted a number of times,
till the inactivity timer expires and a RELCO message
is sent.
Note : the Timers T(rel) and T(interval) are purely implementation dependent.
The draft does not explicitly mention, however these should be started,
in order to safe guard against any loss or ignorance of message at the
receiving end, as a part of a recover mechanism.
diaggarwal(editor) [Page 56]
Internet Draft SUA Conformance Test Plan [Page 57]
4.3 Segmentation And Re-Assembly
4.3.1 "CL Data Transfer Segmentation for Protocol Class 0 on SGP
Side not working as an STP"
+ TEST NUMBER: 3.1
+ PURPOSE: To check that a Connectionless Data transfer message with Size
greater than 272 octets is Segmented, if the data transfer
is initiated from the SGP Side.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The IUT is running at the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also
arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A,
containing protocol class "0" to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Data length 300 Octets)
<------------- CLDT
(Data Length 272 Octets)
<------------- CLDT
(Data Length (300-272) Octets)
<----------
N-UNITDATA IND
(Data length 300 Octets)
TEST DESCRIPTION:
1. Send N-UNITDATA(Data length 300 Bytes) Primitive from the NIF
at SGP to send to ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP, in two segments, one segment of
272 octets and the next segment of the remaining bytes.
Check B: Check that the SUA assembles the segments and gives an
N-UNITDATA indication, of length 300 octets.
diaggarwal(editor) [Page 57]
Internet Draft SUA Conformance Test Plan [Page 58]
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 58]
Internet Draft SUA Conformance Test Plan [Page 59]
4.3.2 "CL Data Transfer Segmentation for Protocol Class 0 on IPSP"
+ TEST NUMBER: 3.2
+ PURPOSE: To check that a Connectionless Data transfer message with Size
greater than 272 octets is NOT SEGMENTED, if the data transfer
is initiated from the IPSP Side.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
IPSP. The example listed below covers the test case at
the IPSP. The IUT is running at the IPSP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active. Also
arrange the data in SGP such that NIF sends Transfer Request
primitive to SUA with Routing Context A, containing protocol
class "0" to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
IPSP IPSP NIF
IPSP is active
<--------- N-UNITDATA REQ
(Data length 600 Octets)
<------------- CLDT
(Data Length 600 Octets)
<----------
N-UNITDATA IND
(Data length 600 Octets)
TEST DESCRIPTION:
1. Send N-UNITDATA(Data length 600 Bytes) Primitive from the NIF
at SGP to send to ASP.
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP, It SHOULD NOT BE SEGMENTED.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 59]
Internet Draft SUA Conformance Test Plan [Page 60]
4.3.3 "CL Data Transfer re-assembly for Protocol Class 0 on SGP
acting as an STP"
+ TEST NUMBER: 3.3
+ PURPOSE: To check that a Connectionless Data transfer message with
Size greater than 272 octets is NOT re-assembled, if the SGP is
acting as an STP.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The IUT is running at the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
Also arrange the data in SGP such that NIF sends
Transfer Request primitive to SUA with Routing Context
A, containing protocol class "0" to be sent to DPC X.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
<------------- CLDT
(Data length 300 Octets)
(SGP Figures out it has to behave
as an STP for this message)
CLDT <----------
(Data length 272 Octets)
<------------- CLDT
(Data length (300-272) Octets)
CLDT <----------
(Data length (300-272) Octets)
TEST DESCRIPTION:
1. SGP is acting as a RELAY NODE and received segmented messages.
Check A: CLDT message SHOULD NOT be re-assembled , and passed on
to ASP as they are.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 60]
Internet Draft SUA Conformance Test Plan [Page 61]
4.3.4 "Connection oriented Data transfer Segmentation on SGP Side"
+ TEST NUMBER: 3.4
+ PURPOSE: To check that if a N-DATA request is issued to SUA at
SGP side with length greater than 255, is not segmented.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The IUT is running at the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
<--------- N-DATA REQ
(Length 300 octets)
<------------- CODT (Source ref. number "A")
(Length 300 octets)
N-DATA IND <----------
(Length 300 octets)
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send COAK message from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive (with length 300)from the SGP to ASP.
Check A: CODT message should be received at the ASP.
Check B: CODT message SHOULD NOT be segmented.
The Above Test case should be carried out for Protocol Class "2" and "3".
diaggarwal(editor) [Page 61]
Internet Draft SUA Conformance Test Plan [Page 62]
4.3.5 "Connection oriented Data transfer Segmentation on ASP Side"
+ TEST NUMBER: 3.5
+ PURPOSE: To check that if a N-DATA request is issued to SUA at
ASP side with length greater than 255, is segmented.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
ASP. The IUT is running at the ASP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
(Length 300 octets)
CODT ------------>
(Length 272 octets)
CODT ------------>
(Length (300-272) octets)
---------> N-DATA IND
(Length 300 octets)
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive (with length 300)from the ASP to SGP.
Check A: CODT message should be received at the ASP.
Check B: CODT message SHOULD BE segmented.
The Above Test case should be carried out for Protocol Class "2" and "3".
diaggarwal(editor) [Page 62]
Internet Draft SUA Conformance Test Plan [Page 63]
4.3.6 "Connection oriented Data transfer Segmentation on IPSP Side"
+ TEST NUMBER: 3.6
+ PURPOSE: To check that if a N-DATA request is issued to SUA at IPSP side
with length greater than 255, IS NOT SEGMENTED.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
IPSP. The IUT is running at the IPSP.
+ PRE-TEST CONDITIONS: SCTP association is established between
IPSP and IPSP
EXPECTED MESSAGE SEQUENCE:
IPSP IPSP NIF
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
(Length 300 octets)
CODT ------------>
(Length 300 octets)
---------> N-DATA IND
(Length 300 octets)
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive (with length 300)from the ASP to SGP.
Check A: CODT message should be received at the ASP.
Check B: CODT message SHOULD NOT BE segmented.
The Above Test case should be carried out for Protocol Class "2" and "3".
diaggarwal(editor) [Page 63]
Internet Draft SUA Conformance Test Plan [Page 64]
4.3.7 "Connection oriented Data transfer re-assembly on IPSP Side"
+ TEST NUMBER: 3.7
+ PURPOSE: To check that if segmented CODT messages are received by IPSP,
they are re-assembled into N-DATA IND.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
IPSP. The IUT is running at the IPSP.
+ PRE-TEST CONDITIONS: SCTP association is established between
IPSP and IPSP.
EXPECTED MESSAGE SEQUENCE:
IPSP
CODT ------------>
( Segmented )
(Length 272 octets)
CODT ------------>
( Segmented )
(Length (300-272) octets)
---------> N-DATA IND
(Length 300 octets)
TEST DESCRIPTION:
1. Generate Segmented CODT Messages towards the IPSP.
Check A: CODT messages should be received at the IPSP.
Check B: CODT messages SHOULD BE RE-ASSEMBLED and N-DATA IND
should be given to user.
The Above Test case should be carried out for Protocol Class "2" and "3".
diaggarwal(editor) [Page 64]
Internet Draft SUA Conformance Test Plan [Page 65]
4.4 Routing Procedures
4.4.1 "CL Data Transfer for Protocol Class 0, Route on GT"
+ TEST NUMBER: 4.1
+ PURPOSE: To check that successful GT Translation takes place and
Connectionless Data transfer occurs from one PC to another.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange
the data in SGP such that NIF sends Transfer Request primitive
to SUA with Routing Context A, containing protocol class "0"
to be sent to GT "X". Configure the SCCP Routing control route
GT "X" to DPC of ASP and SSN which is available at ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Route on GT)
<------------- CLDT
(Route on GT)
<------------
N-UNITDATA IND
(GT Translated to local PC and SSN)
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class "0" "1".
diaggarwal(editor) [Page 65]
Internet Draft SUA Conformance Test Plan [Page 66]
4.4.2 "CL Data Transfer for Protocol Class 0, Route on GT Failure,
with return Option set"
+ TEST NUMBER: 4.2
+ PURPOSE: To check that if GT Translation fails and return
option is set Connectionless Data response is sent back.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange
the data in SGP such that NIF sends Transfer Request primitive
to SUA with Routing Context A, containing protocol class "0"
to be sent to GT "X". Configure the SCCP Routing control route
GT "X" to DPC of ASP and SSN which is NOT AVAILABLE at ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<------------- CLDT
(Route on GT)
(return option set)
<------------
ERROR
CLDR ------------->
(Route on GT FAILURE) ---------> N-NOTICE IND
TEST DESCRIPTION:
1. Send CLDT message from the NIF at SGP to send to GT "X".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: A CLDR Message should be sent back in response to
the GT Routing Failure, as the return option is set.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 66]
Internet Draft SUA Conformance Test Plan [Page 67]
4.4.3 "CL Data Transfer for Protocol Class 0, Route on GT
Failure, return Option NOT set"
+ TEST NUMBER: 4.3
+ PURPOSE: To check that if GT Translation fails and return option is NOT
set Connectionless Data response is sent back.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange
the data in SGP such that NIF sends Transfer Request primitive
to SUA with Routing Context A, containing protocol class "0"
to be sent to GT "X". Configure the SCCP Routing control route
GT "X" to DPC of ASP and SSN which is NOT AVAILABLE at ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Route on GT)
(return option NOT set)
<------------- CLDT
(Route on GT)
<------------
ERROR
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: A CLDR Message SHOULD NOT BE sent back in response to
the GT Routing Failure, as the return option is NOT set.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 67]
Internet Draft SUA Conformance Test Plan [Page 68]
4.4.4 "CL Data Transfer for Protocol Class 0, Route on DPC"
+ TEST NUMBER: 4.4
+ PURPOSE: To check that Connectionless Data transfer occurs from one
PC to another, when routing is DPC based.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
Also arrange the data in SGP such that NIF sends
Transfer Request primitive to SUA with Routing Context A,
containing protocol class "0" to be sent to DPC "X".
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-UNITDATA REQ
(Route on DPC)
<------------- CLDT
(Route on DPC)
<------------
N-UNITDATA IND
(IND is given to appropriate user)
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to DPC "X".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 68]
Internet Draft SUA Conformance Test Plan [Page 69]
4.4.5 "CL Data Transfer for Protocol Class 0, Route on DPC+SSN "
+ TEST NUMBER: 4.5
+ PURPOSE: To check that Connectionless Data transfer occurs from one
PC to another, when routing is DPC+SSN based.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also
arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A, containing
protocol class "0" to be sent to DPC "X" and SSN "Y".
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-UNITDATA REQ
(Route on DPC+SSN)
<------------- CLDT
(Route on DPC+SSN)
<------------
N-UNITDATA IND
(IND is given to user with SSN "Y")
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to
DPC "X" and SSN "Y".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class
"0" and "1".
diaggarwal(editor) [Page 69]
Internet Draft SUA Conformance Test Plan [Page 70]
4.4.6 "CL Data Transfer for Protocol Class 0, Route on DPC+SSN
FAILURE with return option set"
+ TEST NUMBER: 4.6
+ PURPOSE: To check that when routing is DPC+SSN based, and
the peer fails to locate a user, a CLDR message is
sent back if return option is set.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
Also arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A,
containing protocol class "0" to be sent to DPC "X"
and SSN "Y". No user should be registered with the
SSN "Y" on the ASP side.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-UNITDATA REQ
(Route on DPC+SSN)
(Return option set)
<------------- CLDT
(Route on DPC+SSN)
<------------
ERROR(no SSN found)
CLDR ------------->
(Route on DPC+SSN FAILURE)---------> N-NOTICE IND
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to
DPC "X" and SSN "Y".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
Check B: A CLDR Message should be sent back with appropriate error
code, indicating no user with the desired SSN exists.
diaggarwal(editor) [Page 70]
Internet Draft SUA Conformance Test Plan [Page 71]
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 71]
Internet Draft SUA Conformance Test Plan [Page 72]
4.4.7 "CL Data Transfer for Protocol Class 0, Route on DPC+SSN FAILURE
with return option NOT set"
+ TEST NUMBER: 4.7
+ PURPOSE: To check that when routing is DPC+SSN based, and the
peer fails to locate a user, a CLDR message is sent
back if return option is NOT set.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the ASP. The IUT is running at the ASP. However the
same MUST be executed at IPSP and SGP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also arrange
the data in SGP such that NIF sends Transfer Request primitive
to SUA with Routing Context A, containing protocol class "0"
to be sent to DPC "X" and SSN "Y". No user should be registered
with the SSN "Y" on the ASP side.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
(DPC = X)
ASP is active
<--------- N-UNITDATA REQ
(Route on DPC+SSN)
(Return option not set)
<------------- CLDT
(Route on DPC+SSN)
<------------
ERROR(no SSN found)
N-UNITDATA REQ
(Route on DPC+SSN)
(Return option not set)
CLDT ------------->
(Route on DPC+SSN ---------> ERROR(no SSN found)
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to DPC "X"
and SSN "Y".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 72]
Internet Draft SUA Conformance Test Plan [Page 73]
4.4.8 "CL Data Transfer for Protocol Class 0, Route on Hostname"
+ TEST NUMBER: 4.8
+ PURPOSE: To check that successful Hostname DNS lookup takes place then
Connectionless Data transfer occurs from one PC to another.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also
arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A,
containing protocol class "0" to be sent to Hostname "X".
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Route on Hostname)
<------------- CLDT
(Route on Hostname)
<------------
N-UNITDATA IND
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to Hostname "X".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class "0" "1".
diaggarwal(editor) [Page 73]
Internet Draft SUA Conformance Test Plan [Page 74]
4.4.9 "CL Data Transfer for Protocol Class 0, Route on IP in
dotted-decimal Form"
+ TEST NUMBER: 4.9
+ PURPOSE: To check that successful Connectionless Data transfer
occurs from one PC to another, when routing is based on Ip
in dotted-decimal Form.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active. Also
arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A,
containing protocol class "0" to be sent to IP "A.B.C.D".
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Route on IP "A.B.C.D")
<------------- CLDT
(Route on IP "A.B.C.D")
<------------
N-UNITDATA IND
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to
IP "A.B.C.D".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
The Above Test case should be carried out for Protocol Class "0" and
"1".
diaggarwal(editor) [Page 74]
Internet Draft SUA Conformance Test Plan [Page 75]
4.4.10 "CL Data Transfer for Protocol Class 0, Route on Hostname
FAILURE"
+ TEST NUMBER: 4.10
+ PURPOSE: To check that successful Hostname DNS lookup FAILS then
Connectionless Data transfer fails.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active. Also
arrange the data in SGP such that NIF sends Transfer Request
primitive to SUA with Routing Context A, containing protocol
class "0" to be sent to Hostname "X".
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-UNITDATA REQ
(Route on Hostname)
(Hostname Resolution Fails)
---------> Error
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to
Hostname "X".
Check A: Error Indication Should be sent to the SM.
The Above Test case should be carried out for Protocol Class "0" "1".
diaggarwal(editor) [Page 75]
Internet Draft SUA Conformance Test Plan [Page 76]
4.4.11 "Successful connection establishment and termination Route on GT"
+ TEST NUMBER: 4.11
+ PURPOSE: To check connection establishment and termination Route on GT
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at both the SGP and ASP. The IUT is running at both
the SGP and ASP. However the same MUST be executed at IPSP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
(Route on GT)
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-CONNECT RESPONSE -------->
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
N-DATA REQ -------->
CODT ------------>
---------> N-DATA IND
(ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
<--------- N-DISCONNECT REQ
N-DISCONNECT IND<------------- RELRE (Source ref. number "A")
RELCO------------>
(Dest ref. number "A") ---------> N-DISCONNECT IND
N-DATA REQ -------->
diaggarwal(editor) [Page 76]
Internet Draft SUA Conformance Test Plan [Page 77]
<--------- ERROR (Connection Does not exist)
TEST DESCRIPTION:
1. Send N-CONNECT REQ(Dest Address should be in GT form ) Primitive
from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
2. Send N-CONNECT RESPONSE Primitive from the ASP to send to SGP.
Check A: COAK message should be received at the SGP.
3. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: CODT message should be received at the SGP.
Check B: CODT message should be received for Source Ref. number "A".
4. Send N-DISCONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: RELRE message should be received at the ASP.
Check B: RELCO message should be received at the SGP.
5. Send N-DATA REQ Primitive from the ASP to send to SGP.
Check A: Should result in error.
Test cases 2.4.1 to 2.4.10 MUST be tested as per the scenario 2.4.11,
to ensure their proper functioning for Protocol Class "2" and "3".
diaggarwal(editor) [Page 77]
Internet Draft SUA Conformance Test Plan [Page 78]
4.5 Relay node Functionality
4.5.1 "Relay mode operation, Route on GT "
+ TEST NUMBER: 5.1
+ PURPOSE: To check that if we receive a message with GT, and the
GT Translation does not route to local PC and
local user, the message is routed to the destination PC.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP, ASP and the IPSP also. The IUT is running
at all the three nodes.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP1 is active.
Also arrange the data in SGP such that NIF sends Transfer
Request primitive to SUA with Routing Context A,
containing protocol class "0" to be sent to GT "X".
EXPECTED MESSAGE SEQUENCE:
IPSP ASP SGP NIF
<--------- N-UNITDATA REQ
(Route on GT)
<------------- CLDT
(Route on GT)
(GT Translated to DPC "Y" and GT)
<------------- CLDT
(Route on GT)
<------------
N-UNITDATA IND
(GT Translated to local PC and SSN)
TEST DESCRIPTION:
1. Send N-UNITDATA Primitive from the NIF at SGP to send to GT "X".
Check A: CLDT message should be received at the ASP1 containing
the data passed by the SCCP.
diaggarwal(editor) [Page 78]
Internet Draft SUA Conformance Test Plan [Page 79]
Check B: The Message receives a GT, which translates to a new GT,
and the message is sent to the DPC(found out by
translation of GT).
The Above Test case should be carried out for Protocol Class "0" and "1".
diaggarwal(editor) [Page 79]
Internet Draft SUA Conformance Test Plan [Page 80]
4.6 Timer validation
4.6.1 "Validation of Timer T(ack)"
+ TEST NUMBER: 6.1
+ PURPOSE: To check that if the asp does not receive an ASP-UP-ACK
after sending an ASP-UP for a period of Timer T(ack),
it retransmits the ASP_UP message.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASPUP ---------------->
Status Ind ------->
<<Timer T(ack)=2 expires>>
ASPUP ---------------->
Status Ind ------->
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Down state.
2. Do not reply to the ASP-UP message with an ASP-UP-ACK
message.
Check A: After the expiry of the timer T(ack), the ASP-UP Message
is retransmitted.
Check B: The duration of the Timer T(ack) = 2 Seconds.
The above test case is to be carried out on SGP, ASP and IPSP.
diaggarwal(editor) [Page 80]
Internet Draft SUA Conformance Test Plan [Page 81]
4.6.2 "Validation of Timer T(beat)"
+ TEST NUMBER : 6.2
+ PURPOSE: To check that if ASP is in active state and no message
transfer occurs for a time period of T(beat)=30 Seconds,
a BEAT Message SHOULD be transmitted which is
acknowledged by a BEAT_ACK message
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is down
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(ASP-Active)
(Timer T(Beat)=30 Seconds starts)
(Timer T(Beat)=30 Seconds expires)
<--------------- BEAT
BEAT-ACK ---------------->
BEAT ---------------->
<--------------- BEAT-ACK
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Down state. ASP-Up-Ack and
NTFY (AS-Up) message will come from the SGP. Send ASPUP message
again from the AS for the same ASP.
diaggarwal(editor) [Page 81]
Internet Draft SUA Conformance Test Plan [Page 82]
Check A: ASP-Up-Ack message should be received at AS.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains in
the Up state. Send ASPAC message with valid Type and Routing Context
for the ASP1 and ASP-Active-Ack message should come.
2. Do not send any more messages for the connection.
Check A: After a Period of T(Beat) = 30 Seconds, a BEAT Message
SHOULD be originating from the ASP/SGP Side after every 30 seconds.
Check B: A BEAT_ACK MUST be sent from the SGP after receiving a BEAT message.
Note1 : The Inactivity send Timer and the Inactivity receive timer tests
have been covered in the test case "Connection Oriented
Inactivity test in Protocol Class 3"
Note2 : The pending timer tests have been covered in the test case
"Validation of AS pending Behavior"
diaggarwal(editor) [Page 82]
Internet Draft SUA Conformance Test Plan [Page 83]
4.6.3 "validation of Inactivity receive timer T(iar)"
+ TEST NUMBER: 2.9
+ PURPOSE: To check the Connection Oriented Inactivity receive timer
in Protocol Class 3.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP and ASP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams. ASP1 is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is active
<--------- N-CONNECT REQ
N-CONNECT IND <------------- CORE (Source ref. number "A")
(Protocol Class 3)
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
(Seq. Number 1) ---------> N-DATA IND
(ref. number "A")
<------------- CODA
<<<< No COIT message should flow for "T(iar),Inactivity
recv timer= 15 minutes" >>>>>
N-DISCONNECT IND<------------- RELCO
TEST DESCRIPTION:
1. Send N-CONNECT REQ Primitive from the NIF at SGP to send to ASP.
Check A: CORE message should be received at the ASP.
diaggarwal(editor) [Page 83]
Internet Draft SUA Conformance Test Plan [Page 84]
2. Send COAK message from the ASP to the SGP.
Check A: COAK message should be received at the SGP.
3. Send CODT message from the ASP to the SGP.
Check A: CODT message should be received at the SGP.
Check B: CODA message should be received at ASP with Source
Ref. number "A".
4. No COIT Message should flow for a period of "T(iar),Inactivity
recv timer= 15 minutes.
Check A: The Connection Should be released.
diaggarwal(editor) [Page 84]
Internet Draft SUA Conformance Test Plan [Page 85]
4.7 ASPM Procedures
4.7.1 "Validation of AS pending Behavior : recovery case"
+ TEST NUMBER: 7.1
+ PURPOSE: To check that if an asp transitions to ASP-DOWN or
ASP-INACTIVE state and it the last active ASP in the AS
the AS Moves to AS Pending State, and if the AS Buffers
messages for the ASPs for a timer duration of Tr = 2 seconds
and after receiving ASP-ACTIVE message, it transmits the
messages to the active ASP.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP is active.
The AS Should be having one and only one ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is Active
ASPDN ---------------->
Status Ind ------->
(Since this is the last Active ASP
in the AS the AS moves to pending state)
Status Ind ------->
(timer tr=2 seconds starts)
<<Messages are buffered>> <--------- N-CONNECT REQ
<<Messages are buffered>> <--------- N-UNITDATA REQ
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(ASP-Active)
N-CONNECT IND <------------- CORE (Source ref. number "A")
N-UNITDATA IND <------------- CLDT
diaggarwal(editor) [Page 85]
Internet Draft SUA Conformance Test Plan [Page 86]
COAK ------------>
(Dest ref. number "A") ---------> N-CONNECT CONFIRM IND
CODT ------------>
---------> N-DATA IND
(ref. number "A")
<--------- N-DATA REQ
N-DATA IND<------------- CODT
TEST DESCRIPTION:
1. Send ASPDN message to the SGP in ASP-active state.
Check A: Since this is the only ASP in the AS, the AS
should move to AS Pending State.
2. send N-CONNECT REQ destined to the ASP.
Check A: The CORE Message should not be sent to the ASP.
3. send N-UNITDATA REQ destined to the ASP.
Check A: The CLDT Message should not be sent to the ASP.
4. send ASPAC Message to the SGP, before the timer t(r)=2
Seconds expires.
Check A: The CORE and the CLDT Messages should now reach
the SGP.
5. send COAK Message to the SGP.
Check A: The COAK Message should reach the SGP, and the connection
should be established.
6. send CODT Messages in both directions.
Check A: The CODT Messages should reach the both ends.
diaggarwal(editor) [Page 86]
Internet Draft SUA Conformance Test Plan [Page 87]
4.7.2 "Validation of AS pending Behavior : recovery Failure"
+ TEST NUMBER: 7.2
+ PURPOSE: To check that if an asp transitions to ASP-DOWN or ASP-INACTIVE
state and it the last active ASP in the AS the AS Moves to
AS Pending State, and if the AS Buffers messages for the ASPs
for a timer duration of Tr = 2 seconds and after the timer
t(r) expiry, it discards all the messages, and move to
appropriate state.
a) move to AS Inactive : if at least one ASP is in ASP-
INACTIVE state.
b) else move to AS-Down State.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP (with two or more streams. ASP is active.
The AS Should be having one and only one ASP.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is Active
ASPDN ---------------->
Status Ind ------->
(Since this is the last Active ASP
in the AS the AS moves to pending state)
Status Ind ------->
(timer tr=2 seconds starts)
<<Messages are buffered>> <--------- N-CONNECT REQ
<<Messages are buffered>> <--------- N-UNITDATA REQ
(timer tr=2 seconds Expires)
a) At least 1 ASP Is INACTIVE.
(AS Moves to AS-INACTIVE State)
Status Ind ------->
b) All the Concerned ASPs are in DOWN State.
diaggarwal(editor) [Page 87]
Internet Draft SUA Conformance Test Plan [Page 88]
(AS Moves to AS-DOWN State)
Status Ind ------->
TEST DESCRIPTION:
1. Send ASPDN message to the SGP in ASP-active state.
Check A: Since this is the only ASP in the AS, the AS
should move to AS Pending State.
2. send N-CONNECT REQ destined to the ASP.
Check A: The CORE Message should not be sent to the ASP.
3. send N-UNITDATA REQ destined to the ASP.
Check A: The CLDT Message should not be sent to the ASP.
Check B: The Timer T(r) will expire on the SGP Side.
Check C: The AS Should move to AS-INACTIVE state if
at least 1 ASP is active else it will move to
AS-DOWN state.
The above test case MUST be carried out for both AS-INACTIVE
and AS-DOWN Transitions.
diaggarwal(editor) [Page 88]
Internet Draft SUA Conformance Test Plan [Page 89]
4.7.3 "Handling of SCTP-CDI and SCTP-RI"
+ TEST NUMBER: 7.3
+ PURPOSE: To check that if the Underlying SCTP layer gives
an SCTP-CDI or an SCTP-RI, the ASP moves to ASP-DOWN.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP, ASP and IPSP. The example listed below covers the IUT
running at the ASP. However the same must be executed at the
SGP and the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP (with two or more streams. ASP is active.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
ASP is Active
<-----SCTP-CDI/SCTP-RI
M-SCTP_STATUS IND <-----
(ASP Moves to ASP-DOWN State)
TEST DESCRIPTION:
1. Generate an SCTP-CDI Indication from the SCTP layer.
Check A: The ASP Should move to the ASP-DOWN State.
The Above test case MUST be carried out for SCTP-CDI and SCTP-RI.
diaggarwal(editor) [Page 89]
Internet Draft SUA Conformance Test Plan [Page 90]
4.7.4 "Handling of Invalid messages at ASP and SGP"
+ TEST NUMBER: 7.4
+ PURPOSE: To check that if the ASP receives an ASP-UP
message it discards the message.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
ASP. The example listed below covers the IUT running at
the ASP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP (with two or more streams.
EXPECTED MESSAGE SEQUENCE:
ASP SGP NIF
<--------------- ASP-UP
<------------
ERROR
TEST DESCRIPTION:
1. Generate an ASP-UP Message to be destined to the ASP.
Check A: The ASP Should discard this message and report
an error to SM.
The Above test case MUST be carried out for the following combinations
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Stack Message to be Rejected
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ASP ASPUP
ASPDN
ASPAC
ASPIA
NTFY
DAUD
REG_REQ
DEREG_REQ
BEAT
BEAT_ACK
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diaggarwal(editor) [Page 90]
Internet Draft SUA Conformance Test Plan [Page 91]
SGP DUNA
DAVA
SCON
DUPU
ASPUP_ACK
ASPDN_ACK
ASPAC_ACK
ASPIA_ACK
REG_RSP
DEREG_RSP
BEAT
BEAT_ACK
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diaggarwal(editor) [Page 91]
Internet Draft SUA Conformance Test Plan [Page 92]
4.7.5 "Dynamic registration of Routing Key Success"
+ TEST NUMBER : 7.5
+ PURPOSE: To check the Dynamic Registration procedures for Routing
Keys.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP and IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and AS and AS is in AS-Down state i.e. ASP1 is ACTIVE. SGP
has Routing Key already added as RK1 and Routing Context
as RC1.
EXPECTED MESSAGE SEQUENCE:
ASP SGP SM + NIF
CLDT ------------->
(Routing Context RC2) ---------> ERROR
<--------------- ERR(Invalid Routing Context = 0x10)
REG_REQ ---------------->
(Routing Key RK2) Status Ind ------->
(The New Routing Key RK2 and an
AS is created, the ASP is added in
this AS.
<--------------- REG_RSP
(Routing Context RC2)
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Inactive-Ack
<--------------- NTFY(ASP-Inactive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(ASP-Active)
diaggarwal(editor) [Page 92]
Internet Draft SUA Conformance Test Plan [Page 93]
CLDT ------------->
(Routing Context RC2) ---------> N-UNITDATA IND
<--------- N-UNITDATA REQ
(Routing Context RC2)
N-UNITDATA IND <------------- CLDT
(Routing Context RC2)
ASPIA ---------------->
(Routing Context RC2) Status Ind ------->
<--------------- ASP-Inactive-Ack
(Routing Context RC2)
<--------------- NTFY(ASP-Inactive)
DEREG_REQ ---------------->
(Routing Key RK2) Status Ind ------->
(The ASP related to the Routing Key
RK2 is deleted from the AS.
<--------------- DEREG_RSP
(Routing Context RC2)
CLDT ------------->
(Routing Context RC2) ---------> ERROR
<--------------- ERR(Invalid Routing Context = 0x10)
TEST DESCRIPTION:
1. Send a CLDT message from the ASP Side, with Routing Context as RC2.
Check A: CLDT Message with Routing Context RC2 should reach the SGP.
Check B: An ERROR indication should be given to SM.
Check C: An ERR Message should be sent to the peer ASP with error code
as "Invalid Routing Context" = 0x10.
2. Send a N-REG REQ from the ASP Side, with Routing Context as RC2.
Check A: A Status indication should be given to SM.
Check B: The SGP MAY create the new Routing key, and if an Appropriate
AS is not found, then a New AS is created and this
ASP is added in the newly created AS.
Check C: A REG_RSP Message should be received at the ASP with the new
Routing Context as RC2.
diaggarwal(editor) [Page 93]
Internet Draft SUA Conformance Test Plan [Page 94]
3. send ASPUP Message to the SGP.
Check A: ASPUP_ACK message MUST be sent in response to the UP message.
4. send ASPAC Message to the SGP.
Check A: ASPAC_ACK message MUST be sent in response to the UP message.
5. Send a N-UNITDATA REQ from the ASP Side, with Routing Context as RC2.
Check A: CLDT Message with Routing Context RC2 should reach the SGP.
Check B: An N-UNITDATA IND Should be given.
6. Send a N-DEREG REQ from the ASP Side, with Routing Key as RK2.
Check A: A Status indication should be given to SM.
7. Send a N-UNITDATA REQ from the ASP Side, with Routing Context as RC2.
Check A: CLDT Message with Routing Context RC2 should reach the SGP.
Check B: An ERROR indication should be given to SM.
Check C: An ERR Message should be sent to the peer ASP with error code
as "Invalid Routing Context" = 0x10.
diaggarwal(editor) [Page 94]
Internet Draft SUA Conformance Test Plan [Page 95]
4.7.6 "ASPUP_ACK message wait state"
+ TEST NUMBER : 7.6
+ PURPOSE: To check that if ASPUP message is sent to the SGP, then
The ASP should discard any other message, till an
ASPUP_ACK message is received.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the
data in AS such that ASPUP message is sent to the SGP two
times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Down
ASPUP ---------------->
Status Ind ------->
REG_REQ ---------------->
<------------
ERROR
ASPAC ---------------->
<------------
ERROR
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Down state. ASP-Up-Ack and
NTFY (AS-Up) message will come from the SGP. Send ASPUP message
again from the AS for the same ASP.
2. send a REG_REQ message from the ASP, before it gets an ASPUP_ACK
message from the SGP.
Check A: The ASP Should get an Error Indication
The above test case should be applicable to all the SUA MGMT messages
The ASP Should not send any Messages across unless until an ASPUP_ACK
diaggarwal(editor) [Page 95]
Internet Draft SUA Conformance Test Plan [Page 96]
message is received, after sending an ASPUP message.
diaggarwal(editor) [Page 96]
Internet Draft SUA Conformance Test Plan [Page 97]
4.7.7 "ASPUP message in ASP-Up state"
+ TEST NUMBER : 7.7
+ PURPOSE: To check that if ASPUP message is received in ASP-Up state
then message with ASP-Up-Ack is sent to the AS.
+ TEST CONFIGURATION: The Following test cases MUST ONLY be executed at
SGP and IPSP. The example listed below covers the test
case at the SGP. The IUT is running at the SGP. However the
same MUST be executed at IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange
the data in AS such that ASPUP message is sent to the
SGP two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Down
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
ASPUP ---------------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(ASP-Active)
ASPIA ---------------->
Status Ind ------->
<--------------- ASPIA-Ack
<--------------- NTFY(ASP-Inactive)
diaggarwal(editor) [Page 97]
Internet Draft SUA Conformance Test Plan [Page 98]
ASPDN ---------------->
Status Ind ------->
<--------------- ASPDN-Ack
<--------------- NTFY(ASP-DN)
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Down state. ASP-Up-Ack and
NTFY (AS-Up) message will come from the SGP. Send
ASPUP message again from the AS for the same ASP.
Check A: ASP-Up-Ack message should be received at AS.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains in
the Up state.
2. Send ASPAC message with valid Type and Routing Context
Check A: ASP-Active-Ack message should be received at the AS.
3. Send ASPIA message to the SGP in ASP-Active state.
Check A: ASPIA-Ack and NTFY (AS-IA) messages will come
from the SGP.
4. Send ASPDN message to the AS for the same ASP.
Check A: ASPDN-ACK and NTFY(AS-DN) messages will come from SGP.
diaggarwal(editor) [Page 98]
Internet Draft SUA Conformance Test Plan [Page 99]
4.7.8 "ASPUP message for an ASP which is in LOCKED state"
+ TEST NUMBER : 7.8
+ PURPOSE: To check that if ASPUP message is received for an ASP,
which has been marked as LOCKED for MGMT purposes, the SGP
sends an error message with error code "Refused -
Management Blocking".
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange
the data in AS such that ASPUP message is sent to the SGP
two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Down
<--------- LOCK ASP
ASPUP ---------------->
Status Ind ------->
<--------------- ERR(Refused - Management Blocking)
<------------
ERROR
TEST DESCRIPTION:
1. Lock the ASP on the SGP side for MGMT purposes.
2. Send ASPUP message to the SGP in ASP-Down state. ASP-Up-Ack and
NTFY (AS-Up) message will come from the SGP.
Send ASPUP message again from the AS for the same ASP.
2. Check A: an ERROR Message should be sent in response to the ASPUP
message with error code "Refused - Management Blocking".
diaggarwal(editor) [Page 99]
Internet Draft SUA Conformance Test Plan [Page 100]
4.7.9 "ASPUP message in ASP-ACTIVE state"
+ TEST NUMBER : 7.9
+ PURPOSE: To check that if ASPUP message is received in ASP-ACTIVE state
then message ASP-Up-Ack is sent to the AS, and the ASP state
is changed in all the relevant AS.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP is ACTIVE.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- ERR(Unexpected message)
(ASP State Changes to INACTIVE in all
the AS it belongs to)
TEST DESCRIPTION:
1. Send ASPUP message to the SGP in ASP-Active state.
Check A: ASP-Up-Ack message should be received at AS.
Check B: State of ASP at SGP Should change to ASP-INACTIVE.
Check C: An ERR message with error code "Unexpected message"
should be received at the ASP.
diaggarwal(editor) [Page 100]
Internet Draft SUA Conformance Test Plan [Page 101]
4.7.10 "ASPDN-ACK message in ASP-Active state"
+ TEST NUMBER : 7.10
+ PURPOSE: To check that if ASPDN-ACK message is received in ASP-Active state
then the ASP Should move to ASP-Down, and the procedure
to bring the ASP into ASP-ACTIVE state should be initiated
by the ASP itself.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
<--------------- ASPDN-Ack
(ASP SHOULD Move to Down State)
<<<< ASP Should Initiate the procedures to bring itself to it's
previous State >>>>
ASPUP ---------------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(ASP-Active)
TEST DESCRIPTION:
1. Send ASPDN-ACK message to the ASP in ASP-Active state.
Check A: ASP Should move to ASP-Down State.
Check B: The ASP Should Now initiate Procedures to bring itself
to it's previous state.
diaggarwal(editor) [Page 101]
Internet Draft SUA Conformance Test Plan [Page 102]
2. the ASP Sends ASPUP message to the SGP in ASP-Down state.
Check A: ASP-Up-Ack and NTFY (AS-Up) messages will come from the SGP.
3. The ASP Sends ASPUP message for the same ASP.
Check A: ASP-Up-Ack message should be received at AS.
Check B: State of ASP at SGP is now ASP-ACTIVE.
diaggarwal(editor) [Page 102]
Internet Draft SUA Conformance Test Plan [Page 103]
4.7.11 "ASPDN-ACK message in ASP-INACTIVE state"
+ TEST NUMBER : 7.11
+ PURPOSE: To check that if ASPDN-ACK message is received in
ASP-INACTIVE state then the ASP Should move to
ASP-Down, and the Procedure to bring the ASP into
ASP-INACTIVE State is initiated by the ASP itself.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
ASP/IPSP. The example listed below covers the IUT
running at the ASP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is INACTIVE
<--------------- ASPDN-Ack
(ASP SHOULD Move to Down State)
<<<< ASP Should Initiate the procedures to bring itself to it's
previous State >>>>
ASPUP ---------------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-Inactive)
TEST DESCRIPTION:
1. Send ASPDN-ACK message to the ASP in ASP-Active state.
Check A: ASP Should move to ASP-Down State.
Check B: The ASP Should Now initiate Procedures to bring itself
to it's previous state.
2. the ASP Sends ASPUP message to the SGP in ASP-Down state.
Check A: ASP-Up-Ack and NTFY (AS-Up) messages will come from the SGP.
Check B: No ASP-Active procedure should be initiated by the ASP.
Check C: State of ASP at SGP is now ASP-INACTIVE.
diaggarwal(editor) [Page 103]
Internet Draft SUA Conformance Test Plan [Page 104]
4.7.12 "Data message in ASP-INACTIVE state"
+ TEST NUMBER : 7.12
+ PURPOSE: To check that if Data message is received in
ASP-INACTIVE state then the ASP MAY discard the message.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
ASP/IPSP. The example listed below covers the IUT running
at the ASP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is INACTIVE
<------------- CORE (Source ref. number "A")
a) (The ASP MAY SILENTLY DISCARD this Message)
b) (the ASP MAY Entertain this message)
<------------
N-CONNECT IND
TEST DESCRIPTION:
1. Send CORE message to the ASP in ASP-Inactive state.
2. The ASP MAY Discard this message in this case it Should send
an Error indication to the SM.
3.The ASP May entertain this message and give an indication to
the SM.
diaggarwal(editor) [Page 104]
Internet Draft SUA Conformance Test Plan [Page 105]
4.7.13 "Invalid Routing Context in ASP-Active Message"
+ TEST NUMBER : 7.13
+ PURPOSE: To check that if ASPAC message carries multiple Routing
Contexts, and the SGP cannot Activate One of the Routing
Context, then the SGP MUST Send ERROR Message for each
Routing Context value that cannot be successfully activated.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is INACTIVE
ASPAC ---------------->
(RC1, RC2, RC3)
<--------------- ASPAC-Ack
(RC1)
<--------------- NTFY(ASP-Active)
<--------------- ERR(Invalid Routing Context
RC2)
<------------
ERROR
<--------------- ERR(Invalid Routing Context
RC3)
<------------
ERROR
TEST DESCRIPTION:
1. Send ASPAC message(With 3 Routing Contexts
Routing Context RC1 should be a valid value
Routing Context RC2 should be a INVALID value
Routing Context RC3 should be a INVALID value)
to the SGP in ASP-Inactive state.
Check A: ASP Should move to ASP-Active State.
diaggarwal(editor) [Page 105]
Internet Draft SUA Conformance Test Plan [Page 106]
Check B: The SGP Should Now send ASPAC-ACK Message in response
to the ASPAC message(For Routing Context RC1).
Check C: The SGP MUST Send individual ERROR messages for the Routing
Context RC2 and RC3.
diaggarwal(editor) [Page 106]
Internet Draft SUA Conformance Test Plan [Page 107]
4.7.14 "ASPAC Message Out-Of-The-Blue"
+ TEST NUMBER : 7.14
+ PURPOSE: To check that if ASPAC message is received at the SGP
end, for an ASP the SGP has no knowledge of, the SGP
MAY Discard this message silently.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Not Registered with SGP
ASPAC ---------------->
(No reaction)
TEST DESCRIPTION:
1. Send ASPAC message to the SGP with ASP-ID, which has not been
registered with ASP.
Check A: ASP Should discard this message silently.
diaggarwal(editor) [Page 107]
Internet Draft SUA Conformance Test Plan [Page 108]
4.7.15 "Invalid Traffic mode in ASP-Active Message"
+ TEST NUMBER : 7.15
+ PURPOSE: To check that if ASPAC message carries a Traffic mode
which is incompatible at the SGP, then an error message
with code "Unsupported / Invalid Traffic Handling Mode"
MUST be sent..
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and ASP. The AS to which the ASP belongs MUST be
configured at the SGP with mode as OVERIDE).
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is INACTIVE with traffic mode as Override
ASPAC ---------------->
(Traffic mode= Loadshare)
<--------------- ERR(Unsupported /
Invalid Traffic Handling Mode)
<------------
ERROR
TEST DESCRIPTION:
1. Send ASPAC message(With Traffic mode as Loadshare)
to the ASP in ASP-Inactive state.
Check A: SGP Should send an error message with error code
"Unsupported / Invalid Traffic Handling Mode".
The Above test case should also be carried out for ASP-INACTIVE message.
diaggarwal(editor) [Page 108]
Internet Draft SUA Conformance Test Plan [Page 109]
4.7.16 "Alternative ASP-ACTIVE in Override Mode"
+ TEST NUMBER : 7.16
+ PURPOSE: To check that if ASPAC message is sent to an AS
which carries an already active ASP, then all the
new traffic should be directed to this ASP and the SGP
MUST send a NTFY message with code "Alternate ASP Active "
to the other ASP.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP. The example listed below covers the IUT running at
the SGP.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. The AS to which the ASP belongs MUST be configured
at the SGP with mode as OVERIDE). ASP1 is active and
handling Traffic.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP1 is ACTIVE and Handling traffic
ASPAC ---------------->
(ASP 2 Sends ASPAC)
<--------------- ASPAC-Ack
<--------------- NTFY(Alternate ASP Active)
TEST DESCRIPTION:
1. Send ASPAC message for ASP2 to the SGP.
Check A: All the Traffic henceforth MUST be routed to ASP2, and
the ASP1 should be made as INACTIVE in the AS, and
a NTFY Message MUST be generated to the Previous
ACTIVE ASP, with code "Alternate ASP Active ".
diaggarwal(editor) [Page 109]
Internet Draft SUA Conformance Test Plan [Page 110]
4.7.17 "Loadshare Mode for ASP"
+ TEST NUMBER : 7.17
+ PURPOSE: To verify that if an AS is configured to operate in
Loadshare mode, then any data should be distributed
amongst all the ASPs present in that AS.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. The AS to which the ASP1, ASP2, ASP3 belongs
MUST be configured at the SGP with mode as LOADSHARE).
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
(AS is in Loadshare Mode
with ASP1, ASP2 and ASP3
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
TEST DESCRIPTION:
1. Send Several N-UNITDATA REQs from the SGP.
Check A: The Data MUST be distributed amongst the Three ACTIVE
ASPs(the mechanism for Distribution is implementation
dependent).
Repeat the Above test case after moving one of the ACTIVE ASPs
to INACTIVE State(An Additional NTFY Message MAY be generated
with code "Insufficient ASP resources active in AS", to inform
the other ASPs).
diaggarwal(editor) [Page 110]
Internet Draft SUA Conformance Test Plan [Page 111]
4.7.18 "Broadcast Mode for ASP"
+ TEST NUMBER : 7.18
+ PURPOSE: To verify that if ASPs are operating in Broadcast mode
all the Data MUST be sent to all the Active ASPs.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP. The AS to which the ASP1, ASP2, ASP3 belongs MUST
be configured at the SGP with mode as BROADCAST.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
(AS is in BROADCAST Mode
with ASP1, ASP2 and ASP3
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
(ASP1)
N-UNITDATA IND <------------- CLDT
(ASP2)
N-UNITDATA IND <------------- CLDT
(ASP3)
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
(ASP1)
N-UNITDATA IND <------------- CLDT
(ASP2)
N-UNITDATA IND <------------- CLDT
(ASP3)
TEST DESCRIPTION:
1. Send Several N-UNITDATA REQs from the SGP.
Check A: The Data MUST be sent to ALL the ACTIVE ASPs(ASP1,
ASP2 and ASP3).
Repeat the Above test case after moving one of the ACTIVE ASPs
to INACTIVE State(An Additional NTFY Message MAY be generated
with code "Insufficient ASP resources active in AS", to inform
the other ASPs).
diaggarwal(editor) [Page 111]
Internet Draft SUA Conformance Test Plan [Page 112]
4.7.19 "Broadcast Mode for ASP, Unique Correlation ID"
+ TEST NUMBER : 7.19
+ PURPOSE: To verify that if ASPs are operating in Broadcast mode
the SGP MUST tag the first DATA message broadcast
in each SCTP stream with a unique Correlation Id parameter.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP. The AS to which the ASP1, ASP2, ASP3 belongs MUST
be configured at the SGP with mode as BROADCAST.
EXPECTED MESSAGE SEQUENCE :
ASP SGP NIF
(AS is in BROADCAST Mode
with ASP1, ASP2 and ASP3
as the ACTIVE ASPs )
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
(ASP1, Correlation ID = X)
N-UNITDATA IND <------------- CLDT
(ASP2, Correlation ID = Y)
N-UNITDATA IND <------------- CLDT
(ASP3, Correlation ID = Z)
<--------- N-UNITDATA REQ
N-UNITDATA IND <------------- CLDT
(ASP1, Correlation ID = A)
N-UNITDATA IND <------------- CLDT
(ASP2, Correlation ID = B)
N-UNITDATA IND <------------- CLDT
(ASP3, Correlation ID = B)
TEST DESCRIPTION:
1. Send Several N-UNITDATA REQs from the SGP.
Check A: The Data MUST be sent to ALL the ACTIVE ASPs(ASP1,
ASP2 and ASP3).
Check B: The Correlation ID, for the FIRST DATA message
MUST BE DIFFERENT for all the ASPs).
Check C: The consecutive Correlation IDs MAY be same.
diaggarwal(editor) [Page 112]
Internet Draft SUA Conformance Test Plan [Page 113]
4.7.20 "ASPIA-ACK message in ASP-Active state"
+ TEST NUMBER : 7.20
+ PURPOSE: To check that if ASPIA-ACK message is received in
ASP-Active state then the ASP Should move to ASP-INACTIVE,
and the procedure to bring the ASP into ASP-ACTIVE state
should be initiated by the ASP itself.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
ASP.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
<--------------- ASPIA-Ack
(ASP SHOULD Move to INACTIVE State)
<<<< ASP Should Initiate the procedures to bring itself to it's
previous State >>>>
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(ASP-Active)
TEST DESCRIPTION:
1. Send ASPIA-ACK message to the ASP in ASP-Active state.
Check A: ASP Should move to ASP-INACTIVE State.
Check B: The ASP Should Now initiate Procedures to bring itself
to it's previous state.
2. The ASP Sends ASPUP message for the same ASP.
Check A: ASP-Up-Ack message should be received at AS.
Check B: State of ASP at SGP is now ASP-ACTIVE.
diaggarwal(editor) [Page 113]
Internet Draft SUA Conformance Test Plan [Page 114]
4.7.21 "Last ASP Transition to INACTIVE state"
+ TEST NUMBER : 7.21
+ PURPOSE: To check that if an AS has only 1 ASP in the ACTIVE Mode,
and it moves to ASP-INACTIVE state, it MUST send a Notify
message ("AS-Pending") to all of the ASPs in the AS
which are in the state ASP-INACTIVE.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP
and ASP.AS has three ASPs, ASP1 is in ACTIVE State,
ASP2 is in INACTIVE State and the ASP3 are in DOWN State.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASPIA ---------------->
Status Ind ------->
<--------------- ASPIA-Ack
<--------------- NTFY(AS-Pending)
TEST DESCRIPTION:
1. Send ASPIA message to the SGP in ASP-Active state.
Check A: ASP Should move to ASP-INACTIVE State.
Check B: The AS Should now move to AS PENDIND State and
a NTFY message with AS-Pending should be sent to
ASP2.
Check C: The NYFY Message MUST not be sent to ASP3, since
it is in DOWN State.
diaggarwal(editor) [Page 114]
Internet Draft SUA Conformance Test Plan [Page 115]
4.7.22 "ASPDN message in ASP-Down state"
+ TEST NUMBER : 7.22
+ PURPOSE: To check that if ASPDN message is received in ASP-Down
state then ASP-Down-Ack message is sent to the AS.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange
the data in AS such that ASPDN message is sent to the SGP
two times with the valid Reason Parameter on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Up
ASPDN ---------------->
Status Ind ------->
<--------------- ASP-Down-Ack
<--------------- NTFY(AS-Down)
ASPDN ---------------->
<--------------- ASP-Down-Ack
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
TEST DESCRIPTION:
1. Send ASPDN message to the SGP in ASP-Up state. ASP-Down-Ack and
NTFY (AS-Down) messages will come from the SGP. Send ASPDN
message again from the AS for ASP1.
Check A: ASP-Down-Ack message should be received at AS.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the
Down state. Send ASPUP message for the ASP,ASP-Up-Ack
and NTFY with status AS-Up should come.
diaggarwal(editor) [Page 115]
Internet Draft SUA Conformance Test Plan [Page 116]
Note: NTFY message with AS status may come before the NTFY message with
ASP status.
diaggarwal(editor) [Page 116]
Internet Draft SUA Conformance Test Plan [Page 117]
4.7.23 "ASPAC message in ASP-Active state"
+ TEST NUMBER : 7.23
+ PURPOSE: To check that if ASPAC message is received in ASP-Active
state then ASP-Active-Ack message is sent to the AS.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange
the data in AS such that ASPAC message with correct Type
(Type is same as defined at SGP for the AS) and routing
context P is sent to the SGP two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Up
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
ASPAC ---------------->
<--------------- ASP-Active-Ack
DATA ---------------->
N-DATA Ind ------->
TEST DESCRIPTION:
1. Send ASPAC message to the SGP in ASP-Up state. ASP-Active-Ack
message will come from the SGP. Send ASPAC message
again from the AS for the same ASP.
2. Check A: ASP-Active-Ack message should be received at ASP.
3. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the
Active state. Send DATA message for the ASP and SGP should send
N-DATA indication to the NIF.
diaggarwal(editor) [Page 117]
Internet Draft SUA Conformance Test Plan [Page 118]
4.7.24 "ASPIA message in ASP-Up state"
+ TEST NUMBER : 7.24
+ PURPOSE: To check that if ASPIA message is received in ASP-Up state
then ASP-Inactive-Ack message is sent to the AS.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Active state i.e. AS1 is active.
Arrange the data in AS such that ASPIA message with correct
Type(Type is same as defined at SGP for the AS) and Routing
Context P is sent to the SGP two times on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Active
ASPIA ---------------->
Status Ind ------->
<--------------- ASP-Inactive-Ack
ASPIA ---------------->
<--------------- ASP-Inactive-Ack
ASPAC ---------------->
Status Ind ------->
<--------------- ASP-Active-Ack
<--------------- NTFY(AS-Active)
TEST DESCRIPTION:
1. Send ASPIA message to the SGP in ASP-Active state. ASP-Inactive-Ack
and NTFY (AS-Pending) messages will come from the SGP.
Send ASPIA message again from the AS for the same ASP.
Check A: ASP-Inactive-Ack message will come from SGP.
Check B: State of ASP at SGP is not disturbed i.e. ASP remains
in the Inactive state. Send ASPAC message with
diaggarwal(editor) [Page 118]
Internet Draft SUA Conformance Test Plan [Page 119]
correct Type ((Type is same as defined at SGP for
the AS) for the ASP1 and SGP should respond with
ASP-Active-Ack message.
diaggarwal(editor) [Page 119]
Internet Draft SUA Conformance Test Plan [Page 120]
4.7.25 "ASPAC message in ASP-Down state"
+ TEST NUMBER : 7.25
+ PURPOSE: To check that if ASPAC message is received in ASP-Down
state then message is discarded.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and AS is in AS-Down state i.e. ASP1 is down. Arrange
the data in AS such that ASPAC message with correct Type
(Type is same as defined at SGP for the AS) and routing
context P is sent to the SGP on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
AS is Down
ASPAC ---------------->
<--------------- NTFY(ASP-Down)
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
TEST DESCRIPTION:
1. Send ASPAC message to the SGP 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 SGP is not disturbed i.e. ASP remains in the
Down state. Send ASPUP message for the ASP and SGP
should respond with ASP-Up-Ack and NTFY message with
status AS Inactive.
4. Repeat the above test case for ASPIA message.
diaggarwal(editor) [Page 120]
Internet Draft SUA Conformance Test Plan [Page 121]
4.7.26 "ASPDN message in ASP-Active state"
+ TEST NUMBER : 7.26
+ PURPOSE: To check that if ASPDN message is received in ASP-Active
state then ASP-Down-Ack message is sent to AS and State
of ASP at SGP becomes ASP-Down.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and ASP1 is Active. Arrange the data in AS such
that ASPUP message with valid Reason parameter is sent
to the SGP on stream 0.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
ASPDN ---------------->
Status Ind ------->
<--------------- ASP-Down-Ack
ASPUP ---------------->
Status Ind ------->
<--------------- ASP-Up-Ack
<--------------- NTFY(ASP-InActive)
TEST DESCRIPTION:
1. Send ASPDN message to the SGP in ASP-Active state.
2. Check A: ASP-Down-Ack message is received at ASP.
3. Check B: State of ASP should become Down. Send ASPUP message
to the SGP and SGP should send ASP-Up-Ack and NTFY with Status
ASP-Inactive.
diaggarwal(editor) [Page 121]
Internet Draft SUA Conformance Test Plan [Page 122]
4.7.27 "Initiation of SSNM messages"
+ TEST NUMBER : 7.27
+ PURPOSE: To check that if N-STATE primitive is issued at an SGP,
then the corresponding SSNM message is issued to the
concerned ASP.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
ASP/IPSP. The example listed below covers the IUT running at
the ASP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between SGP and
AS and ASP1 is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
N-PCSTATE IND <------------- DUNA
(DPC "X" unavailable)
DAUD ---------------->
DAUD ---------------->
DAUD ---------------->
N-PCSTATE IND <------------- DUVA
(DPC "X" Available)
TEST DESCRIPTION:
1. Send a DUNA message from the SGP indicating the Unavailability
of a PC "X".
Check A: DUNA message should be received at the ASP.
Check B: The ASP Should start issuing DAUD on regular intervals.
2. Send a DAVA message indicating the availability of PC "X".
Check A: Dava Message should be received at the ASP.
Check B: no more DAUD Messages should be sent by the ASP.
diaggarwal(editor) [Page 122]
Internet Draft SUA Conformance Test Plan [Page 123]
4.7.28 "Receiving SCON message"
+ TEST NUMBER : 7.28
+ PURPOSE: To check that if a SCON Message is received , the SUA
informs it's user by an appropriate method.
+ TEST CONFIGURATION: The Following test cases MUST be executed at
SGP/IPSP. The example listed below covers the IUT running at
the SGP. However the same must be executed at the IPSP also.
+ PRE-TEST CONDITIONS: SCTP association is established between
SGP and AS and ASP1 is Active.
EXPECTED MESSAGE SEQUENCE :
ASP SGP SM + NIF
ASP is Active
SCON ---------------->
Status Ind ------->N-INFORM IND
TEST DESCRIPTION:
1. Send an SCON message from the ASP side to the SGP side.
Check A: SCON message should be received at the SGP.
Check B: The SUA User is informed by means of an N-INFORM IND.
diaggarwal(editor) [Page 123]
Internet Draft SUA Conformance Test Plan [Page 124]
5 Acknowledgements
The authors would like to thank (in alphabetical order)
Anjali Gurmukhani
Gayatri Singla
Harsh Bhondwe
Sanjay Kumar
Vipin Gupta
for their insightful comments and suggestions.
Funding for the RFC editor function is currently provided by the
Internet Society.
6 Authors' Addresses
Dipak Aggarwal
Hughes Software Systems
Electronic City, Plot 17,
Sector 18 , gurgaon 122015
Harayana, India
EMail: [email protected]
7 References
[2960] RFC 2960 "Stream Control Transport Protocol" R.
Stewart, et al, November 2000.
[ITU-MTP] ITU-T Recommendations Q.701-Q.705, 'Signaling System
No. 7 (SS7) - Message Transfer Part (MTP)'
[ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System
No. 7 (SS7) - Signaling Connection Control Part
(SCCP)'
[SUA] SCCP-User Adaptation Layer <draft-ietf-sigtran-sua-
08.txt>, October 2001, Work in Progress.
[M3UA-CONF] Test Specification for MTP3 User Adaptation <draft-
mahajan-test-spec-m3ua-00.txt>, July 2000, Work in
Progress.
diaggarwal(editor) [Page 124]
Internet Draft SUA Conformance Test Plan [Page 125]
Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
diaggarwal(editor) [Page 125]
| ||||||||||||||||
| Last modified: Thu, 28 Nov 2024 06:50:38 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||