INTERNET-DRAFT Sunil Mahajan Prashant Singh Ashok.K.Singh Hughes Software Systems Feb, 2001 expires: Aug, 2001 Test Specification for MTP3 User Adaptation Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf. org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Sunil-Prashant-Ashok, HSS [Page 1] Internet Draft Test Specs for M3UA Feb 2001 Abstract This document presents the test specification for M3UA (MTP3 User Adaptation) protocol (ver 05), which can be used to test M3UA implementations for conformance to the protocol definition. The list of test is exhaustive and covers almost all the categories of test. This draft can also be used in conjunction with M3UA specification by implementers of protocol as implementers guide, as the pictorial representation of various scenarios help easy understanding of the protocol. Next revision of the draft will cover the additions done to the protocol revision and any subsequent RFC published by IETF. Table of Contents 1 Introduction------------------------------------------------4 1.1 Terms Used--------------------------------------------------4 2 General Principles of m3ua Tests----------------------------6 2.1 Presentation of Test Descriptions---------------------------6 2.1.1 Pre-Test Condition------------------------------------------7 3 Test Configurations-----------------------------------------7 3.1 Configuration for Testing the m3ua at SG--------------------7 3.2 Configuration for Testing The m3ua at AS--------------------11 4 Test Cases--------------------------------------------------14 4.1 Test cases for testing m3ua at SG---------------------------14 4.1.1 Send and Receive transfer primitive in AS Active state------14 4.1.2 Stream selection--------------------------------------------15 4.1.3 AS Management-----------------------------------------------16 4.1.4 MTP3 Management---------------------------------------------34 4.1.5 Invalid Message Handling------------------------------------40 4.1.6 Duplicate Message Handling----------------------------------49 4.1.7 ASPM messages when SG has locked out the ASP----------------58 4.1.8 Message Routing---------------------------------------------59 Sunil-Prashant-Ashok, HSS [Page 2] Internet Draft Test Specs for M3UA Feb 2001 4.1.9 Mode of Traffic Handling by ASP in ASPAC message------------64 4.1.10 Mode of Traffic Handling by ASP in ASPIA message------------76 4.1.11 ERROR Message Handling--------------------------------------77 4.1.12 SCTP Connection Management----------------------------------78 4.1.13 SPMC management---------------------------------------------80 4.2 Test Cases for Testing m3ua at AS---------------------------82 4.2.1 Send and receive of transfer primitive in AS Active state---82 4.2.2 Stream Selection--------------------------------------------83 4.2.3 SCTP Connection Management----------------------------------84 4.2.4 AS Management-----------------------------------------------86 4.2.5 Invalid Message Handling------------------------------------90 4.2.6 SSNM Message Handling---------------------------------------96 4.2.7 Duplicate Message Handling---------------------------------105 4.2.8 ERROR Handling---------------------------------------------107 4.2.9 ASP in more than one AS------------------------------------108 4.2.10 SG Redundancy----------------------------------------------109 5 Acknowledgement--------------------------------------------111 6 Authors address--------------------------------------------111 7 References-------------------------------------------------111 Sunil-Prashant-Ashok, HSS [Page 3] Internet Draft Test Specs for M3UA Feb 2001 1 Introduction The M3UA is a protocol for the transport of any SS7 MTP3-User signaling (e.g. ISUP and SCCP messages) over IP using the Stream Control Transport Protocol (SCTP) or any other suitable transport protocol. This protocol would be used between a Signaling Gateway (SG) and an Application Service Provider (ASP) (e.g. Media Gateway Controller - MGC) or IP-resident Database. 1.1 Terms Used Application Server (AS) - A logical entity serving a specific Routing Key. An example of an Application Server is a virtual switch element handling all call processing for a unique range of PSTN trunks, identified by an SS7 DPC/OPC/CIC_range. Another example is a virtual database element, handling all HLR transactions for a particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more unique Application Server Processes, of which one or more is normally actively processing traffic. Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or standby process of an Application Server (e.g., part of a distributed virtual switch or database element). Examples of ASPs are processes (or process instances of) MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP end-point and may be configured to process signaling traffic within more than one Application server. Association - An association refers to an SCTP association. The association provides the transport for the delivery of MTP3-User protocol data units and M3UA adaptation layer peer messages. 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 MU3A in a peer-to-peer fashion. Conceptually, an IPSP does not use the services of a signalling gateway. Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, standby or load-sharing process of a Signalling Gateway. Signalling Process - A process instance that uses M3UA to communicate with other signalling process. An ASP, a signalling gateway process and an IPSP are all signalling processes. Sunil-Prashant-Ashok, HSS [Page 4] Internet Draft Test Specs for M3UA Feb 2001 Routing Key: At the SG, the Routing Key describes a set of SS7 parameter/parameter-ranges that uniquely defines the range of signaling traffic configured to be handled by a particular Application Server. For example, where all traffic directed to a particular SS7 DPC, OPC and ISUP CIC_range(s) or SCCP SSN is to be sent to a particular Application Server, that SS7 data defines the associated Routing Key. Routing Keys are mutually exclusive in the sense that a received SS7 signaling message cannot be directed to more than one Routing Key. Also, a Routing Key cannot extend across more than a single SS7 DPC, in order to more easily support SS7 Management procedures. It is not necessary for the parameter ranges within a particular Routing Key to be contiguous. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks that are not represented by contiguous CIC values. Routing Context : An Application Server Process may be configured to process traffic within more than one Application Server. In this case, the Routing Context parameter is exchanged between the SG and the ASP, identifying the relevant Application Server. From the perspective of an ASP, the Routing Context uniquely identifies the range of traffic associated with a particular Application Server, which the ASP is configured to receive from the SG. There is a 1:1 relationship between a Routing Context value and a Routing Key at an SG. Therefore the Routing Context can be viewed as an index into an SG Table containing the SG Routing Keys. Fail-over - The capability to re-route signaling traffic as required to an alternate Application Server Process, or group of ASPs, within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Fail-back may apply upon the return to service of a previously unavailable Application Server Process. Signaling Point Management Cluster (SPMC): A complete set of Application Servers represented to the SS7 network under the same SS7 Point Code. SPMCs are used to sum the availability/congestion/ User_Part status of an SS7 destination point code that is distributed in the IP domain, for the purpose of supporting MTP3 management procedures at an SG. In some cases, the SG itself may also be a member of the SPMC. In this case, the SG availability/congestion/User_Part status must also be taken into account when considering any supporting MTP3 management actions. MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.). Sunil-Prashant-Ashok, HSS [Page 5] Internet Draft Test Specs for M3UA Feb 2001 Network Appearance: The Network Appearance identifies an SS7 network context for the purposes of logically separating the signaling traffic between the SG and the Application Server Processes over a common SCTP Association. An example is where an SG is logically partitioned to appear as an element in four separate national SS7 networks. A Network Appearance implicitly defines the SS7 Point Code(s), Network Indicator and MTP3 protocol type/variant/version used within a specific SS7 network partition. An physical SS7 route-set or link-set at an SG can appear in only one network appearance. The Network Appearance is not globally significant and requires coordination only between the SG and the ASP. Network Byte Order: Most significant byte first, a.k.a Big Endian. Layer Management: Layer Management is a nodal function in an SG or ASP that handles the inputs and outputs between the M3UA layer and a local management entity. Host - The computing platform that the ASP process is running on. Stream - A stream refers to an SCTP stream. 2 General Principles of M3UA Tests These tests aim to verify a given implementation of a protocol in accordance with the relevant draft. The specification is independent of a given implementation and does not generally imply any modification of the endpoint under test. However, it is recognized that certain tests require capabilities of the system that are not explicitly defined in the draft, and these capabilities may not be present in all implementations. As a consequence, certain tests may not be possible in all implementations. 2.1 Presentation of test descriptions Each test description includes the environment in which the point under test must be inserted in order to pass the test. Nine test configurations are defined (named A, B, C, D, E, F, G, H, I and J); 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.). Sunil-Prashant-Ashok, HSS [Page 6] Internet Draft Test Specs for M3UA Feb 2001 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. 3 Test Configurations: The set of tests described in this Recommendation assumes that the point under test is inserted in a test environment called "test configuration". 3.1 Presentation of test configurations: There are different configurations for testing the M3UA protocol. These configurations and hence test cases have been divided on the basis of M3UA at SG and M3UA at AS. 3.2 Configuration for testing the M3UA at SG/IPSP: 3.2.1 Configuration A: This simple configuration is used for all the procedures of tests concerning only one AS. Configuration A is shown in figure 1. AS is handling the traffic for routing context P and N/w Appearance A. AS is having only one ASP ASP1.Point Code of SG is Z. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN ------------- -------------- | SG/IPSP | | AS DPC = X | | under Test | | ------- | | DPC = Z |-------------------------------|--| ASP1 | | | | | ------- | ------------- -------------- Fig 1: Configuration A Sunil-Prashant-Ashok, HSS [Page 7] Internet Draft Test Specs for M3UA Feb 2001 3.2.2 Configuration B: This configuration is used for all the procedures of tests concerning one ASP in two AS which are handling traffic for both AS. Configuration B is shown in figure 2. AS1 is handling the traffic for routing context P and N/w Appearance A. AS2 is handling the traffic for routing context Q and N/w Appearance A. ASP1 is in both AS. Point Code of SG/IPSP is Z. Routing Context P and Q may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN -------------- | AS1 DPC X | ------------- | ------- | | |-------------------------------| | ASP1 | | | SG/IPSP | | ------- | | Under Test | -------------- | DPC Z | -------------- | |-------------------------------| AS2 DPC Y | ------------- | ------- | | | ASP1 | | | ------- | -------------- Fig 2: Configuration B Sunil-Prashant-Ashok, HSS [Page 8] Internet Draft Test Specs for M3UA Feb 2001 3.2.3 Configuration C: This configuration is used for all the procedures of tests concerning two or more ASP in one AS. Configuration C is shown in figure 3. AS is handling the traffic for routing context P and N/w Appearance A. ASP1 and ASP2 can be in FAIL-OVER mode or LOADSHARE mode of traffic handling. Point Code of SG/IPSP is Z. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN -------------- | AS DPC X | ------------- | ------- | | |-------------------------------|-| ASP1 | | | SG/IPSP | | ------- | | Under Test | | ------- | | DPC Z | | | ASP2 | | | |-------------------------------|- ------- | ------------- -------------- Fig 3: Configuration C ( Note: In test case 1.9.3 it is assumed that as is containing three ASPs) 3.2.4 Configuration D: This configuration is used for all the procedures of tests concerning two or more AS which are handling traffic for different network appearance and different routing context. Configuration D is shown in figure 4. AS1, AS2 are handling the traffic for N/w Appearance A and AS3 is handling traffic for N/w appearance B. AS1 is handling traffic for Routing Context P, AS2 is handling traffic for Routing Context Q and AS3 is handling traffic for Routing Context R. Sunil-Prashant-Ashok, HSS [Page 9] Internet Draft Test Specs for M3UA Feb 2001 -------------- | AS1 DPC X | ------------- | ------- | | |-------------------------------| | ASP1 | | | SG/IPSP | | ------- | | Under Test | -------------- | DPC Z | -------------- | |-------------------------------| AS2 DPC Y | ------------- -------+ | ------- | | | | ASP2 | | | | ------- | | -------------- | -------------- | | AS3 DPC T | +-----------------------|- ------- | | | ASP 3 | | | ------- | -------------- Fig 4: Configuration D 3.2.5 Configuration E: This configuration is used for all the procedures of tests concerning two AS which are handling traffic for two Routing Contexts. Configuration E is shown in figure 5. AS1 is handling the traffic for routing context P. AS2 is handling the traffic for Routing Context Q. ASP1 is in AS1 and ASP2 is in AS2. Routing Contexts are sharing the point code. -------------- | AS1 DPC X | ------------- | ------- | | |-------------------------------| | ASP1 | | | SG/IPSP | | ------- | | Under Test | -------------- | DPC Z | -------------- | |-------------------------------| AS2 DPC X | ------------- | ------- | | | ASP2 | | | ------- | -------------- Fig 5: Configuration E 3.2.6 Configuration F: This configuration is used for all the procedures of tests concerning AS serving different SIO. Configuration F is shown in figure 6. AS1 is handling the traffic for routing context P, AS2 is handling for routing context Q and AS3 for routing context R. All AS are handling traffic for N/w appearance A. Point Code of SG/IPSP is Z. AS1 and AS2 are serving the SIO ISUP but different CIC range and AS3 is serving the SIO SCCP. Sunil-Prashant-Ashok, HSS [Page 10] Internet Draft Test Specs for M3UA Feb 2001 -------------- | AS1 DPC X | ------------- | ------- | | |-------------------------------| | ASP1 | | | SG/IPSP | | ------- | | Under Test | -------------- | DPC Z | -------------- | |-------------------------------| AS2 DPC X | ------------- -------+ | ------- | | | | ASP2 | | | | ------- | | -------------- | -------------- | | AS3 DPC X | +-----------------------|- ------- | | | ASP 3 | | | ------- | -------------- Fig 6: Configuration F 3.3 Configuration for testing the M3UA at AS 3.3.1 Configuration G: This simple configuration is used for all the procedures of tests concerning only one SG/IPSP. Configuration G is shown in figure 7. Point Code of SG is Z. ASP is handling the traffic for routing context P. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN ------------- -------------- | ASP1 | | SG/IPSP | | under Test | | DPC = Z | | DPC = X |-------------------------------| | | | | | ------------- -------------- Fig 7: Configuration G Sunil-Prashant-Ashok, HSS [Page 11] Internet Draft Test Specs for M3UA Feb 2001 3.3.2 Configuration H: This configuration is used for all the procedures of tests concerning two SGs/IPSPs connected to the same ASP and handling traffic for the same DPCin the SEP network. Configuration H is shown in figure 8. SG1/IPSP1 and SG2/IPSP2are 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+CIC+SIO 3. DPC+SIO 4. DPC+SSN -------------- | SG1/IPSP1 | ------------- | DPC Y | | |-------------------------------| | | ASP1 | | | | Under Test | -------------- | DPC X | -------------- | |-------------------------------| SG2/IPSP2 | ------------- | DPC Z | | | | | -------------- Fig 8: Configuration H 3.3.3 Configuration I: This simple configuration is used for all the procedures of tests concerning one ASP in two AS. Configuration I is shown in figure 9. Point Code of SG/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+CIC+SIO 3. DPC+SIO 4. DPC+SSN Sunil-Prashant-Ashok, HSS [Page 12] Internet Draft Test Specs for M3UA Feb 2001 -------------- | Under Test | | AS1 DPC X | | ------- | ---------------- | | ASP1 | | ---------------------| | | ------- | | SG / IPSP | -------------- | | -------------- | DPC Z | | AS2 DPC Y | | | | ------- | ---------------------| | | | ASP1 | | ---------------- | ------- | | Under Test | -------------- Fig 9: Configuration I 3.3.4 Configuration J: This configuration is used for all the procedures of tests concerning two SGs/IPSPs connected to the same ASP.SG1 is handling trafic for Routing context P and SG2 is handling traffic for routing context P and Q. Configuration J is shown in figure 10. 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+CIC+SIO 3. DPC+SIO 4. DPC+SSN -------------- | SG1/IPSP1 | ------------- | DPC Y | | |-------------------------------| | | ASP1 | | | | Under Test | -------------- | DPC X | -------------- | |-------------------------------| SG2/IPSP2 | ------------- | DPC Z | | | | | -------------- Fig 10 : Configuration J Sunil-Prashant-Ashok, HSS [Page 13] Internet Draft Test Specs for M3UA Feb 2001 4 Test Cases 4.1 Test Cases for Testing M3UA at SG These test cases are used to test the M3UA at SG. "Send and Receive Transfer Primitive in AS Active State" + TEST NUMBER : 1.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.3.1 and 1.6 + TITLE : MTP-Transfer Primitive + SUBTITLE : Send and Receive Transfer Primitive in AS Active State + PURPOSE: To check that on receiving Transfer primitive from NIF, DATA message is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. ASP1 is active. Also arrange the data in SG such that upper layers send MTP-Transfer indication primitive to M3UA with data to be sent to DPC X and N/w Appearance A. EXPECTED MESSAGE SEQUENCE : ASP SG NIF a) ASP is Active <----------- MTP-Transfer <------------- DATA N/w appearance A b) DATA --------------> MTP-Transfer ---------> TEST DESCRIPTION: 1. Send Transfer Request Primitive from the NIF at SG side to send Protocol Data to the ASP1. 2. Check A: DATA message should be received at the ASP1 containing the data passed by the NIF and the Network Appearance. 3. Send DATA message from ASP containing Protocol Data and Network Appearance A that is known to SG. 4. Check B: Transfer primitive is received at the NIF with the Protocol Data. 5. Repeat the test step 3 if N/w Appearance parameter is not present in the DATA message sent from ASP to SG. Note: Network Appearance is an optional parameter. In some implementation this parameter will not be present in DATA message sent from SG to ASP. Sunil-Prashant-Ashok, HSS [Page 14] Internet Draft Test Specs for M3UA Feb 2001 "Stream Selection" + TEST NUMBER : 1.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 1.4.7 + TITLE : Stream Selection + SUBTITLE : Stream Selection + PURPOSE: To check that all the messages for the same call are sent on the same SCTP stream. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS with two or more streams. ASP1 is active. Also arrange the data in SG such that NIF send three or more Transfer indication primitive to M3UA with N/w Appearance A containing the Data with same CIC value to be sent to DPC X. EXPECTED MESSAGE SEQUENCE : ASP SG NIF ASP is active <--------- MTP-Transfer Check Stream id <------------- DATA Data with CIC X <--------- MTP-Transfer Check Stream id <------------- DATA Data with CIC X <--------- MTP-Transfer Check Stream id <------------- DATA Data with CIC X TEST DESCRIPTION: 1. Send three or more Transfer Request Primitive from the NIF at SG side to send Protocol Data to the ASP. In the Protocol Data CIC values should be same in all Transfer Request primitive assuming load sharing across streams is based on CIC. 2. Check A: DATA messages are received at the ASP1 containing the same Stream Sequence number. 3. Repeat the above test with same SLS value in Protocol Data in all Transfer Request primitive assuming load sharing across the streams is based on SLS. 4. Repeat the above test case with different CIC values and different SLS values. DATA messages should be sent on different streams. Note: How the messages will be distributed on different streams based on CIC and SLS is implementation dependent. Sunil-Prashant-Ashok, HSS [Page 15] Internet Draft Test Specs for M3UA Feb 2001 "Transfer Request Primitive from NIF in AS Inactive State" + TEST NUMBER : 1.3.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5 + TITLE : AS management + SUBTITLE : Transfer Request from NIF in AS Inactive State + PURPOSE: To check that if AS is Inactive at SG and NIF sends Transfer Primitive to send to that AS then it receives a send failure. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP1 is active. Also arrange the data in ASP such that ASPIA message is sent from ASP1 to SG on stream 0. The Type field in APSIA can be any valid value which is equal to the traffic handling mode for the AS at the SG and Routing Context should be P. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM ASPIA ---------------> (ASP1) Status Ind --------> <-------------- ASP-Inactive-Ack <-------------- NTFY(AS-Pending) <-------- MTP-Transfer Send failure --------> TEST DESCRIPTION: 1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to Inactive state at the SG. Send MTP-Transfer Primitive with N/w Appearance A containing Protocol Data with DPC X. 2. Check A: Send failure should be received at the NIF and DATA message should not be sent to ASP. 3. Repeat the above test if ASPIA message is sent without Routing Context Parameter. ASP-Inactive-Ack and NTFY(AS-Pending) should be received at the ASP with either all routing contexts configured at the SG or with no routing context for the ASP. 4. Repeat the above test if instead of sending ASPIA message, SCTP association between ASP and SG is removed. Note: In some implementation there may be T(r) running on receiving ASPDN or ASPIA message for the last ASP and for that time AS will be in AS-Pending state. In that case let the timer T(r) expire before sending the Transfer primitive. Sunil-Prashant-Ashok, HSS [Page 16] Internet Draft Test Specs for M3UA Feb 2001 "MTP-Transfer Request Primitive from NIF in AS Down State" + TEST NUMBER : 1.3.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.1.1 + TITLE : AS management + SUBTITLE : MTP-Transfer Request from NIF in AS Down State + PURPOSE: To check that if AS is down at SG and NIF sends MTP-Transfer Primitive to send to that AS then it receives a send failure. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP1 is active. Also arrange the data in ASP such that ASPDN message is sent from ASP1 to SG on stream 0. The Reason parameter in ASPDN message can be any valid value. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM ASPIA ---------------> (ASP1) Status Ind ---------> <-------------- ASP-Inactive-Ack <-------------- NTFY(AS-Pending) ASPDN ---------------> (ASP1) Status Ind ---------> <-------------- ASP-Down-Ack <-------------- NTFY(AS-Down) <-------- MTP-Transfer Send failure --------> TEST DESCRIPTION: 1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to Inactive state at the SG. 2. Send ASPDN message from ASP to the SG. ASP will move to down state at the SG. Send MTP-Transfer Primitive with N/w Appearance A containing Protocol Data with DPC X. 3. Check A: Send failure should be received at the NIF and DATA message should not be sent to ASP. Note: In some implementation there may be T(r) running on receiving ASPDN message for the last ASP and for that time AS will be in AS-Pending state. In that case let the timer T(r) expire before sending the MTP-Transfer primitive. Sunil-Prashant-Ashok, HSS [Page 17] Internet Draft Test Specs for M3UA Feb 2001 "Timer T(r) Cancellation" + TEST NUMBER : 1.3.3 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5 + TITLE : AS management + SUBTITLE : Timer T(r) Cancellation + PURPOSE: To check that after last ASP becomes inactive then SG buffers the messages from NIF for time T(r) and if ASPAC comes before its expiry then all buffered messages are sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP1 is active. Arrange the data in ASP such that ASPIA and ASPAC messages are sent from ASP1 to SG on stream 0. The Type field in APSIA and ASPAC can be any valid value and Routing Context should be P. Let the value of Timer T(r) be z sec. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is active ASPIA -----------------> (ASP1) Status Ind --------> <---------------- ASP-Inactive-Ack <---------------- NTFY(AS-Pending) | Timer T(r) is started | | Time < z sec. <------- MTP-Transfer | Message will be buffered | <------- MTP-Transfer | Message will be buffered ASPAC ---------------> (ASP1) Status Ind --------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) <--------------- DATA <--------------- DATA Sunil-Prashant-Ashok, HSS [Page 18] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPIA Message from ASP1 to SG. ASP will become Inactive at the SG. 2. Send MTP-Transfer Primitive from NIF with N/w Appearance A containing Protocol Data to be sent to DPC X. 3. Check A: DATA message will not be received at ASP. 4. Send ASPAC message containing N/w Appearance A before Timer T(r) expires. 5. Check B: DATA messages buffered at the SG will be sent to the AS. Note: This case is implementation specific. In some implementation there may not be any Timer T(r) running. In that case there is no need to run this test case. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 19] Internet Draft Test Specs for M3UA Feb 2001 "Timer T(r) Expiry" + TEST NUMBER : 1.3.4 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5 + TITLE : AS management + SUBTITLE : Timer T(r) Expiry + PURPOSE: To check that timer T(r) is cancelled on receiving ASPAC message from the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP1 is active. Arrange data in ASP such that ASPIA and ASPAC messages are sent from ASP1 to SG on stream 0. The Type field in APSIA and ASPAC can be any valid value and Routing Context should be P. Let the value of Timer T(r) is z sec. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is active <------- MTP-Transfer <--------------- DATA <------- MTP-Transfer <--------------- DATA ASPIA ----------------> Status Ind --------> <--------------- ASP-Inactive-Ack <--------------- NTFY(AS-Pending) | |Time = z sec <------- MTP-Transfer | | <------- MTP-Transfer ( Data is buffered and after expiry of timer it will be discarded) Status Ind ---------> <--------------- NTFY(AS-Down) <-------- MTP-Transfer Send Failure -------> Sunil-Prashant-Ashok, HSS [Page 20] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send MTP-Transfer Primitive with N/w appearance A containing protocol Data to send to DPC X. Message will be buffered at SG. 2. Send ASPIA message from ASP1 to the SG. ASP will become Inactive at SG. AS will be in AS-Pending state at the SG. 3. Check A: Timer T(r) is started. 4. Send MTP Tranfer Primitive with Network Appearance A containing protocol data to send DPC X. Message will be buffered at SG. 5. TimerT(r) is expired, and the message buffered is discarded, also after the expiry of T(r) AS will move to the AS-DOWN state. 6. Send MTP-Transfer Primitive from NIF with N/w appearance A containing protocol Data to send to DPC X. SG will send Send Failure. 7. Repeat the above test case if ASPDN message with any valid Reason parameter is sent instead of ASPIA message. Note: This case is implementation specific. In some implementation there may not be any Timer T(r) running. In that case send failure is notified by M3UA on receiving MTP-Transfer request. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 21] Internet Draft Test Specs for M3UA Feb 2001 "Notify Message with AS Status" + TEST NUMBER : 1.3.5 + Reference: draft-ietf-sigtran-m3ua-03.txt Clause 4.3.3 + TITLE : AS management + SUBTITLE : Notify Message with AS status + PURPOSE: To check that if ASPDN, ASPUP, ASPAC and ASPIA messages are received in ASP-Active, ASP-Down, ASP-Up and ASP-Active state respectively then NTFY message with correct status is sent to ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Also arrange the data in ASP such that ASPDN, ASPUP, ASPAC and ASPIA messages are sent from ASP to SG for ASP and these are sent on stream zero. The value of N/w Appearance is A and Routing Context is P in all the messages and other parameters are having valid values. EXPECTED MESSAGE SEQUENCE : ASP SG SM ASP is active ASPDN ---------------> (ASP1) Status Ind ----------> <-------------- ASP-Down-Ack <-------------- NTFY(AS-Down) ASPUP ---------------> (ASP1) Status Ind -----------> <-------------- ASP-Up-Ack <-------------- NTFY (AS-Inactive) ASPAC ---------------> (ASP1) Status Ind -----------> <-------------- ASP-Active-Ack <-------------- NTFY (AS-Active) Sunil-Prashant-Ashok, HSS [Page 22] Internet Draft Test Specs for M3UA Feb 2001 ASPIA ---------------> (ASP1) Status Ind -----------> <-------------- ASP-Inactive-Ack <-------------- NTFY (AS-Pending) TEST DESCRIPTION: 1. Send ASPDN message for ASP1 from ASP to the SG. 2. Check A: ASPDN is acknowledged by ASP-Down-Ack and NTFY (AS-Down) message at the ASP. 3. Send ASPUP message to SG. 4. Check B: SG responds with ASP-UP-Ack message and NTFY (AS-Inactive). 5. Send ASPAC message with Routing Context P and check SG responds with ASP-Active-Ack and NTFY with status AS-Active. Repeat the test case with Routing Context parameter not present in ASPAC message. 6. Send ASPIA message and check that SG responds with ASP Inactive-Ack and NTFY with status AS-Pending. 7. Check E: NTFY message is received on stream 0. 8. Repeat the above test case if all messages from ASP are sent on stream other than zero. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 23] Internet Draft Test Specs for M3UA Feb 2001 "Received DAUD Message " + TEST NUMBER : 1.3.6 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.4.3 + TITLE : AS management + SUBTITLE : Received DAUD message + PURPOSE: To check that if DAUD message is received from ASP then SG sends Status Request primitive to the NIF and state of ASP is not changed at SG. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP1 is active. Also arrange the data in ASP such that DAUD message is sent to the SG with Network Appearance A and Affected DPC any value. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM AS is active DAUD -------------> Status Request ------> <------ Pause/Resume/State <------------ DUNA/DAVA/SCON TEST DESCRIPTION: 1. Send DAUD message with N/w appearance A and affected DPC any value from ASP to the SG. 2. Check A: Status Request Primitive is received at SM with the DPC and N/w appearance received in the DAUD message. 3. Check B: State of AS will not be changed at SG. Send Pause/Resume primitive with N/w appearance A and SG should send DUNA/DAVA message to the ASP1. 4. Repeat the above test case if DAUD message is sent without N/w Appearance parameter. Response should be same as in the above case. Note: DUNA/DAVA/SCON message may be sent by M3UA itself in response to DAUD message depending upon the implementation. Note1: ASP auditing is an optional procedure and may not be supported at ASP/SG. Sunil-Prashant-Ashok, HSS [Page 24] Internet Draft Test Specs for M3UA Feb 2001 "ASPAC message with more than one Routing Context" + TEST NUMBER : 1.3.7 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : AS management + SUBTITLE : ASPAC message with more than one Routing Context + PURPOSE: To check that if ASPAC message is received with more than one Routing Context then status of ASP is active in all the AS to which this ASP belongs. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP1. ASP1 is belonging to two AS, AS1 and AS2. AS1 is handling traffic for routing context P and AS2 is handling traffic for routing context Q. ASP1 is in Inactive state i.e. AS1 and AS2 are in the AS-Iactive state at SG.Also arrange the data in ASP1 such that ASPAC message is sent from ASP1 to SG on stream 0 containing Routing Context P and Q. Fill any valid value in the Type parameter which is same as configured for AS1 and AS2 at the SG and it should be same for both AS. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Inactive ASPAC ------------------> Routing Context P and Q Status Ind ---------> <----------------- ASP-Active-Ack <----------------- NTFY (AS-Active) <-------- MTP-Transfer for Routing Context P <----------------- DATA <-------- MTP-Transfer for Routing Context Q <----------------- DATA TEST DESCRIPTION: 1. Send ASPAC Message with routing contexts P and Q to the SG. 2. Check A: ASP-Active-Ack and NTFY message with status AS-Active should be received at ASP with routing contexts P and Q. 3. Check B: Check that state of ASP is active in AS1 and AS2. This can be checked by sending DATA messages containing protocol DATA for both Routing Contexts. Sunil-Prashant-Ashok, HSS [Page 25] Internet Draft Test Specs for M3UA Feb 2001 "ASPAC message without any Routing Context" + TEST NUMBER : 1.3.8 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : AS management + SUBTITLE : ASPAC message without any Routing Context + PURPOSE: To check that if ASPAC message is received without any Routing Context then status of ASP is active and it is kept in free pool. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. Both ASP are having SCTP association with SG and are Inactive in the AS. Arrange data in AS such that ASPAC messages are sent to the SG from ASP1 on stream 0. Dont fill any routing context parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Inactive ASPAC ------------------> No Routing Context Status Ind ---------> <----------------- ASP-Active-Ack <----------------- NTFY (AS-Active) TEST DESCRIPTION: 1. Send ASPAC Message without any routing to the SG. 2. Check A: ASP-Active-Ack and NTFY message with status AS-Active should be received at ASP without any routing context. 3. Check B: Check that state of ASP is active and put in the spare pool. Note: This is implementation dependent. Alternatively it may also send a Protocol Error. Sunil-Prashant-Ashok, HSS [Page 26] Internet Draft Test Specs for M3UA Feb 2001 "ASPIA message with more than one Routing Context" + TEST NUMBER : 1.3.9 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5 + TITLE : AS management + SUBTITLE : ASPIA message with more than one Routing Context + PURPOSE: To check that if ASPIA message is received with more than one Routing Context then status of ASP is Inactive in all the AS to which this ASP belongs. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. ASP1 is belonging to two AS, AS1 and AS2. AS1 is handling traffic for routing context P and AS2 is handling traffic for routing context Q. ASP1 is in Active state i.e. AS1 and AS2 are in the AS-Active state at SG. Also arrange the data in ASP1 such that ASPIA message is sent on stream 0 from ASP1 to SG containing Routing Context P and Q. Fill any valid value in the Type parameter which is same as configured for AS1 and AS2 in SG and it should be same for both AS. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Active ASPIA ------------------> Routing Context P and Q Status Ind ---------> <----------------- ASP-Inactive-Ack <----------------- NTFY(AS-Pending) <-------- MTP-Transfer Routing Context P Send Failure --------> <-------- MTP-Transfer Routing Context Q Send Failure --------> Sunil-Prashant-Ashok, HSS [Page 27] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPIA Message containing routing contexts P and Q from ASP1 to the SG. 2. Check A: ASP-Inactive-Ack and NTFY (AS-Pending) message should be received at the ASP with routing contexts P and Q. 3. Check B: NTFY message is received on stream 0. 4. Check C: Check that state of ASP is Inactive in AS1 and AS2. This can be checked by sending MTP-Transfer primitive from NIF at SG containing protocol DATA for both Routing Contexts. Note: Routing Context is an optional parameter in the NTFY message. Some implementation may not send this parameter in the NTFY message. In that case two NTFY message with status AS-Inactive/AS-Pending will be received one for AS1 and other for AS2. Note1: NTFY message with AS status may come before the ASP-Inactive-Ack message. Sunil-Prashant-Ashok, HSS [Page 28] Internet Draft Test Specs for M3UA Feb 2001 "Notify Message with AS Status is sent only for AS State change -A" + TEST NUMBER : 1.3.10 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.1.2 + TITLE : AS management + SUBTITLE : Notify Message with AS Status is sent only for AS State change + PURPOSE: To check that NTFY message with AS state change is not sent if there is no change in the state of the AS. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. Both ASP are having SCTP association with SG and are active in the AS. Arrange data in AS such that ASPUP, ASPAC, ASPIA and ASPDN messages are sent to the SG from ASP1 on stream 0. Fill the routing contexts P and Type parameter any valid value which is same configured for AS at the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM Both ASPs are active ASPIA(ASP1) -----------------> <---------------- ASP-Inactive-Ack Check: NTFY(AS-Pending) is not received Status Ind ---------> ASPDN(ASP1) -----------------> <---------------- ASP-Down-Ack Check: NTFY(AS-Down) is not received Status Ind ---------> ASPUP(ASP1) -----------------> <---------------- ASP-Up-Ack Check: NTFY(AS-Inactive) is not received Status Ind ---------> ASPAC(ASP1) -----------------> <---------------- ASP-Active-Ack Check: NTFY(AS-Active) is not received Status Ind ---------> Sunil-Prashant-Ashok, HSS [Page 29] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPIA message for ASP1 from ASP to the SG with routing context P and Type parameter any valid value. 2. Check A: ASP-Inactive-Ack messages is received at the AS and NTFY message with status AS-Inactive is not received. 3. Repeat the above test case for other messages like ASPDN, ASPUP and ASPAC for ASP1 from AS to SG. Sunil-Prashant-Ashok, HSS [Page 30] Internet Draft Test Specs for M3UA Feb 2001 "Notify Message with AS Status is sent only for AS State change -B" + TEST NUMBER : 1.3.11 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.1.2 + TITLE : AS management + SUBTITLE : Notify Message with AS Status Change + PURPOSE: To check that NTFY message with AS state change is sent if AS state has changed. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. Both ASP are having SCTP association with SG and are active in the AS. Arrange data in AS such that ASPUP, ASPAC, ASPIA and ASPDN messages are sent to the SG from ASP1 and ASP2 on stream 0. Fill the routing contexts P and Type parameter any valid value which is same configured for AS at the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM Both ASP are active ASPIA(ASP1) -----------------> <---------------- ASP-Inactive-Ack Status Ind ---------> ASPIA(ASP2) -----------------> <---------------- ASP-Inactive-Ack <---------------- NTFY(AS-Pending) Status Ind ---------> ASPDN(ASP1) -----------------> <---------------- ASP-Down-Ack Status Ind ---------> ASPDN(ASP2) -----------------> <---------------- ASP-Down-Ack <---------------- NTFY( AS-Down) Status Ind ---------> Sunil-Prashant-Ashok, HSS [Page 31] Internet Draft Test Specs for M3UA Feb 2001 ASPUP(ASP1) -----------------> <---------------- ASP-Up-Ack <---------------- NTFY( AS-Inactive) Status Ind ---------> ASPUP(ASP2) -----------------> <---------------- ASP-Up-Ack Status Ind ---------> ASPAC(ASP1) -----------------> <---------------- ASP-Active-Ack <---------------- NTFY( AS-Active) Status Ind ---------> ASPAC(ASP2) -----------------> <---------------- ASP-Active-Ack Status Ind ---------> TEST DESCRIPTION: 1. Send ASPIA message for ASP1 and ASP2 from ASP to the SG with routing context P and Type parameter any valid value. 2. Check A: ASP-Inactive-Ack and NTFY message with status AS-Pending is received at the AS. 3. Check B: NTFY messages are received on stream 0. 4. Repeat the above test case for other messages like ASPDN, ASPUP and ASPAC for ASP1 from AS to SG. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 32] Internet Draft Test Specs for M3UA Feb 2001 "Heartbeat and HeartbeatAck" + TEST NUMBER : 1.3.12 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.1.2 + TITLE : AS management + SUBTITLE : Heartbeat + PURPOSE: : To check that an ASP sends Heartbeat messages (to ensure that the M3UA peers are still available to each other) and receives a Heartbeat Ack from the remote peer. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP1 is active. Also arrange the data in ASP such that BEAT message is sent from ASP1 to SG. EXPECTED MESSAGE SEQUENCE: AS SG SM a) BEAT (ASP1) -----------------> Timer 2*T(beat) | is started | <---------------- BEAT ACK b) BEAT (ASP1) -----------------> Timer 2*T(beat) | is started | | Timer 2*T(beat) is expired and no BEAT ACK is from SG. TEST DESCRIPTION: 1. Send BEAT Message for ASP1 from ASP to the SG. 2. The beat message should be acknowledge by BEAT ACK before the Timer expires. 3. Send the Beat message again. 4. The timer expires and no beat ack message is received, the ASP will consider remote M3UA peer as Down.Transmission of BEAT message is stopped and ASP-Up procedures are used to re-establish communication with the SG M3UA peer. Sunil-Prashant-Ashok, HSS [Page 33] Internet Draft Test Specs for M3UA Feb 2001 "MTP-Pause Indication Primitive:" + TEST NUMBER : 1.4.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.4.1 + TITLE : MTP3 management + SUBTITLE : MTP-Pause Indication Primitive + PURPOSE: To check that if MTP-Pause indication primitive is received from NIF at SG then SG sends DUNA message to the concerned AS. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SG and AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. Also arrange the data in NIF at SG such that MTP-Pause Indication Primitive is sent to the AS with Network Appearance A and B and affected DPC any value. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 ASP3 SG NIF All AS are active <---------- MTP-Pause N/w Appearance A Affected DPC T <---------------------------- DUNA <----------------- DUNA <---------- MTP-Pause N/w Appearance B Affected DPC T <--------- DUNA TEST DESCRIPTION: 1. Send MTP-Pause indication Primitive message from NIF in the SG containing the Network Appearance A and Affected DPC T. 2. Check A: DUNA message will be received at the ASP1 and ASP2 containing the network Appearance A and Affected DPC T. 3. Check B: DUNA message is received at both AS AS1 and AS2 which are handling traffic for the same network appearance. 4. Check C: DUNA message is received on the Stream number 0. 5. Repeat the above test case with N/w Appearance B. In this case DUNA message should be sent to AS3. Sunil-Prashant-Ashok, HSS [Page 34] Internet Draft Test Specs for M3UA Feb 2001 "MTP-Resume Indication Primitive" + TEST NUMBER : 1.4.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.4.1 + TITLE : MTP3 management + SUBTITLE : MTP-Resume Indication Primitive + PURPOSE: To check that if MTP-Resume indication primitive is received from NIF at SG then SG sends DAVA message to the concerned AS. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SG and AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. Also arrange the data in NIF at SG such that MTP-Resume Indication Primitive is sent to the AS with Network Appearance A and B and affected DPC any value. EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SG NIF All AS are active <---------- MTP-Resume N/w Appearance A Affected DPC T <---------------------------- DAVA <----------------- DAVA <---------- MTP-Resume N/w Appearance B Affected DPC T <--------- DAVA TEST DESCRIPTION: 1. Send MTP-Resume indication Primitive from NIF in the SG containing the Network Appearance A and Affected DPC T. 2. Check A: DAVA message is received at AS1 and AS2 containing the network Appearance A and Affected DPC T. 3. Check B: DAVA message is received at AS1 and AS2 4. Check C: DAVA message is received on the Stream number 0. 5. Repeat the test case for N/w appearance B and affected destination any value. Check that message is being sent to AS3. Prashant-Ashok, HSS [Page 35] Internet Draft Test Specs for M3UA Feb 2001 "MTP-Status Indication Primitive with Route Congested" + TEST NUMBER : 1.4.3 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.4.1 + TITLE : MTP3 management + SUBTITLE : MTP-Status Indication Primitive with Route Congested + PURPOSE: To check that if MTP-Status indication primitive with Route Congested parameter is received from NIF at SG then SG sends SCON message to the concerned AS. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SG and AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. Also arrange the data in NIF at SG such that MTP-Status indication Primitive is sent to the SG with cause Routing Congested, affected DPC, Congestion level and Network Appearance. EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SG NIF All AS are active <---------- MTP-Status N/w Appearance A DPC T Cong Level 2 <---------------------------- SCON <----------------- SCON <---------- MTP-Status N/w Appearance B DPC T Cong Level 2 <--------- SCON Sunil-Prashant-Ashok, HSS [Page 36] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send MTP-Status indication Primitive from NIF in the SG containing the Network Appearance A, cause Route congestion, Affected DPC X and congestion Level 2. 2. Check A: SCON message is received at the AS1 and AS2 containing the network Appearance A, Affected DPC X, Congestion Level 2 passed to it from NIF. 3. Check B: SCON message is received at AS1 and AS2. 4. Check C: SCON message is received on the Stream number 0. 5. Repeat the above test case for all congestion level 0,1,2 and 3. SCON message will be received with congestion level passed from NIF. 6. Repeat the above test case with different congestion level for different affected DPC. SCON message should contain the correct congestion level for each affected destination. 7. Repeat the above test case with N/w appearance B. SCON message will be received at AS3. Sunil-Prashant-Ashok, HSS [Page 37] Internet Draft Test Specs for M3UA Feb 2001 "MTP-Status Indication Primitive with User Part Unavailable" + TEST NUMBER : 1.4.4 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.4.1 + TITLE : MTP3 management + SUBTITLE : MTP-Status Indication Primitive with User Part Unavailable + PURPOSE: To check that if MTP-Status indication primitive with cause User Part Unavailable is received from NIF at SG then SG sends DUPU message to the concerned AS. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SG and AS1, AS2 and AS3. All AS are in AS-Active state. AS1 and AS2 are handling traffic for N/w appearance A and AS3 is handling traffic for N/w Appearance B. Also arrange the data in NIF at SG such that MTP-Status indication Primitive is sent to the SG with cause User Part Unavailable Unknown, affected DPC, SIO for ISUP and network appearance A. Assume routing context is DPC+SIO based. EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SG NIF All AS are active <---------- MTP-Status N/w Appearance A DPC S <---------------------------- DUPU <----------------- DUPU <---------- MTP-Status N/w Appearance B DPC S <--------- DUPU Sunil-Prashant-Ashok, HSS [Page 38] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send MTP-Status indication Primitive from NIF in the SG containing the Network Appearance A, cause User Part Unavailable, Affected DPC S and SIO for ISUP. 2. Check A: SG will send DUPU message containing the network Appearance A, Affected DPC S, cause unknown and user ISUP. 3. Check B: DUPU message is received at AS1 and AS2. 4. Check C: DUPU message is received on the Stream number 0. 5. Repeat the above test case with cause values Unequipped Remote User and Inaccessible Remote User and other parameters being the same as in the above tests. DUPU message will be received with these cause values. 6. Repeat the above test case with SIO values TUP, Broadband ISUP, Satellite ISUP and Reserved. 7. Repeat the above test case if MTP-Status is sent with N/w appearance B. DUPU message will be sent to AS3. Sunil-Prashant-Ashok, HSS [Page 39] Internet Draft Test Specs for M3UA Feb 2001 "Invalid Version Error" + TEST NUMBER : 1.5.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.3 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Version Error + PURPOSE: To check that if any message with Invalid version is received at the SG then SG responds with ERROR message containing cause "Invalid Version" and diagnostic information filled with the version the SG supports. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Also arrange the data in ASP such that ASPIA message is sent with the version other than Release 1.0 protocol to SG. Type field can be any valid value and fill the routing context with any value. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is active ASPIA ----------------> Version = 2 <--------------- ERROR Cause = Invalid Version TEST DESCRIPTION: 1. Send ASPIA message AS to SG containing version 2 in the common header. 2. Check A: ERROR message is received at the ASP containing cause Invalid Version. 3. Check B: Diagnostic Field Parameter in ERROR is filled with version 1. 4. Repeat the above test cases for other messages from AS to SG like ASPAC, ASPUP, ASPDN, DAUD and DATA. In all these cases ERROR message will be received with the same cause. Sunil-Prashant-Ashok, HSS [Page 40] Internet Draft Test Specs for M3UA Feb 2001 "Invalid Traffic Handling Mode Error" + TEST NUMBER : 1.5.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 4.3.3.4 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Traffic Handling Mode Error + PURPOSE: To check that if ASPAC or ASPIA message is received with Type parameter incompatible with the traffic handling mode currently used in AS at SG, SG responds with ERROR message containing cause "Invalid Traffic Handling Mode". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP1 is Up. Arrange the data in ASP such that ASPAC message is sent with Type field filled with Loadshare mode of Traffic handling. Traffic Handling Mode defined at SG for AS is Override. Fill value P in Routing context parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Inactive ASPAC ----------------> Type = Loadshare <--------------- ERROR Cause = Invalid traffic Handling Mode TEST DESCRIPTION: 1. Send ASPAC message from AS to SG containing Type field Loadshare. Mode of Traffic handling for AS at SG is Override. 2. Check A: ERROR message is received at the ASP containing cause Invalid Traffic Handling Mode. 3. Repeat the above test cases for other values of Type field with Traffic Handling Mode for AS at SG being different from this Type field. 4. Repeat the test case with Type field having value that is not defined i.e any value greater than 0x03. 5. Repeat all the above tests for ASPIA message. Sunil-Prashant-Ashok, HSS [Page 41] Internet Draft Test Specs for M3UA Feb 2001 "Invalid Traffic Handling Mode Error if there are two ASP in one AS" + TEST NUMBER : 1.5.3 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 4.3.3.4 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Traffic Handling Mode Error if there are two ASP in one AS + PURPOSE: To check that if ASPAC or ASPIA message is received with Type parameter incompatible with the traffic handling mode currently used in AS at SG, SG responds with ERROR message containing cause "Invalid Traffic Handling Mode". + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP1 and ASP2 are Up. Arrange the data in ASP such that ASPAC message for ASP1 is sent with Type field filled with Override mode of Traffic handling and ASPAC message for ASP2 is sent with Type field filled with Loadshare mode of Traffic handling. Traffic Handling Mode defined at SG for AS is Override Mode. Fill value P in Routing context parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Inactive ASPAC(ASP1)----------------> Type = Override Status Ind -------> <--------------- ASP-Active-Ack ASPAC(ASP2) ----------------> Type = Loadshare <--------------- ERROR Cause = Invalid traffic Handling Mode TEST DESCRIPTION: 1. Send ASPAC message from ASP1 to SG containing Type field Override. 2. Check A: ASP-Active-Ack message is received at the ASP. 3. Send ASPAC message from ASP2 to SG containing Type field Loadshare. 4. Check B: ERROR message is received at the ASP containing cause Invalid Traffic Handling Mode. 5. Repeat the above test cases for other values of Type field with Traffic Handling Mode for AS at SG being different from this Type. 6. Repeat the test case with Type field having value that is not defined. 7. Repeat all the above tests for ASPIA message. Sunil-Prashant-Ashok, HSS [Page 42] Internet Draft Test Specs for M3UA Feb 2001 "Unrecognized Message Type" + TEST NUMBER : 1.5.4 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 + TITLE : Invalid Message Handling + SUBTITLE : Unrecognized Message Type + PURPOSE: To check that if a message with message type not defined is received at SG, SG responds with ERROR message containing cause "Invalid Message Type". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP1 is active. Arrange the data in ASP such that a message with Message type not defined is sent to SG. Let the other parameters in the message be like any other message. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Active Message ----------------> Message Type=0408 <--------------- ERROR Cause = Invalid Message Type DATA ----------------> N/w Appearance A MTP-Transfer Ind -------> TEST DESCRIPTION: 1. Send a message with message type 0408 or any other value which is not defined from AS to SG 2. Check A: ERROR message is received at the ASP containing cause Invalid Message Type. 3. Check B: State of AS at SG is not disturbed. 4. Repeat the above test cases by sending DUNA, DAVA, DUPU, SCON messages from AS which the SG is not expected to receive. In this case Error will be reported to the SM and Message will be discarded. Prashant-Ashok, HSS [Page 43] Internet Draft Test Specs for M3UA Feb 2001 "Invalid Network Appearance" + TEST NUMBER : 1.5.5 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Network Appearance + PURPOSE: To check that if a message with invalid network appearance i.e. network appearance not defined at SG then SG responds with ERROR message containing cause "Invalid Network Appearance". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data in AS such that DATA message with Network Appearance other than A is sent to SG. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Active DATA ----------------> N/w Appearance B <--------------- ERROR Cause = Invalid N/w Appearance DATA ----------------> N/w Appearance A MTP-Transfer Ind -------> TEST DESCRIPTION: 1. Send DATA message with network appearance B which is not defined at SG. 2. Check A: ERROR message containing cause Invalid Network Appearance should be received at AS. 3. Check B: State of AS at SG is not disturbed. Note: Network Appearance parameter is optional. In some implementation this parameter may not come in DATA message. In those implementations, this test case need not be tested. Prashant-Ashok, HSS [Page 44] Internet Draft Test Specs for M3UA Feb 2001 "Invalid Reason parameter in ASPDN message" + TEST NUMBER : 1.5.6 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 4.3.3.2 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Reason Parameter in ASPDN message + PURPOSE: To check that if ASPDN message with Invalid Reason parameter is received then ASP Down Ack message is send back. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is in Active state i.e. ASP1 is active. Arrange the data in ASP such that ASPDN message with Reason Parameter filled with value 03 or more is sent to the SG. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Active ASPDN ----------------> Reason = 0x3 Message is discarded <--------------- ASP-Down-Ack <--------------- NTFY (AS-Down) <--------------- Error (Unsupported Message Type) TEST DESCRIPTION: 1. Send ASPDN message with Reason Parameter 0x3 from ASP to SG. 2. Check A: The ASP-Down-Ack, NTFY (AS-Down) is send to ASP. 3. Also an error message with reason Unsupported Message Type is send to ASP to indicate that the reason parameter was invalid. Sunil-Prashant-Ashok, HSS [Page 45] Internet Draft Test Specs for M3UA Feb 2001 "Invalid routing context parameter in ASPAC message" + TEST NUMBER : 1.5.7 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.5.7 + TITLE : Invalid Message Handling + SUBTITLE : Invalid routing context Parameter in ASPAC message + PURPOSE: To check that if ASPAC message with Invalid routing context parameter is received then ASPAC message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Inactive state i.e. ASP1 is Inactive. Arrange the data in AS such that ASPAC message with Routing Context P is sent to the SG. EXPECTED MESSAGE SEQUENCE : ASP SG NIF AS is Inactive ASPAC ----------------> Routing context Q <--------------- Error ( Invalid Routing Context) ASPAC ----------------> Routing context P and Q Status Ind ---------> <--------------- ASP-Active-Ack with routing context P <--------------- NTFY (AS-Active) TEST DESCRIPTION: 1. Send ASPAC message with routing context Q. 2. Check A: SG will send an Error message with Invalid Routing Context parameter. 3. Send ASPAC message with routing context P and Q. 4. Check B: ASP-Active-Ack and NTFY (AS-Active) message will be sent for routing context P. Note: Routing context is an optional parameter in ASPAC message. In some implementation this field may not come in ASPAC message. In those implementation this test case need not be run. Sunil-Prashant-Ashok, HSS [Page 46] Internet Draft Test Specs for M3UA Feb 2001 "Invalid routing context parameter in ASPIA message" + TEST NUMBER : 1.5.8 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.5.7 + TITLE : Invalid Message Handling + SUBTITLE : Invalid routing context Parameter in ASPIA message + PURPOSE: To check that if ASPIA message with Invalid routing context parameter is received then ASPIA message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Active state i.e. ASP1 is active. Arrange the data in AS such that ASPIA message with Routing Context Q is sent to the SG. EXPECTED MESSAGE SEQUENCE : ASP SG NIF ASP is Active ASPIA ----------------> Routing context Q <--------------- Error ( Invalid Routing Context) ASPIA ----------------> Routing context P and Q Status Ind ---------> <--------------- ASP-Inactive-Ack with routing context P <--------------- NTFY(AS-Pending) TEST DESCRIPTION: 1. Send ASPIA message with Routing Context Q. 2. Check A: SG will send an Error message with Invalid Routing Context parameter. 3. Send ASPIA message with routing context P and Q. 4. Check B: ASP-Inactive-Ack and NTFY (AS-Pending) message will be sent with status AS-Pending for routing context P. Note: Routing context is an optional parameter in ASPIA message. In some implementation this field may not come in ASPIA message. In those implementation this test case need not be run. Sunil-Prashant-Ashok, HSS [Page 47] Internet Draft Test Specs for M3UA Feb 2001 "Message length less than the length of mandatory Parameters" + TEST NUMBER : 1.5.9 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.5.7 + TITLE : Invalid Message Handling + SUBTITLE : Message length less than the length of mandatory parameters + PURPOSE: To check that if a message with value of length parameter less than length of mandatory parameters is received then message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Active state. Arrange the data in AS such that ASPIA message with length parameter filled with value less than the length of type parameter is sent on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG NIF AS is Active ASPIA ----------------> Message Length = 2 <--------------- Error ( Unsupported Message Type) DATA ----------------> N/w appearance A MTP-Transfer ---------> TEST DESCRIPTION: 1. Send ASPIA message with length parameter filled with value less than the length of type field to the SG. 2. Check A: SG will send an Error message with Unsupported Message Type parameter. 3. Check B: State of AS at SG is not disturbed. 4. Repeat the above test case for other messages like ASPAC, ERROR, ASPDN. Sunil-Prashant-Ashok, HSS [Page 48] Internet Draft Test Specs for M3UA Feb 2001 "ASPUP message in AS-Inactive state" + TEST NUMBER : 1.6.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.1 + TITLE : Duplicate Message Handling + SUBTITLE : ASPUP message in AS Inactive state + PURPOSE: To check that if ASPUP message is received in ASP-Inactive state then message with ASP-Up-Ack is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Down state i.e. ASP1 is down. Arrange the data in AS such that ASPUP message is sent to the SG two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Down ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) ASPUP ----------------> <--------------- ASP-Up-Ack ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) TEST DESCRIPTION: 1. Send ASPUP message to the SG in ASP-Down state. ASP-Up-Ack and NTFY (AS-Inactive) messages will come from the SG. Send ASPUP message again from the AS for the same ASP. 2. Check A: ASP-Up-Ack message should be received at AS. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Inactive state. Send ASPAC message with valid Type and Routing Context for the ASP1 and ASP-Active-Ack message should come. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 49] Internet Draft Test Specs for M3UA Feb 2001 "ASPDN message in ASP-Down state" + TEST NUMBER : 1.6.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.2 + TITLE : Duplicate Message Handling + SUBTITLE : ASPDN message in ASP-Down state + PURPOSE: To check that if ASPDN message is received in ASP-Down state then ASP-Down-Ack message is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Inactive state i.e. ASP1 is Inactive. Arrange the data in AS such that ASPDN message is sent to the SG two times with the valid Reason Parameter on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Inactive ASPDN ----------------> Status Ind -------> <--------------- ASP-Down-Ack <--------------- NTFY(AS-Down) ASPDN ----------------> <--------------- ASP-Down-Ack ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send ASPDN message to the SG in ASP-Inactive state. ASP-Down-Ack and NTFY (AS-Down) messages will come from the SG. Send ASPDN message again from the AS for ASP1. 2. Check A: ASP-Down-Ack message should be received at AS. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Down state. Send ASPUP message for the ASP,ASP-Up-Ack and NTFY with status AS-Inactive should come. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 50] Internet Draft Test Specs for M3UA Feb 2001 "ASPAC message in ASP-Active state" + TEST NUMBER : 1.6.3 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : Duplicate Message Handling + SUBTITLE : ASPAC message in ASP-Active state + PURPOSE: To check that if ASPAC message is received in ASP-Active state then ASP-Active-Ack message is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Inactive state i.e. ASP1 is Inactive. Arrange the data in AS such that ASPAC message with correct Type (Type is same as defined at SG for the AS) and routing context P is sent to the SG two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Inactive ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY (AS-Active) ASPAC ----------------> <--------------- ASP-Active-Ack DATA ----------------> MTP-Transfer Ind -------> TEST DESCRIPTION: 1. Send ASPAC message to the SG in ASP-Inactive state. ASP-Active-Ack and NTFY (AS-Active) message will come from the SG. 2. Send ASPAC message again from the AS for the same ASP. 3. Check A: ASP-Active-Ack message should be received at ASP. 4. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Active state. Send DATA message for the ASP and SG should send MTP-Transfer indication to the NIF. Sunil-Prashant-Ashok, HSS [Page 51] Internet Draft Test Specs for M3UA Feb 2001 "ASPIA message in ASP-Inactive state" + TEST NUMBER : 1.6.4 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5 + TITLE : Duplicate Message Handling + SUBTITLE : ASPIA message in ASP-Inactive state + PURPOSE: To check that if ASPIA message is received in ASP-Inactive state then ASP-Inactive-Ack message is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Active state i.e. AS1 is active. Arrange the data in AS such that ASPIA message with correct Type(Type is same as defined at SG for the AS) and Routing Context P is sent to the SG two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS is Active ASPIA ----------------> Status Ind -------> <--------------- ASP-Inactive-Ack <--------------- NTFY(AS-Pending) ASPIA ----------------> <--------------- ASP-Inactive-Ack ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) Sunil-Prashant-Ashok, HSS [Page 52] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPIA message to the SG in ASP-Active state. ASP-Inactive-Ack and NTFY (AS-Pending) messages will come from the SG. 2. Send ASPIA message again from the AS for the same ASP. 3. Check A: ASP-Inactive-Ack message will come from SG. 4. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Inactive state. Send ASPAC message with correct Type(Type is same as defined at SG for the AS) for the ASP1 and SG should respond with ASP-Active-Ack message. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 53] Internet Draft Test Specs for M3UA Feb 2001 "ASPAC message in ASP-Down state" + TEST NUMBER : 1.6.5 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : Invalid Message Handling + SUBTITLE : ASPAC message in ASP-Down state + PURPOSE: To check that if ASPAC message is received in ASP-Down state then message is discarded and an Error message is returned back . + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is in ASP-Down state i.e. ASP1 is down. Arrange the data in ASP such that ASPAC message with correct Type (Type is same as defined at SG for the AS) and routing context P is sent to the SG on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Down ASPAC ----------------> <--------------- Error ( Unexpected Message) ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send ASPAC message to the SG in ASP-Down state. 2. Check A: Error message with Unexpected Message should be received at the ASP. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Down state. Send ASPUP message for the ASP and SG should respond with ASP-Up-Ack and NTFY message with status AS-Inactive. 4. Repeat the above test case for ASPIA message. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sunil-Prashant-Ashok, HSS [Page 54] Internet Draft Test Specs for M3UA Feb 2001 "ASPUP message in ASP-Active state" + TEST NUMBER : 1.6.6 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : ASPUP message in ASP-Active state + PURPOSE: To check that if ASPUP message is received in ASP-Active state then ACK message is sent to AS and ASP state is moved to ASP-up. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and ASP1 is Active. Arrange the data in AS such that ASPUP message is sent to the SG on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Active ASPUP ----------------> <--------------- Error (Unexpected Message) ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack TEST DESCRIPTION: 1. Send ASPUP message to the SG in ASP-Active state. 2. Check A: An Error message with parameter Unexpected Message should be received at ASP. 3. Check B: State of ASP should not change. Send ASPAC message with correct Type (Type is same as defined at SG for the AS) and routing context P to the SG and SG should send ASP-Active-Ack. Sunil-Prashant-Ashok, HSS [Page 55] Internet Draft Test Specs for M3UA Feb 2001 "ASPDN message in ASP-Active state" + TEST NUMBER : 1.6.7 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.2 + TITLE : Different Message Handling + SUBTITLE : ASPDN message in ASP-Active state + 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 SG becomes ASP-Down. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and ASP1 is Active. Arrange the data in AS such that ASPUP message with valid Reason parameter is sent to the SG on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Active ASPDN ----------------> Status Ind -------> <--------------- ASP-Down-Ack <--------------- NTFY(AS-Down) ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send ASPDN message to the SG in ASP-Active state. 2. Check A: ASP-Down-Ack and NTFY (AS-Down) message is received at ASP. 3. Check B: State of ASP should become Down. 4. Send ASPUP message to the SG and SG should send ASP-Up-Ack and NTFY message with Status ASP-Inactive. Sunil-Prashant-Ashok, HSS [Page 56] Internet Draft Test Specs for M3UA Feb 2001 "DATA message from AS in ASP-Down state" + TEST NUMBER : 1.6.8 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 3.6.1 and 3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : DATA message from AS in ASP-Down state + PURPOSE: To check that if DATA message is received in ASP-Down state then it is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and ASP1 is Down. Arrange the data in AS such that DATA message with N/w Appearance A is sent to the SG. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Down DATA ----------------> <--------------- Error (Unexpected Message) ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send DATA message to the SG in ASP-Down state. 2. Check A: DATA message should be discarded and an Error message should be received at the ASP. 3. Check that state of SG is not disturbed. 4. Send ASPUP message on stream 0 and SG should respond with ASP-Up-Ack and NTFY (AS-Inactive). Sunil-Prashant-Ashok, HSS [Page 57] Internet Draft Test Specs for M3UA Feb 2001 "ASPM message when SG has locked out the ASP for management reason" + TEST NUMBER : 1.7 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.1 + TITLE : AS management + SUBTITLE : ASPM message when SG has locked out the ASP for management reason + PURPOSE: To check that if ASPM message is received when SG has locked out the ASP for managemet reason then NTFY message with status ASP-Down is sent to AS . + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and ASP may be in any state. Arrange the data in SG such that ASP is locked out at the SG. Arrange the data in AS such that ASPM messages with valid parameters are sent to the SG on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF <---------- Lock-ASP ASPUP ----------------> <--------------- ASP-Down-Ack TEST DESCRIPTION: 1. Lock out the ASP at the SG by sending primitive for locking ASP from SM. 2. Now send ASPUP message with valid parameters from ASP to SG. 2. Check A: ASP-Down-Ack message with reason " Management Blocking" is received at ASP. 3. Repeat the above test case for other ASPM messages like ASPAC, ASPIA and ASPDN messages from ASP to the SG with valid parameters. Response should be same. Sunil-Prashant-Ashok, HSS [Page 58] Internet Draft Test Specs for M3UA Feb 2001 "Message Routing based on DPC" + TEST NUMBER : 1.8.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 1.4.2.1 + TITLE : Message Routing + SUBTITLE : Message Routing towards ASP + PURPOSE: To check that if NIF sends a MTP-Transfer message containing Protocol DATA to send to the AS then it is sent to the correct AS. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SG and all ASP i.e. ASP1, ASP2 and ASP3 and all ASP are in Active state. Also arrange the data in NIF at SG such that MTP-Transfer Indication Primitives is sent to the AS with following parameter combination: Protocol Data and N/w Appearance A and DPC X Protocol Data and N/w Appearance A and DPC Y Protocol Data and N/w Appearance B and DPC Z EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SG NIF All AS are active <---------- MTP-Transfer Ind N/w Appearance A DPC X <---------------------------- DATA <---------- MTP-Transfer Ind N/w Appearance A DPC Y <---------------- DATA <---------- MTP-Transfer Ind N/w Appearance B DPC Z <-------- DATA TEST DESCRIPTION: 1. Send MTP-Transfer indication Primitive from NIF in SG containing the Protocol Data with DPC X and N/w appearance A. 2. Check A: DATA message will be received at the AS1. 3. Repeat the above test case for MTP-Transfer Ind primitive containing Protocol Data with DPC Y and N/w appearance A. 4. Repeat the above test case for MTP-Transfer Ind primitive containing Protocol Data with DPC Z and N/w appearance B. Sunil-Prashant-Ashok, HSS [Page 59] Internet Draft Test Specs for M3UA Feb 2001 "Message Routing based on DPC+CIC" + TEST NUMBER : 1.8.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 1.4.2.1 + TITLE : Message Routing + SUBTITLE : Message Routing based on DPC+CIC + PURPOSE: To check that if NIF sends a MTP-Transfer message containing Protocol DATA to send to the AS then it is sent to the correct AS. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and all ASP i.e. ASP1 and ASP2 and all ASP are in Active state. Routing context P consists of DPC X and CIC 1 to 31. Routing context Q consists of DPC X and CIC 33 to 63. Also arrange the data in NIF at SG such that MTP-Transfer Indication Primitives is sent to the AS with the following parameter combination: Protocol Data with DPC X and CIC 3 Protocol Data with DPC X and CIC 35 EXPECTED MESSAGE SEQUENCE : AS1 AS2 SG NIF All AS are active <---------- MTP-Transfer Ind DPC X CIC 3 <---------------------------- DATA <---------- MTP-Transfer Ind DPC X CIC 35 <---------------- DATA TEST DESCRIPTION: 1. Send MTP-Transfer indication Primitive from NIF in the SG containing the Protocol Data with DPC X and CIC value 3. 2. Check A: DATA message will be received at the AS1. 3. Repeat the above test case for MTP-Transfer Ind primitive containing Protocol Data with DPC X and CIC value 35. DATA message should be received at AS2 Sunil-Prashant-Ashok, HSS [Page 60] Internet Draft Test Specs for M3UA Feb 2001 "Message Routing based on DPC+SSN" + TEST NUMBER : 1.8.3 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 1.4.2.1 + TITLE : Message Routing + SUBTITLE : Message Routing based on DPC+SSN + PURPOSE: To check that if NIF sends a MTP-Transfer message containing Protocol DATA to send to the AS then it is sent to the correct AS. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and all ASP i.e. ASP1and ASP2 and all ASP are in Active state. Routing context P consists of DPC X and SSN S. Routing context Q consists of DPC X and SSN T. Also arrange data in NIF at SG such that MTP-Transfer Indication Primitives is sent to the AS with the following parameter combination: Protocol Data with DPC X and SSN S Protocol Data with DPC X and SSN T EXPECTED MESSAGE SEQUENCE : AS1 AS2 SG NIF All AS are active <---------- MTP-Transfer Ind DPC X SSN S <---------------------------- DATA <---------- MTP-Transfer Ind DPC X SSN T <---------------- DATA TEST DESCRIPTION: 1. Send MTP-Transfer indication Primitive from NIF in the SG containing the Protocol Data with DPC X and SSN value S. 2. Check A: DATA message will be received at the AS1. 3. Repeat the above test case for MTP-Transfer Ind primitive containing Protocol Data with DPC X and SSN value T. DATA message should be received at AS2 Sunil-Prashant-Ashok, HSS [Page 61] Internet Draft Test Specs for M3UA Feb 2001 "Message Routing based on DPC+SIO" + TEST NUMBER : 1.8.4 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 1.4.2.1 + TITLE : Message Routing + SUBTITLE : Message Routing based on DPC+SIO + PURPOSE: To check that if NIF sends a MTP-Transfer message containing Protocol DATA to send to the AS then it is sent to the correct AS. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and all ASP i.e. ASP1and ASP2 and all ASP are in Active state. Routing context P consists of DPC X and SIO S. Routing context Q consists of DPC X and SIO T. Also arrange the data in NIF at SG such that MTP-Transfer Indication Primitives is sent to the AS with the following parameter combination: Protocol Data with DPC X and SIO S Protocol Data with DPC X and SIO T EXPECTED MESSAGE SEQUENCE : AS1 AS2 SG NIF All AS are active <---------- MTP-Transfer Ind DPC X SIO S <---------------------------- DATA <---------- MTP-Transfer Ind DPC X SIO T <---------------- DATA TEST DESCRIPTION: 1. Send MTP-Transfer indication Primitive from NIF in the SG containing the Protocol Data with DPC X and SIO value S. 2. Check A: DATA message will be received at the AS1. 3. Repeat the above test case for MTP-Transfer Ind primitive containing Protocol Data with DPC Y and SIO value T. DATA message should be received at AS2 Sunil-Prashant-Ashok, HSS [Page 62] Internet Draft Test Specs for M3UA Feb 2001 "Routing for Data not matching any routing context" + TEST NUMBER : 1.8.5 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 1.4.2.1 + TITLE : Message Routing + SUBTITLE : Routing for Data not matching any routing context + PURPOSE: To check that if NIF sends a MTP-Transfer message containing Protocol DATA which does not match to any routing context then default routing is given to this message. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP1 and ASP2 and ASP and ASP2 are Active. Routing context P consists of DPC X and SSN S. Routing context Q consists of DPC X and SSN T. Also arrange the data in NIF at SG such that MTP-Transfer Indication Primitives is sent to the AS with DPC X and SSN other than S or T. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM AS is Active <----------- MTP-Transfer Ind DPC X & SSN <> S or T Error ind. ----------> TEST DESCRIPTION: 1. Send MTP-Transfer indication Primitive from NIF in the SG containing the Protocol Data having DPC and SSN such that theu don't match any routing key. 2. Check A: Error should be returned or some default routing will be given to this message. 3. Repeat the above test case if routing context is defined based on DPC+CIC. Send MTP-Transfer Ind from NIF containing protocol data with DPC+CIC that doesn't match this routing key. Response will be same as in the above case. 4. Repeat the above test case if routing context is defined based on DPC+SIO. Send MTP-Transfer Ind from NIF containing protocol data with DPC+SIO that doesn't match this routing key. Response will be same as in the above case. 5. Repeat the above test case if routing context is defined based on DPC. Send MTP-Transfer Ind from NIF containing protocol data with DPC that doesn't match this routing key. Response will be same as in the above case. Sunil-Prashant-Ashok, HSS [Page 63] Internet Draft Test Specs for M3UA Feb 2001 "Loadshare Mode of Traffic handling in ASPAC message" + TEST NUMBER : 1.9.1 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 5.1.3 and 4.3.3.4 + TITLE : Mode of Traffic Handling by ASP in ASPAC message + SUBTITLE : Loadshare mode of Traffic Handling + PURPOSE: To check that if an ASPAC message is received with Type field containing Loadshare mode then traffic is distributed between this ASP and all other active ASPs. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP1 and ASP2. ASP1 is active. Arrange the DATA in AS such that it sends ASPAC message for ASP2 with Loadshare mode and routing context P on stream 0. Also mode of traffic handling for AS at SG is Loadshare. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 is Active ASPAC(ASP2) ----------------> Loadshare Mode Status Ind -------> <--------------- ASP-Active-Ack <----------- MTP-Transfer Ind DPC X & CIC S To ASP1 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC T To ASP2 <--------------- DATA ASPIA(ASP1) ----------------> Status Ind -------> <--------------- ASP-Inactive-Ack <----------- MTP-Transfer Ind DPC X & CIC S To ASP2 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC T To ASP2 <--------------- DATA Sunil-Prashant-Ashok, HSS [Page 64] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPAC message with Loadshare mode in type field and Routing context P from AS to SG for ASP2. 2. Check A: ASP-Active-Ack message should be received at AS. 3. Check B: Traffic should also go ASP2 which has sent the ASPAC. Check this by sending MTP-Transfer Ind from NIF at SG containing different CIC values assuming traffic is load shared based on the CIC. 4. Send ASPIA message from ASP1 to the SG. 5. ASP1 will receive ASP-Inactive-Ack from SG. 6. Check that all the traffic is now going to ASP2. Sunil-Prashant-Ashok, HSS [Page 65] Internet Draft Test Specs for M3UA Feb 2001 "Loadshare (Standby) Mode of Traffic handling in ASPAC message" + TEST NUMBER : 1.9.2 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 5.1.3 and 4.3.3.4 + TITLE : Mode of Traffic Handling by ASP in ASPAC message + SUBTITLE : Loadshare (Standby) mode of Traffic Handling + PURPOSE: To check that if an ASPAC message is received with Type field containing Loadshare (Standby) mode then traffic is not started to the ASP until the remote peer determines that additional resources are needed. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. There are three ASPs in AS, ASP1, ASP2, ASP3. All are having SCTP Associations with SG.ASP1 and ASP2 are active ASP3 is inactive. Arrange the data in AS such that it sends ASPAC message with Loadshare mode (Standby) for ASP3. Also mode of traffic Handling for AS at SG is also loadshare mode (Standbby). EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1&ASP2 are Active ASPAC(ASP3) ----------------> Loadshare Mode (Standby) Status Ind -------> To ASP3 <--------------- ASP-Active-Ack (for ASP3) <----------- MTP-Transfer Ind DPC X & CIC S To ASP1 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC T To ASP2 <--------------- DATA ASPIA(ASP1) ----------------> Status Ind -------> To ASP1 <--------------- ASP-Inactive-Ack (for ASP1) <----------- MTP-Transfer Ind DPC X & CIC S To ASP2 <--------------- DATA <----------- MTP-Transfer Ind To ASP3 <--------------- DATA DPC X & CIC T Sunil-Prashant-Ashok, HSS [Page 66] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPAC message with Loadshare mode (Standby) in type field from AS to SG to SG. 2. Check A: ASP-Active-Ack message should be received at AS. 3. Check B: All trafic should still go to ASP1 and ASP2 only. 4. Send ASPIA message from ASP1 to the SG. 5. ASP1 will receive ASP-Inactive-Ack from SG. 6. Check that all the traffic is now going to ASP2 and ASP3 ( which has sent the ASPAC with loadshare mode (Standby). Sunil-Prashant-Ashok, HSS [Page 67] Internet Draft Test Specs for M3UA Feb 2001 "Loadshare Mode of Traffic handling by ASP in ASPIA message" + TEST NUMBER : 1.9.3 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 5.1.3 and 4.3.3.4 + TITLE : Mode of Traffic Handling + SUBTITLE : Loadshare mode of Traffic Handling by ASP in ASPIA message + PURPOSE: To check that if an ASPIA message is received with Type field containing Loadshare mode and no other active ASPs are available then a NTFY (Insufficient ASPs) is sent to all inactive ASPs. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP1, ASP2 and ASP3. ASP1 and ASP2are active and ASP3 is active in standby Mode and all are in loadshare mode of traffic handling. Arrange the DATA in AS such that it sends ASPIA message for ASP2 with Loadshare mode and routing context P on stream 0. Also mode of traffic handling for AS at SG is Loadshare.Data at SG is arranged in such a way that a minimum of 2 ASPs are required for handling the traffic for routing context P. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1&ASP2 are Active ASPIA(ASP2) ----------------> Loadshare Mode Status Ind -------> To ASP2 <--------------- ASP-Inactive-Ack <----------- MTP-Transfer Ind DPC X & CIC S To ASP2 <--------------- DATA To ASP3 <--------------- DATA ASPIA(ASP3) ----------------> Loadshare Mode Status Ind -------> To ASP3 <--------------- ASP-Inactive-Ack To ASPs <--------------- NTFY (Insufficient ASPs) with routinfg context P To ASP2 <--------------- DATA Sunil-Prashant-Ashok, HSS [Page 68] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPIA message with Loadshare mode in type field and Routing context P from AS to SG for ASP2. 2. Check A: ASP-Inactive-Ack message should be received at AS. 3. Check B: Traffic should go to ASP1 and ASP3 which has sent the ASPAC. Check this by sending MTP-Transfer Ind from NIF at SG containing different CIC values assuming traffic is load shared based on the CIC. 4. Send ASPIA message with Loadshare mode in type field and Routing context P from ASP3 to the SG. 5. ASP3 will receive ASP-Inactive-Ack from SG. 6. Check that all the traffic is now going to ASP2. 7. Check NTFY (Insufficient ASPs) should be received at all the three ASPs. Sunil-Prashant-Ashok, HSS [Page 69] Internet Draft Test Specs for M3UA Feb 2001 "Over-ride Mode of Traffic handling" + TEST NUMBER : 1.9.4 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : Mode of Traffic Handling by ASP in ASPAC message + SUBTITLE : Over-ride mode of Traffic Handling + PURPOSE: To check that if an ASPAC message is received with Type field containing over-ride mode then all traffic is sent to that ASP which sent ASPAC message. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. ASP1 in AS is active. Arrange the DATA in AS such that it sends ASPAC message with over-ride mode and routing context P for ASP2 on stream 0. Also mode of traffic handling for AS at SG is also override mode. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 is Active ASPAC(ASP2) ----------------> Override Mode Status Ind -------> <----------- MTP-Transfer Ind DPC X & CIC S (Data is buffered and will be send to SG when ASP2 takes over.) To ASP2 <--------------- ASP-Active-Ack To ASP1 <--------------- NTFY(Alternate ASP-Active) To ASP2 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC S To ASP2 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC T To ASP2 <--------------- DATA Sunil-Prashant-Ashok, HSS [Page 70] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send ASPAC message with override mode in type field and Routing context P from AS to SG for ASP2. 2. Check A: ASP2 will receive ASP-Active-Ack from SG. 3. NTFY message with status Alternate ASP-Active should be received at ASP1. 4. Check B: All traffic should go to ASP2 which has sent the ASPAC. Check this by sending MTP-Transfer Ind from NIF at SG. Sunil-Prashant-Ashok, HSS [Page 71] Internet Draft Test Specs for M3UA Feb 2001 "Over-ride Mode of Traffic handling" + TEST NUMBER : 1.9.5 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : Mode of Traffic Handling by ASP in ASPAC message + SUBTITLE : To check if ASP receives data during Over-ride mode of Traffic Handling changeover. + PURPOSE: To check that if an ASPreceives data during the changeover of ASPs in Override modeof traffic handling. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. ASP1 in AS is active. Arrange the data in AS such that it sends ASPAC message with over-ride mode and routing context P for ASP2 on stream 0 and ASP1 receives the DATA before it receives NTFY message. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 is Active ASPAC(ASP2) ----------------> Override Mode Status Ind -------> DATA ----------------> (Data is buffered and will be passed on when ASP2 becomes active.) To ASP2 <--------------- ASP-Active-Ack To ASP1 <--------------- NTFY(Alternate ASP-Active) DATA -----------> DATA ----------------> (From ASP2) DATA -----------> TEST DESCRIPTION: 1. Send ASPAC message with override mode in type field and Routing context P from AS to SG for ASP2. 2. Send DATA from ASP1 to SG before receiving Ack message. 3. Check A: The data is buffered at SG. 4. ASP2 receives ASP-Active-Ack and ASP1 receives a NTFY message with status as Alternate ASP Active. 5 Check B: The data buffered at SG is passed further.And now it will receive data from ASP2. Sunil-Prashant-Ashok, HSS [Page 72] Internet Draft Test Specs for M3UA Feb 2001 "Over-ride Mode of Traffic handling" + TEST NUMBER : 1.9.6 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : Mode of Traffic Handling by ASP in ASPAC message + SUBTITLE : No NTFY message to the ASP whose status is not changed in Over-ride mode of Traffic Handling + PURPOSE: To check that if an ASPAC message is received with Type field containing over-ride mode then NTFY Altenate ASP Active is send to that ASP only whose traffic is going to be handled by the sending ASP. All traffic is sent to that ASP which sent ASPAC message. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. ASP1 and ASP2 are active and handling the traffic for routing context P and Q, ASP3 is Inactive. Now send the ASPAC with traffic handling mode as override for routing context P on stream 0. Also the mode of traffic handling for AS at SG is also override mode. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 and ASP2 are Active <----------- MTP-Transfer Ind Routing Context P To ASP1 <--------------- DATA <----------- MTP-Transfer Ind Routing Context Q To ASP2 <--------------- DATA ASPAC(ASP3) ----------------> Routing Context P Override Mode Status Ind -------> To ASP3 <--------------- ASP-Active-Ack To ASP1 <--------------- NTFY(Alternate ASP-Active) <----------- MTP-Transfer Ind Routing Context P To ASP3 <--------------- DATA <----------- MTP-Transfer Ind Routing Context Q To ASP2 <--------------- DATA Sunil-Prashant-Ashok, HSS [Page 73] Internet Draft Test Specs for M3UA Feb 2001 TEST DESCRIPTION: 1. Send data with routing context as P and Q to ASP, ASP1 and ASP2 will receive the data respectively. 2. Send ASPAC for ASP3 with routing context P and traffic handling mode as override. 3. Check A: ASP3 will receive ASP Active Ack and NTFY message with status Alternate ASP-Active should be received by ASP1. 3. Send data with routing context as P and Q to ASP, ASP3 and ASP2 will receive the data respectively. 4. Check B: NTFY message with status Alternate ASP-Active is not received by ASP2. Sunil-Prashant-Ashok, HSS [Page 74] Internet Draft Test Specs for M3UA Feb 2001 "Over-ride (Standby) Mode of Traffic handling" + TEST NUMBER : 1.9.7 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.4 + TITLE : Mode of Traffic Handling by ASP in ASPAC message + SUBTITLE : Over-ride (Standby) mode of Traffic Handling + PURPOSE: To check that if an ASPAC message is received with Type field containing over-ride (Standby) mode then all traffic is sent to that ASP which sent ASPAC message after all the previously active ASP transitions to inactive or down . + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. ASP1 in AS is active. Arrange the DATA in AS such that it sends ASPAC message with over-ride mode (Standby) and routing context P for ASP2 on stream 0. Also mode of traffic handling for AS at SG is also override mode (Standby). EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 is Active a)ASPAC(ASP2) ----------------> Override Mode (Standby) Status Ind -------> To ASP2 <--------------- ASP-Active-Ack (for ASP2) <----------- MTP-Transfer Ind DPC X & CIC S To ASP1 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC T To ASP1 <--------------- DATA b)ASPIA(ASP1) ----------------> Status Ind -------> To ASP1 <--------------- ASP-Inactive-Ack (for ASP1) <----------- MTP-Transfer Ind DPC X & CIC S To ASP2 <--------------- DATA TEST DESCRIPTION: 1. Send ASPAC message with override mode (Standby) in type field and Routing context P from AS to SG for ASP2. 2. Check A: ASP2 will receive ASP-Active-Ack from SG. 3. Check B: All traffic should still go to ASP1. 4. Send ASPIA message from AS to SG for ASP1. 5. Check B: All traffic should go to ASP2 which has sent the ASPAC with override mode (standby). Check this by sending MTP-Transfer Ind from NIF at SG. Sunil-Prashant-Ashok, HSS [Page 75] Internet Draft Test Specs for M3UA Feb 2001 "Loadshare Mode of Traffic handling in ASPIA message" + TEST NUMBER : 1.10 + Reference: draft-ietf-sigtran-m3ua-05.txt Clause 4.3.3.5 + TITLE : Mode of Traffic Handling by ASP in ASPIA message + SUBTITLE : Loadshare mode of Traffic Handling + PURPOSE: To check that if an ASPIA message is received with Type field containing Loadshare mode then all traffic is sent to other ASP. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP1 and ASP2. ASP1 and ASP2 in AS are active and are in loadshare mode of traffic handling. Arrange the DATA in AS such that it sends ASPIA message with Loadshare mode and routing context P for ASP1 on stream 0. Also mode of traffic handling for AS at SG is Loadshare. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 & ASP2 are Active ASPIA(ASP2) ----------------> (Mode=Loadshare) Status Ind -------> To ASP2 <--------------- ASP-Inactive-Ack <----------- MTP-Transfer Ind DPC X & CIC S To ASP1 <--------------- DATA <----------- MTP-Transfer Ind DPC X & CIC T To ASP1 <--------------- DATA TEST DESCRIPTION: 1. Send ASPIA message with Loadshare mode in type field and Routing context P from ASP1 to SG. 2. Check A: SG should send ASP-Inactive-Ack message. 3. Check B: All traffic should go to ASP1. Check this by sending MTP-Transfer Ind from NIF at SG with Protocol Data containing different SLS values. Sunil-Prashant-Ashok, HSS [Page 76] Internet Draft Test Specs for M3UA Feb 2001 "ERROR Message Hand