| draft-hss-sigtran-sua-conformance08 Description: Request For Comments
You 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) |
Documentation