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 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 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 -------> <> 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) <> <--------- N-CONNECT REQ <> <--------- 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) <> <--------- N-CONNECT REQ <> <--------- 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: diaggarwal@hss.hns.com 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 , October 2001, Work in Progress. [M3UA-CONF] Test Specification for MTP3 User Adaptation , 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]