INTERNET-DRAFT Anshoo Sharma[EDITOR] Aricent Issued: Jan 2002 Expires: Jul 2003 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. Anshoo Sharma, Aricent [Page 1] Internet Draft M3UA Conformance Test Plan Jan 2003 Abstract This document presents the test specification for M3UA (MTP3 User Adaptation) protocol (RFC 3332), 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.......................................................3 1.1 Terms Used....................................................3 1.2 Change History................................................6 2. General Principles of M3UA Tests...................................6 2.1 Presentation of test descriptions.............................6 3. Test Configurations................................................7 3.1 Presentation of test Configurations...........................7 3.2 Configuration for testing the M3UA at SGP.....................8 3.3 Configuration for testing the M3UA at ASP....................12 4. Test Cases for Testing M3UA at SGP...............................16 4.1 Management...................................................16 4.2 Transfer.....................................................35 4.3 SSNM.........................................................47 4.4 ASPSM........................................................56 4.5 ASPTM........................................................64 4.6 SCTP Connection Management..................................101 4.7 Dynamic Routing Key Management..............................106 5. Test Cases for Testing M3UA at ASP..............................116 5.1 Management..................................................116 5.2 Transfer....................................................125 5.3 SSNM........................................................139 5.4 ASPSM.......................................................149 5.5 ASPTM.......................................................154 5.6 SCTP Connection Management..................................163 5.7 Dynamic Routing Key Management..............................167 6. Acknowledgements.................................................169 7. Authors' Addresses...............................................169 8. References.......................................................169 Copyright Statement..............................................170 Anshoo Sharma, Aricent [Page 2] Internet Draft M3UA Conformance Test Plan Jan 2003 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 SIO/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. Note that there is a 1:1 relationship between an AS and a Routing Key. Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or backup process of an Application Server (e.g., part of a distributed virtual switch or database). Examples of ASPs are processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP endpoint and may be configured to process signalling 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 M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. Failover - The capability to reroute signalling 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. Failover also applies upon the return to service of a previously unavailable Application Server Process. Anshoo Sharma, Aricent [Page 3] Internet Draft M3UA Conformance Test Plan Jan 2003 Host - The computing platform that the process (SGP, ASP or IPSP) is running on. Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the M3UA layer and a local management entity. Linkset - A number of signalling links that directly interconnect two signalling points, which are used as a module. MTP - The Message Transfer Part of the SS7 protocol. MTP3 - MTP Level 3, the signalling network layer of SS7 MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.). Network Appearance - The Network Appearance is a M3UA local reference shared by SG and AS (typically an integer) that together with an Signaling Point Code uniquely identifies an SS7 node by indicating the specific SS7 network it belongs to. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks. Network Byte Order: Most significant byte first, a.k.a Big Endian. Routing Key: A Routing Key describes a set of SS7 parameters and parameter values that uniquely define the range of signalling traffic to be handled by a particular Application Server. Parameters within the Routing Key cannot extend across more than a single Signalling Point Management Cluster. Routing Context - A value that uniquely identifies a Routing Key. Routing Context values are either configured using a configuration management interface, or by using the routing key management procedures defined in this document. Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, backup, load-sharing or broadcast process of a Signalling Gateway. Anshoo Sharma, Aricent [Page 4] Internet Draft M3UA Conformance Test Plan Jan 2003 Signalling Gateway - An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network [11]. An SG appears to the SS7 network as an SS7 Signalling Point. An SG contains a set of one or more unique Signalling Gateway Processes, of which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and to the supported Application Servers. Signalling Process - A process instance that uses M3UA to Communicate with other signalling processes. An ASP, an SGP and an IPSP are all signalling processes. Signalling Point Management Cluster (SPMC) - The complete set of Application Servers represented to the SS7 network under a single MTP entity (Signalling Point) in one specific Network Appearance. SPMCs are used to aggregate the availability, congestion, and user part status of an MTP entity (Signalling Point) that is distributed in the IP domain, for the purpose of supporting MTP3 management procedures towards the SS7 network. In some cases, the SG itself may also be a member of the SPMC. In this case, the SG availability /congestion /User_Part status should also be taken into account when considering any supporting MTP3 management actions. Stream - A stream refers to an SCTP stream; a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the unordered delivery service. ASPSM, ASPTM, SSNM - ASP State Maintenance Messages, ASP Traffic Maintenance Messages, Signalling System Network Management Messages. Anshoo Sharma, Aricent [Page 5] Internet Draft M3UA Conformance Test Plan Jan 2003 1.2 Change History 1.2.1 Changes from draft-anshoo-test-spec-m3ua-00.txt 1. Test Case for Missing Mandatory Parameter. Test Case Number (SGP Side) : 1.15 Test Case Number (ASP Side) : 1.9 2. Test Case for Unsupported Dynamic Registration Test Case Number (SGP Side) : 1.16 3. Test Case for sending ASP Failure Notification from SGP. Test Case Number (SGP Side) : 1.17 4. Test Case for sending DATA from ASP only in Active State of AS. Test Case Number (ASP Side) : 2.7 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.). Anshoo Sharma, Aricent [Page 6] Internet Draft M3UA Conformance Test Plan Jan 2003 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: 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. Anshoo Sharma, Aricent [Page 7] Internet Draft M3UA Conformance Test Plan Jan 2003 3.2 Configuration for testing the M3UA at SGP: 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. SG routes Data to SS7 for PC Z. SGP serves SG. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN SG +-------------+ +--------------+ | SGP/IPSP | | AS DPC = X | | under Test | | ------- | | DPC = Z |-------------------------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Fig 1: Configuration A 3.2.2 Configuration B: This configuration is used for all the procedures of tests concerning one ASP in two AS which is 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 and SGP serves SG. Routing Context P and Q may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN Anshoo Sharma, Aricent [Page 8] Internet Draft M3UA Conformance Test Plan Jan 2003 +--------------+ SG | AS1 DPC X | +-------------+ | ------- | | |-------------------------------| | ASP1 | | | SGP/IPSP | | ------- | | Under Test | +--------------+ | DPC Z | +--------------+ | |-------------------------------| AS2 DPC Y | +-------------+ | ------- | | | ASP1 | | | ------- | +--------------+ Fig 2: Configuration B 3.2.3 Configuration C: This configuration is used for all the procedures of tests concerning two or more ASP in one AS. Configuration C is shown in figure 3. AS is handling the traffic for routing context P and N/w Appearance A. ASP1 and ASP2 can be in FAIL-OVER mode, LOADSHARE or BROADCAST mode of traffic handling. Point Code of SG/IPSP is Z and SGP serves SG. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN +--------------+ SG | AS DPC X | +-------------+ | ------- | | |-------------------------------|-| ASP1 | | | SGP/IPSP | | ------- | | Under Test | | ------- | | DPC Z | | | ASP2 | | | |-------------------------------|- ------- | +-------------+ +--------------+ Fig 3: Configuration C Anshoo Sharma, Aricent [Page 9] Internet Draft M3UA Conformance Test Plan Jan 2003 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. SGP serves SG. 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. +--------------+ SG | AS1 DPC X | +-------------+ | ------- | | |-------------------------------| | ASP1 | | | SGP/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. SGP serves SG. Anshoo Sharma, Aricent [Page 10] Internet Draft M3UA Conformance Test Plan Jan 2003 +--------------+ SG | AS1 DPC X | +-------------+ | ------- | | |-------------------------------| | ASP1 | | | SGP/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. SGP serves SG. +--------------+ SG | AS1 DPC X | +-------------+ | ------- | | |-------------------------------| | ASP1 | | | SGP/IPSP | | ------- | | Under Test | +--------------+ | DPC Z | +--------------+ | |-------------------------------| AS2 DPC X | | |-------+ | ------- | +-------------+ | | | ASP2 | | | | ------- | | +--------------+ | +--------------+ | | AS3 DPC X | +-----------------------|- ------- | | | ASP 3 | | | ------- | +--------------+ Fig 6: Configuration F Anshoo Sharma, Aricent [Page 11] Internet Draft M3UA Conformance Test Plan Jan 2003 3.3 Configuration for testing the M3UA at ASP 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. SG routes Data to SS7 for PC Z and SGP serves SG. 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 | | SGP/IPSP | | under Test | | DPC = Z | | DPC = X |-------------------------------| SG | | | | | +-------------+ +--------------+ Fig 7: Configuration G 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 DPC in the SEP network. Configuration H is shown in figure 8. SGP1/IPSP1 serving SG1 and SGP2/IPSP2 serving SG2 are handling the traffic for N/w Appearance A. Point Code of SG1/IPSP1 is Y and of SG2/IPSP2 is Z. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN Anshoo Sharma, Aricent [Page 12] Internet Draft M3UA Conformance Test Plan Jan 2003 +--------------+ | SGP1/IPSP1 | +-------------+ | DPC Y | | |-------------------------------| SG1 | | ASP1 | | | | Under Test | -------------- | DPC X | +--------------+ | |-------------------------------| SGP2/IPSP2 | +-------------+ | DPC Y | | SG2 | | | +--------------+ 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 +--------------+ | Under Test | | AS1 DPC X | | ------- | +----------------+ | | ASP1 | | ---------------------| | | ------- | | SGP / IPSP | +--------------+ | | +--------------+ | DPC Z | | AS2 DPC Y | | SG | | ------- | ---------------------| | | | ASP1 | | +----------------+ | ------- | | Under Test | +--------------+ Fig 9: Configuration I Anshoo Sharma, Aricent [Page 13] Internet Draft M3UA Conformance Test Plan Jan 2003 3.3.4 Configuration J: This configuration is used for all the procedures of tests concerning two SGPs in an SG connected to the same ASP. SG is handling traffic for Point Code Y and SGP1 and SGP2 are serving the SG. The ASP is handling Traffic for Routing Context P. Configuration J is shown in figure 10. The SG can be in Broadcast, Loadshare or Override Mode. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN +--------------+ | SGP1 | +-------------+ | DPC Y | | |-------------------------------| SG | | ASP1 | | | | Under Test | +--------------+ | DPC X | +--------------+ | |-------------------------------| SGP2 | +-------------+ | DPC Y | | SG | | | +--------------+ Fig 10 : Configuration J 3.3.4 Configuration K: This configuration is used for all the procedures of tests concerning four SGPs connected to the same ASP. Both SG1 and SG2 are handling traffic for PC X and Y. ASP1 is handling traffic for routing context P. Point Code of SG1/IPSP1 is Y and of SG2/IPSP2 is Z. The SGs can be in Broadcast, Loadshare or Override Mode. Configuration J is shown in Figure 11. Routing Context P may be based on the following information: 1. DPC 2. DPC+CIC+SIO 3. DPC+SIO 4. DPC+SSN Anshoo Sharma, Aricent [Page 14] Internet Draft M3UA Conformance Test Plan Jan 2003 +--------------+ +-------------+ | SGP1 (SG1) | | |-------------------------------| DPC Y | | | +--------------+ | | +--------------+ | | | SGP2 (SG1) | | ASP1 |-------------------------------| DPC Y | | Under Test | +--------------+ | DPC X | +--------------+ | | | SGP3 (SG2) | | |-------------------------------| DPC Y | | | +--------------+ | | +--------------+ | |-------------------------------| SGP4 (SG2) | +-------------+ | DPC Y | +--------------+ Fig 11 : Configuration K Anshoo Sharma, Aricent [Page 15] Internet Draft M3UA Conformance Test Plan Jan 2003 4. Test Cases for Testing M3UA at SGP Following Tests are to be carried out when the Implementation Under Test is SGP. 4.1 MANAGEMENT Test Cases covering MANAGEMENT Procedures. "Notify Message with AS Status" + TEST NUMBER : 1.1 + 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 SGP and ASP and ASP is Active. Also arrange the data in ASP such that ASPDN, ASPUP messages are sent from ASP to SGP 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 SGP SM ASP is active ASPDN ---------------> (ASP1) Status Ind ----------> <-------------- ASP-Down-Ack | Status Ind ---------> (AS Pending) | |Time = z sec | |Timer T(r) Expiry | --- Status Ind ---------> (AS Down) Anshoo Sharma, Aricent [Page 16] Internet Draft M3UA Conformance Test Plan Jan 2003 ASPUP ---------------> (ASP1) Status Ind -----------> <-------------- ASP-Up-Ack <-------------- NTFY (AS-Inactive) ASPAC ---------------> (ASP1) Status Ind -----------> <-------------- ASP-Active-Ack <-------------- NTFY (AS-Active) ASPIA ---------------> (ASP1) Status Ind -----------> <-------------- ASP-Inactive-Ack <-------------- NTFY (AS-Pending) TEST DESCRIPTION: 1. Send ASPDN message for ASP1 from ASP to the SGP. 2. Check A: ASPDN is acknowledged by ASP-Down-Ack message at the ASP. 3. Send ASPUP message to SGP. 4. Check B: SGP responds with ASP-UP-Ack message and NTFY (AS-Inactive). 5. Send ASPAC message with Routing Context P and check SGP 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 SGP responds with ASP Inactive-Ack and NTFY with status AS-Pending. 7. Check E: NTFY message is received on stream 0. Anshoo Sharma, Aricent [Page 17] Internet Draft M3UA Conformance Test Plan Jan 2003 "Notify Message with Insufficient Resources in AS" + TEST NUMBER : 1.2 + TITLE : AS management + SUBTITLE : Notify Message with Insufficient Resources in AS + PURPOSE: To check that if the number of Active ASPs in a Loadshare / Broadcast AS goes below the minimum number of required ASPs then a NTFY message for Insufficient Resources is sent to INACTIVE ASPs. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1 and ASP2. ASP1 is Active for RC P and ASP2 is Inactive in SGP. The AS is in Loadshare mode and the minimum number of Active ASPs required is two. Also arrange the data in ASP1 such that ASPIA messages is sent from ASP1 to SGP for Routing Context P. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 SGP SM ASP1 is Active ASP2 is Active ASPIA ---------------> (ASP1) <-------------- ASP-Inactive-Ack Status Ind ----------> (ASP2)<---------- NTFY (Insufficient Resources) (ASP1)<----------------- NTFY (Insufficient Resources) TEST DESCRIPTION: 1. Send ASPIA message from ASP1 to the SGP. 2. Check A: SGP sends a NTFY Message with Insufficient Resources for RC P to ASP2 which is in ASP-Inactive State. 3. Check B: ASPIA is acknowledged by ASPIA-Ack message by the SGP to ASP1. 4. Repeat the Test Case when the AS is in Broadcast Mode. Note: This NTFY message might not be provisioned by some implementations. Anshoo Sharma, Aricent [Page 18] Internet Draft M3UA Conformance Test Plan Jan 2003 "Invalid Version Error" + TEST NUMBER : 1.3 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Version Error + PURPOSE: To check that if any message with Invalid version is received at the SGP then SGP responds with ERROR message containing cause "Invalid Version" and diagnostic information filled with the version the SGP supports. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Active. Also arrange the data in ASP such that ASPIA message is sent with the version other than Version 1.0 protocol to SGP. Type field can be any valid value and fill the routing context with any value. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is active ASPIA ----------------> Version = 2 <--------------- ERROR Cause = Invalid Version TEST DESCRIPTION: 1. Send ASPIA message ASP to SGP 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 ASP to SGP like ASPAC, ASPUP, ASPDN, DAUD and DATA. In all these cases ERROR message will be received with the same cause. Anshoo Sharma, Aricent [Page 19] Internet Draft M3UA Conformance Test Plan Jan 2003 "Invalid Traffic Handling Mode Error" + TEST NUMBER : 1.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 SGP, SGP responds with ERROR message containing cause "Invalid Traffic Handling Mode". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP 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 SGP for AS is Override. Fill value P in Routing context parameter. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Inactive ASPAC ----------------> Type = Loadshare <--------------- ERROR Cause = Invalid traffic Handling Mode TEST DESCRIPTION: 1. Send ASPAC message from ASP to SGP containing Type field Loadshare. Mode of Traffic handling for AS at SGP 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 SGP 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. Anshoo Sharma, Aricent [Page 20] Internet Draft M3UA Conformance Test Plan Jan 2003 "Invalid Traffic Handling Mode Error if there are two ASP in one AS" + TEST NUMBER : 1.5 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Traffic Handling Mode Error if there are two ASP in one AS + PURPOSE: To check that if ASPAC or ASPIA message is received with Type parameter incompatible with the traffic handling mode currently used in AS at SGP, SGP responds with ERROR message containing cause "Invalid Traffic Handling Mode". + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP1 and ASP2 are Up. Arrange the data in ASPs 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 SGP for AS is Override Mode. Fill value P in Routing context parameter. EXPECTED MESSAGE SEQUENCE : ASP SGP 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 SGP containing Type field Override. 2. Check A: ASP-Active-Ack message is received at the ASP. 3. Send ASPAC message from ASP2 to SGP 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 SGP being different from this Type. Anshoo Sharma, Aricent [Page 21] Internet Draft M3UA Conformance Test Plan Jan 2003 6. Repeat the test case with Type field having value that is not defined. 7. Repeat all the above tests for ASPIA message. Anshoo Sharma, Aricent [Page 22] Internet Draft M3UA Conformance Test Plan Jan 2003 "Unrecognized Message Type" + TEST NUMBER : 1.6 + TITLE : Invalid Message Handling + SUBTITLE : Unrecognized Message Type + PURPOSE: To check that if a message with message type not defined is received at SGP, SGP responds with ERROR message containing cause "Invalid Message Type". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP1 is active. Arrange the data in ASP such that a message with Message type not defined is sent to SGP. Let the other parameters in the message be like any other message. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active Message ----------------> Message Type=0x408 <--------------- ERROR Cause = Invalid Message Type DATA ----------------> N/w Appearance A MTP-Transfer Ind -------> TEST DESCRIPTION: 1. Send a message with message type 0x408 or any other value which is not defined from ASP to SGP. 2. Check A: ERROR message is received at the ASP containing cause Invalid Message Type. 3. Check B: State of AS at SGP is not disturbed. 4. Repeat the above test cases by sending DUNA, DAVA, DUPU, DRST messages from ASP which the SGP is not expected to receive. In this case Error will be reported to the SM and Message will be discarded. Anshoo Sharma, Aricent [Page 23] Internet Draft M3UA Conformance Test Plan Jan 2003 "Invalid Network Appearance" + TEST NUMBER : 1.7 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Network Appearance and Invalid Routing Context + PURPOSE: To check that if a message with invalid network appearance i.e. network appearance not defined at SGP then SGP responds with ERROR message containing cause "Invalid Network Appearance". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is in AS-Active state i.e. ASP1 is active. Arrange the data in ASP such that DATA message with Network Appearance other than A is sent to SGP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP 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 SGP. 2. Check A: ERROR message containing cause Invalid Network Appearance should be received at AS. 3. Check B: State of AS at SGP is not disturbed. 4. Repeat the Test for an unconfigured Routing Context ERROR message with Invalid Routing Context must be returned. Note: Network Appearance and Routing Context parameters are optional. In some implementation this parameter may not come in DATA message. In those implementations, this test case need not be tested. Anshoo Sharma, Aricent [Page 24] Internet Draft M3UA Conformance Test Plan Jan 2003 "Message length less than the length of mandatory Parameters" + TEST NUMBER : 1.8 + 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 SGP and ASP 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. EXPECTED MESSAGE SEQUENCE : ASP SGP NIF AS is Active ASPIA ----------------> Message Length = 2 <--------------- Error ( Unsupported Message Type) DATA ----------------> N/w appearance A, RC = P MTP-Transfer ---------> TEST DESCRIPTION: 1. Send ASPIA message with length parameter filled with value less than the length of type field to the SGP. 2. Check A: SGP will send an Error message with Unsupported Message Type parameter. 3. Check B: State of AS at SGP is not disturbed. 4. Repeat the above test case for other messages like ASPAC, ERROR, ASPDN. Anshoo Sharma, Aricent [Page 25] Internet Draft M3UA Conformance Test Plan Jan 2003 "ERROR Message Handling" + TEST NUMBER : 1.9 + TITLE : ERROR + SUBTITLE : Handling of Received Error + PURPOSE: To check that if an error is received then that is reported to the SM and no action is taken against that. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is active. Arrange data in ASP such that ERROR with cause invalid version is sent to the SGP. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active ERROR ----------------> cause=Invalid version Error -------> TEST DESCRIPTION: 1. Send ERROR message with cause invalid version from ASP to SGP. 2. Check A: Error should be reported to the SM. 3. Check B: Further action at the SGP are implementation dependent. SM may tear down the connection or no action may be taken. 4. Repeat the test case for other cause values in ERROR message. Anshoo Sharma, Aricent [Page 26] Internet Draft M3UA Conformance Test Plan Jan 2003 "Error - Refused - Management Blocking" + TEST NUMBER : 1.10 + TITLE : ERROR + SUBTITLE : ASPUP and ASPAC messages are sent for a Blocked ASP then ERROR message is sent from SGP. + PURPOSE: To check that if an error is received then that is reported to the SM and no action is taken against that. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in ASP-Down state. Arrange data in ASP such that ASPUP and ASPAC messages are sent to SGP with valid parameters. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Down ASPUP ----------------> <--------------- Error (Refused - Management Blocking) ASPAC ----------------> <--------------- Error (Refused - Management Blocking) TEST DESCRIPTION: 1. Send ASPUP message from ASP to SGP. 2. Check A: Error should be sent from SGP with "Refused - Management Blocking" to ASP. 3. Send ASPAC message from ASP to SGP. 4. Check A: Error should be sent from SGP with "Refused - Management Blocking" to ASP. Anshoo Sharma, Aricent [Page 27] Internet Draft M3UA Conformance Test Plan Jan 2003 "Error - Invalid Stream Identifier" + TEST NUMBER : 1.11 + TITLE : ERROR + SUBTITLE : Stream Zero for Non-Transfer Messages for Multiple Stream SCTP association. + PURPOSE: If Non Transfer messages with the exception of ASPTM, BEAT and BEAT-Ack are sent on any Stream other than Zero then ERROR message is sent from SGP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in ASP-Down state. Arrange data in ASP such that ASPUP is sent to SGP with valid parameters on stream 1. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Down ASPUP ----------------> (stream 1) <--------------- Error (Invalid Stream Identifier) TEST DESCRIPTION: 1. Send ASPUP message from ASP to SGP on Stream 1. 2. Check A: Error should be sent from SGP with "Invalid Stream Identifier" to ASP. 3. Repeat the Test Case for all Non-Transfer messages other than ASPTM, BEAT and BEAT-Ack. Anshoo Sharma, Aricent [Page 28] Internet Draft M3UA Conformance Test Plan Jan 2003 "Reception of Unpadded Message" + TEST NUMBER : 1.12 + TITLE : ERROR + SUBTITLE : On Receiving Unpadded message from Peer, SGP should still process the Message. + PURPOSE: If the SGP receives a Message from the ASP which is not padded, then also the Message should be Processed. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in ASP-Down state. Arrange data in ASP such that ASPUP is sent to SGP with size of Info String such that the Total Message Length is 35 Bytes and this Message should not be padded. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Down ASPUP ----------------> (Length is 35 Bytes) <---------------- ASPUP-Ack <---------------- NTFY TEST DESCRIPTION: 1. Send the ASPUP message as described from ASP to SGP on Stream 0. 2. Check A: The Message should not be rejected at the SGP. 3. Check B: ASP UP Ack and NTFY should be sent from the SGP side. Anshoo Sharma, Aricent [Page 29] Internet Draft M3UA Conformance Test Plan Jan 2003 "Error - ASP ID Required" + TEST NUMBER : 1.13 + TITLE : ERROR + SUBTITLE : Error with cause ASP Identifier Required. + PURPOSE: On Receiving an ASPUP Message from an unconfigured Transport Address without an ASP ID the SGP sends ERROR with cause "ASP ID Required". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is in ASP-Down state. Arrange data in ASP such that ASPUP is sent to SGP with no ASP ID. The Transport Address of the ASP has not been configured at the SGP side. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Down ASPUP ----------------> (No ASP ID) <---------------- ERROR (ASP ID Required) TEST DESCRIPTION: 1. Send ASPUP message from ASP to SGP. 2. Check A: An Error Message with cause ASP ID Required is sent to the ASP from the SGP. Anshoo Sharma, Aricent [Page 30] Internet Draft M3UA Conformance Test Plan Jan 2003 "Error - Invalid ASP ID" + TEST NUMBER : 1.14 + TITLE : ERROR + SUBTITLE : Error with cause Invalid ASP Identifier. + PURPOSE: On receiving a Non-Unique ASP Identifier in the ASPUP message an ERROR with cause Invalid ASP Identifier is sent to the ASP. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SGP and both ASPs (i.e. ASP1 and ASP2). ASP1 is in ASP-Inactive state and the ASP Identifier for ASP1 is 'T'. ASP2 is in ASP-Down State. Arrange data at ASP2 for sending an ASPUP to SGP with ASP ID as 'T'. EXPECTED MESSAGE SEQUENCE : ASP2 SGP SM + NIF ASP1 is Inactive ASP2 is Down From ASP2 ASPUP ----------------> (ASP ID 'T') (ASP2) <---------------- ERROR (Invalid ASP ID) TEST DESCRIPTION: 1. Send ASPUP message from ASP to SGP with ASP ID 'T'. 2. Check A: An Error Message with cause Invalid ASP ID Required is sent to the ASP from the SGP and the ASPUP message is discarded. Anshoo Sharma, Aricent [Page 31] Internet Draft M3UA Conformance Test Plan Jan 2003 "Error - Missing Parameter" + TEST NUMBER : 1.15 + TITLE : ERROR + SUBTITLE : Error with cause Missing Parameter. + PURPOSE: To check that if any message without mandatory parameter is received at the SGP then SGP responds with ERROR message containing cause "Missing Parameter". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Active. Also arrange the data in ASP such that Payload Data Message is sent without Protocol Data parameter. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active From ASP DATA ----------------> (Without Payload) (ASP) <---------------- ERROR (Missing Parameter) TEST DESCRIPTION: 1. Send Payload Data message ASP to SGP without Protocol Data parameter. 2. Check A: ERROR message is received at the ASP containing Error Code Missing Parameter. 3. Repeat the above test cases for other messages from ASP to SGP like REG REQ, DEREG REQ, SCON and DAUD without mandatory parameter. In all these cases ERROR message will be received with the same Error Code. Anshoo Sharma, Aricent [Page 32] Internet Draft M3UA Conformance Test Plan Jan 2003 "Error - Unsupported Message Class" + TEST NUMBER : 1.16 + TITLE : ERROR + SUBTITLE : Error Type - Unsupported Message Class. + PURPOSE: To verify that A SGP that does not support registration must return an Error (Unsupported Message Class) (optionally with the message with the first 40 bytes of the offending message). This Error should be returned whenever an unsupported or invalid Message Type is received. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. Dynamic Routing Key Registration is not supported at the SGP. The ASP is in Inactive State at the SGP. Arrange Data in ASP such that a Routing Key Registration request for RK1 is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Inactive REG REQ -----------------> <----------------- Error (Unsupported Message Class) TEST DESCRIPTION: 1. Send a valid Reg Req message for RK1 from ASP to SGP Stack. 2. Check A: Verify that the SGP send a error message "Unsupported Message Class" with the first 40 bytes of the offending message to the ASP. Anshoo Sharma, Aricent [Page 33] Internet Draft M3UA Conformance Test Plan Jan 2003 "NTFY - ASP Failure" + TEST NUMBER : 1.17 + TITLE : NOTIFY + SUBTITLE : Sending of ASP Failure Notification + PURPOSE: To check that when any of the ASP's fail at SG. Notification ASP failure is send to all up/active ASP's with ASP ID (if available) of the failed ASP. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2. ASP1, ASP2 is in ASP-inactive state. EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 SGP SM + NIF ASP1 & ASP2 are Inactive ASPAC -----------------> (ASP1) Status Ind -----------> <-------------- ASP-Active-Ack <-------------- NTFY (AS-Active) *** Terminate the SCTP Association between ASP1 and SGP *** Status Ind -----------> <------- NTFY (AS-Pending) to ASP2 <------- NTFY (ASP-Failure) to ASP2 TEST DESCRIPTION: 1. Send ASPAC message from ASP1 for related AS. ASP1 becomes active at SGP. 2. Terminate the association between SGP and ASP1. 3. Check that AS PENDING notification is sent to ASP2. 4. Check that ASP FAILURE notification is sent to ASP2 with the ASP ID (if available) of ASP1. Anshoo Sharma, Aricent [Page 34] Internet Draft M3UA Conformance Test Plan Jan 2003 4.2 TRANSFER Test Cases to test TRANSFER Procedures. "Send and Receive Transfer Primitive in AS Active State" + TEST NUMBER : 2.1 + 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 SGP and ASP. ASP1 is active. Also arrange the data in SGP such that upper layers send MTP-Transfer indication primitive to M3UA with data to be sent to DPC X, N/w Appearance A and RC P. EXPECTED MESSAGE SEQUENCE : ASP SGP 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 SGP side to send Protocol Data to the ASP. 2. Check A: DATA message should be received at the ASP containing the data passed by the NIF, Network Appearance and the RC for which the DATA is being sent. 3. Send DATA message from ASP containing Protocol Data and Network Appearance A that is known to SGP. 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 and RC is not present in the DATA message sent from ASP to SGP. Anshoo Sharma, Aricent [Page 35] Internet Draft M3UA Conformance Test Plan Jan 2003 Note: Network Appearance and Routing Context are optional parameters. In some implementation these parameter will not be present in DATA message sent from SGP to ASP and vice versa. Anshoo Sharma, Aricent [Page 36] Internet Draft M3UA Conformance Test Plan Jan 2003 "Stream Selection" + TEST NUMBER : 2.2 + 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 SGP and ASP with two or more streams. ASP1 is active. Also arrange the data in SGP such that NIF send three or more Transfer indication primitive to M3UA with N/w Appearance A and Routing Context P, containing the Data with same CIC value to be sent to DPC X. EXPECTED MESSAGE SEQUENCE : ASP SGP 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 SGP 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 Anshoo Sharma, Aricent [Page 37] Internet Draft M3UA Conformance Test Plan Jan 2003 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. Anshoo Sharma, Aricent [Page 38] Internet Draft M3UA Conformance Test Plan Jan 2003 "DATA message from ASP in ASP-Down state" + TEST NUMBER : 2.3 + TITLE : Invalid Message Handling + SUBTITLE : DATA message from ASP 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 SGP and ASP and ASP1 is in Down State. Arrange the data in AS such that DATA message with N/w Appearance A, RC P is sent to the SGP. EXPECTED MESSAGE SEQUENCE : ASP SGP 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 SGP 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 the ASP at SGP is not disturbed. 4. Send ASPUP message on stream 0 and SGP should respond with ASP-Up-Ack and NTFY (AS-Inactive). Anshoo Sharma, Aricent [Page 39] Internet Draft M3UA Conformance Test Plan Jan 2003 "Message Routing based on DPC" + TEST NUMBER : 2.4 + 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 SGP and all ASP i.e. ASP1, ASP2 and ASP3 and all ASP are in Active state. Also arrange the data in NIF at SGP 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 T EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 ASP3 SGP NIF All AS are active <---------- MTP-Transfer Req N/w Appearance A DPC X <---------------------------- DATA <---------- MTP-Transfer Req N/w Appearance A DPC Y <---------------- DATA <---------- MTP-Transfer Req N/w Appearance B DPC T <-------- DATA Anshoo Sharma, Aricent [Page 40] Internet Draft M3UA Conformance Test Plan Jan 2003 TEST DESCRIPTION: 1. Send MTP-Transfer Request Primitive from NIF in SGP containing the Protocol Data with DPC X and N/w appearance A. 2. Check A: DATA message will be received at the ASP1. 3. Repeat the above test case for MTP-Transfer Req primitive containing Protocol Data with DPC Y and N/w appearance A. 4. Repeat the above test case for MTP-Transfer Req primitive containing Protocol Data with DPC T and N/w appearance B. Anshoo Sharma, Aricent [Page 41] Internet Draft M3UA Conformance Test Plan Jan 2003 "Message Routing based on DPC+CIC" + TEST NUMBER : 2.5 + 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 SGP and all ASP i.e. ASP1 and ASP2 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 SGP such that MTP-Transfer Request Primitives is sent to the SGP with the following parameter combination: Protocol Data with DPC X and CIC 3 Protocol Data with DPC X and CIC 35 EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 SGP 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 SGP containing the Protocol Data with DPC X and CIC value 3. 2. Check A: DATA message will be received at the ASP1. 3. Repeat the above test case for MTP-Transfer Req primitive containing Protocol Data with DPC X and CIC value 35. DATA message should be received at ASP2 Anshoo Sharma, Aricent [Page 42] Internet Draft M3UA Conformance Test Plan Jan 2003 "Message Routing based on DPC+SSN" + TEST NUMBER : 2.6 + 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 SGP and all ASP i.e. ASP1 and ASP2 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 SGP such that MTP-Transfer Request Primitives is sent to the SGP with the following parameter combination: Protocol Data with DPC X and SSN S Protocol Data with DPC X and SSN T EXPECTED MESSAGE SEQUENCE : ASP1 ASP2 SGP NIF All AS are active <---------- MTP-Transfer Req DPC X SSN S <---------------------------- DATA <---------- MTP-Transfer Req DPC X SSN T <---------------- DATA TEST DESCRIPTION: 1. Send MTP-Transfer Request Primitive from NIF in the SGP 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 Req primitive containing Protocol Data with DPC X and SSN value T. DATA message should be received at AS2 Anshoo Sharma, Aricent [Page 43] Internet Draft M3UA Conformance Test Plan Jan 2003 "Message Routing based on DPC+SIO" + TEST NUMBER : 2.7 + 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 SGP and all ASP i.e. ASP1 and ASP2 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 SGP such that MTP-Transfer Request 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 : ASP1 ASP2 SGP NIF All AS are active <---------- MTP-Transfer Req DPC X SIO S <---------------------------- DATA <---------- MTP-Transfer Req DPC X SIO T <---------------- DATA TEST DESCRIPTION: 1. Send MTP-Transfer Request Primitive from NIF in the SGP 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 Req primitive containing Protocol Data with DPC X and SIO value T. DATA message should be received at ASP2 Anshoo Sharma, Aricent [Page 44] Internet Draft M3UA Conformance Test Plan Jan 2003 "Routing for Data not matching any routing context" + TEST NUMBER : 2.8 + 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 SGP 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 SGP such that MTP-Transfer Request Primitives is sent to the SGP with DPC X and SSN other than S or T. EXPECTED MESSAGE SEQUENCE : ASP SGP NIF + SM AS is Active <----------- MTP-Transfer Req DPC X & SSN <> S or T Failure Ind. ----------> TEST DESCRIPTION: 1. Send MTP-Transfer Request Primitive from NIF in the SGP containing the Protocol Data having DPC and SSN such that they don't match any routing key. 2. Check A: Failure 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 Req from NIF containing protocol data with DPC+CIC that doesn't match any 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 Req 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 Req from NIF containing protocol data with Anshoo Sharma, Aricent [Page 45] Internet Draft M3UA Conformance Test Plan Jan 2003 DPC that doesn't match this routing key. Response will be same as in the above case. Note: Implementation may provide a default AS for all Data. In this case Failure would not be returned. Anshoo Sharma, Aricent [Page 46] Internet Draft M3UA Conformance Test Plan Jan 2003 4.3 SSNM Test Cases to test SSNM Procedures. "Received DAUD Message " + TEST NUMBER : 3.1 + TITLE : Status Audit + SUBTITLE : Received DAUD message + PURPOSE: To check that if DAUD message is received from ASP then SGP sends Status Request primitive to the NIF and state of ASP is not changed at SGP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP1 is active. Also arrange the data in ASP such that DAUD message is sent to the SGP with Network Appearance A and Affected DPC any value. EXPECTED MESSAGE SEQUENCE : ASP SGP NIF + SM AS is active DAUD -------------> Status Request ------> <------ Pause/Resume/State <------------ DUNA/DAVA/DRST/SCON TEST DESCRIPTION: 1. Send DAUD message with N/w appearance A and affected DPC any value from ASP to the SGP. 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 SGP. Send Pause/Resume primitive with N/w appearance A and SGP should send DUNA/DRST/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. Anshoo Sharma, Aricent [Page 47] Internet Draft M3UA Conformance Test Plan Jan 2003 Note1: ASP auditing is an optional procedure and may not be supported at ASP/SGP. Anshoo Sharma, Aricent [Page 48] Internet Draft M3UA Conformance Test Plan Jan 2003 "MTP-Pause Indication Primitive:" + TEST NUMBER : 3.2 + TITLE : MTP3 management + SUBTITLE : MTP-Pause Indication Primitive + PURPOSE: To check that if MTP-Pause indication primitive is received from NIF at SGP then SGP sends DUNA message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. 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 SGP 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 : AS1 AS2 AS3 SGP NIF All AS are active <---------- MTP-Pause N/w Appearance A Affected DPC M <---------------------------- DUNA <----------------- DUNA <---------- MTP-Pause N/w Appearance B Affected DPC M <--------- DUNA TEST DESCRIPTION: 1. Send MTP-Pause indication Primitive message from NIF in the SGP containing the Network Appearance A and Affected DPC M. 2. Check A: DUNA message will be received at the ASP1 and ASP2 containing the network Appearance A and Affected DPC M. 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. Anshoo Sharma, Aricent [Page 49] Internet Draft M3UA Conformance Test Plan Jan 2003 "MTP-Resume Indication Primitive" + TEST NUMBER : 3.3 + TITLE : MTP3 management + SUBTITLE : MTP-Resume Indication Primitive + PURPOSE: To check that if MTP-Resume indication primitive is received from NIF at SGP then SGP sends DAVA message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. 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 SGP 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 SGP NIF All AS are active <---------- MTP-Resume N/w Appearance A Affected DPC M <---------------------------- DAVA <----------------- DAVA <---------- MTP-Resume N/w Appearance B Affected DPC M <--------- DAVA TEST DESCRIPTION: 1. Send MTP-Resume indication Primitive from NIF in the SGP containing the Network Appearance A and Affected DPC M. 2. Check A: DAVA message is received at AS1 and AS2 containing the network Appearance A and Affected DPC M. 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. Anshoo Sharma, Aricent [Page 50] Internet Draft M3UA Conformance Test Plan Jan 2003 "MTP-Status Indication Primitive with Route Congested" + TEST NUMBER : 3.4 + 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 SGP then SGP sends SCON message to the concerned ASPs. Also arrange the data in NIF at SGP such that MTP-Status indication Primitive is sent to the SGP with cause Routing Congested, affected DPC, Congestion level and Network Appearance. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. 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. EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SGP NIF All AS are active <---------- MTP-Status N/w Appearance A DPC M Cong Level 2 <---------------------------- SCON <----------------- SCON <---------- MTP-Status N/w Appearance B DPC M Cong Level 2 <--------- SCON TEST DESCRIPTION: Anshoo Sharma, Aricent [Page 51] Internet Draft M3UA Conformance Test Plan Jan 2003 1. Send MTP-Status indication Primitive from NIF in the SGP containing the Network Appearance A, cause Route congestion, Affected DPC M and congestion Level 2. 2. Check A: SCON message is received at the AS1 and AS2 containing the network Appearance A, Affected DPC M, 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. Anshoo Sharma, Aricent [Page 52] Internet Draft M3UA Conformance Test Plan Jan 2003 "MTP-Status Indication Primitive with User Part Unavailable" + TEST NUMBER : 3.5 + 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 SGP then SGP sends DUPU message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. 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 SGP such that MTP-Status indication Primitive is sent to the SGP 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 SGP NIF All AS are active <---------- MTP-Status N/w Appearance A DPC S <---------------------------- DUPU <----------------- DUPU <---------- MTP-Status N/w Appearance B DPC S <--------- DUPU Anshoo Sharma, Aricent [Page 53] Internet Draft M3UA Conformance Test Plan Jan 2003 TEST DESCRIPTION: 1. Send MTP-Status indication Primitive from NIF in the SGP containing the Network Appearance A, cause User Part Unavailable, Affected DPC S and SIO for ISUP. 2. Check A: SGP 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. Anshoo Sharma, Aricent [Page 54] Internet Draft M3UA Conformance Test Plan Jan 2003 "MTP-Pause Indication Primitive" + TEST NUMBER : 3.6 + TITLE : MTP3 management + SUBTITLE : MTP-Status Indication Primitive with Route Restricted + PURPOSE: To check that if MTP-Status indication primitive with Route Restricted is received from NIF at SGP then SGP sends DRST message to the concerned ASPs. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP1, ASP2 and ASP3. 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 SGP such that MTP-Status Indication Primitive is sent to the AS with Network Appearance A and B and affected DPC any value. EXPECTED MESSAGE SEQUENCE : AS1 AS2 AS3 SGP NIF All AS are active <---------- MTP-Status N/w Appearance A Cause Restricted <---------------------------- DRST <----------------- DRST <---------- MTP-Status N/w Appearance B Cause Restricted <--------- DRST TEST DESCRIPTION: 1. Send MTP-Pause indication Primitive message from NIF in the SGP containing the Network Appearance A and Affected DPC M. 2. Check A: DRST message will be received at the ASP1 and ASP2 containing the network Appearance A and Affected DPC M. 3. Check B: DRST message is received at both AS AS1 and AS2 which are handling traffic for the same network appearance. 4. Check C: DRST message is received on the Stream number 0. 5. Repeat the above test case with N/w Appearance B. In this case DRST message should be sent to AS3. Anshoo Sharma, Aricent [Page 55] Internet Draft M3UA Conformance Test Plan Jan 2003 4.4 ASPSM Test Cases to test ASPSM Procedures. "Heartbeat and Heartbeat Ack" + TEST NUMBER : 4.1 + 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 SGP and ASP. ASP is active. Also arrange the data in ASP such that BEAT message is sent from ASP1 to SGP. EXPECTED MESSAGE SEQUENCE: ASP SGP SM ASP is Active 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 without any BEAT ACK is from SGP. TEST DESCRIPTION: 1. Send BEAT Message from ASP to the SGP. 2. The beat message should be acknowledge by BEAT ACK before the Timer expires. 3. Send the Beat message again. Anshoo Sharma, Aricent [Page 56] Internet Draft M3UA Conformance Test Plan Jan 2003 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 SGP M3UA peer. 5. Repeat the Test when the BEAT message is sent by SGP. Anshoo Sharma, Aricent [Page 57] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPUP message in AS-Inactive state" + TEST NUMBER : 4.2 + TITLE : Duplicate Message Handling + SUBTITLE : ASPUP message in ASP 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 SGP and ASP and ASP is in ASP-Down state. Arrange the data in ASP such that ASPUP message is sent to the SGP two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Down ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) ASPUP ----------------> <--------------- ASP-Up-Ack ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack <--------------- NTFY(AS-Active) TEST DESCRIPTION: 1. Send ASPUP message to the SGP in ASP-Down state. ASP-Up-Ack and NTFY (AS-Inactive) messages will come from the SGP. 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 SGP 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. Anshoo Sharma, Aricent [Page 58] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPDN message in ASP-Down state" + TEST NUMBER : 4.3 + 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 SGP and ASP 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 SGP two times on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS is Inactive ASPDN ----------------> Status Ind -------> <--------------- ASP-Down-Ack ASPDN ----------------> <--------------- ASP-Down-Ack ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send ASPDN message to the SGP in ASP-Inactive state. ASP-Down-Ack message will be received from the SGP. Send ASPDN message again from the ASP. 2. Check A: ASP-Down-Ack message should be received at AS. 3. Check B: State of ASP at SGP is not disturbed i.e. ASP remains in the Down state. Send ASPUP message for the ASP,ASP-Up-Ack and NTFY with status AS-Inactive should come. Anshoo Sharma, Aricent [Page 59] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPUP message in ASP-Active state" + TEST NUMBER : 4.4 + 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-Inactive. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP1 is Active. Arrange the data in AS such that ASPUP message is sent to the SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active ASPUP ----------------> <--------------- ASP-Up-Ack Status Ind -------> AS Inactive <--------------- Error (Unexpected Message) ASPAC ----------------> Status Ind -------> <--------------- ASP-Active-Ack TEST DESCRIPTION: 1. Send ASPUP message to the SGP 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 to ASP Inactive. Send ASPAC message with correct Type (Type is same as defined at SGP for the AS) and routing context P to the SGP and SGP should send ASP-Active-Ack. Anshoo Sharma, Aricent [Page 60] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPDN message in ASP-Active state" + TEST NUMBER : 4.5 + 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 SGP becomes ASP-Down. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is Active. Arrange the data in ASP such that ASPDN Message is sent to the SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF ASP is Active ASPDN ----------------> Status Ind -------> <--------------- ASP-Down-Ack | | [T(r) Expiry] --- Status Ind -------> AS Down ASPUP ----------------> Status Ind -------> <--------------- ASP-Up-Ack <--------------- NTFY(AS-Inactive) TEST DESCRIPTION: 1. Send ASPDN message to the SGP in ASP-Active state. 2. Check A: ASP-Down-Ack message is received at ASP. 3. Check B: State of ASP should become Down. 4. Send ASPUP message to the SGP and SGP should send ASP-Up-Ack and NTFY message with Status ASP-Inactive. Anshoo Sharma, Aricent [Page 61] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPM message when SGP has locked out the ASP for management reason" + TEST NUMBER : 4.6 + TITLE : AS management + SUBTITLE : ASPM message when SGP has locked out the ASP for management reason + PURPOSE: To check that if ASPM message is received when SGP has locked out the ASP for management then ERROR message with reason Management Blocking is sent to ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP may be in any state. Arrange the data in SGP such that ASP is locked out at the SGP. Arrange the data in AS such that ASPUP message with valid parameters is sent to the SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF <---------- Lock-ASP ASPUP ----------------> <--------------- ERROR (Refused - Management Blocking) TEST DESCRIPTION: 1. Lock out the ASP at the SGP by sending primitive for locking ASP from SM. 2. Now send ASPUP message with valid parameters from ASP to SGP. 2. Check A: Error message with reason " Management Blocking" is received at ASP. 3. Repeat the above test case for ASPAC message from ASP to the SGP with valid parameters. Response should be same. Anshoo Sharma, Aricent [Page 62] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASP ID in ASP UP Message" + TEST NUMBER : 4.7 + TITLE : ASP management + SUBTITLE : ASPUP Message from a ASP with unconfigured Transport Address. + PURPOSE: To test that on when an ASP sends an ASPUP message with ASP ID from a new Transport Address then the SGP updates the Transport Address for this ASP with the new Transport Address. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP and ASP is in ASP-Down state. The Transport Address statically configured for the ASP is T1 and the SCTP association is with Transport Address T2. The ASP is statically configured to have ASP ID 'I'. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF (From Transport Addr T2) ASPUP ----------------> (ASP ID 'I') <--------------- ASPUP-Ack <--------------- NTFY Status Ind ------> TEST DESCRIPTION: 1. Send ASPUP from ASP (at Transport Address T2) to SGP with ASP ID 'I'. 2. Check A: SGP updates the Transport Address for ASP (with ASP ID 'I') to T2 which was in ASP-Down state up till now. 3. Check B: ASPUP was successfully processed at the ASP and the state of ASP has changed to ASP-Inactive. ASPUP-Ack and NTFY messages have been sent to ASP. Anshoo Sharma, Aricent [Page 63] Internet Draft M3UA Conformance Test Plan Jan 2003 4.5 ASPTM Test Cases to test ASPTM Procedures. "Transfer Request Primitive from NIF in AS Inactive State" + TEST NUMBER : 5.1 + TITLE : AS management + SUBTITLE : Transfer Request from NIF in AS Inactive State + PURPOSE: To check that if AS is Inactive at SGP 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 SGP and ASP. ASP is active. Also arrange the data in ASP such that ASPIA message is sent from ASP1 to SGP . The Type field in ASPIA can be any valid value which is equal to the traffic handling mode for the AS at the SGP and Routing Context should be P. EXPECTED MESSAGE SEQUENCE : ASP SGP NIF + SM ASP is Active ASPIA ---------------> (ASP1) Status Ind --------> <-------------- ASP-Inactive-Ack <-------------- NTFY(AS-Pending) | | ___ [T(r) Expires] Status Ind --------> AS Inactive <-------- MTP-Transfer Send failure --------> Pause Ind --------> Anshoo Sharma, Aricent [Page 64] Internet Draft M3UA Conformance Test Plan Jan 2003 TEST DESCRIPTION: 1. Send ASPIA Message for ASP1 from ASP to the SGP. ASP will move to Inactive state at the SGP. 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. Some implementations may also indicate a Pause Ind at the SGP for the SPMC. 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 SGP or with no routing context for the ASP. 4. Repeat the above test if instead of sending ASPIA message, SCTP association between ASP and SGP 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. Anshoo Sharma, Aricent [Page 65] Internet Draft M3UA Conformance Test Plan Jan 2003 "MTP-Transfer Request Primitive from NIF in AS Down State" + TEST NUMBER : 5.2 + TITLE : AS management + SUBTITLE : MTP-Transfer Request from NIF in AS Down State + PURPOSE: To check that if AS is down at SGP 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 SGP and ASP. ASP is active. Also arrange the data in ASP such that ASPIA and ASPDN message is sent from ASP to SGP on stream 0. EXPECTED MESSAGE SEQUENCE : ASP SGP NIF + SM ASP is Active ASPIA ---------------> (ASP1) Status Ind ---------> <-------------- ASP-Inactive-Ack <-------------- NTFY(AS-Pending) T(r) Started ASPDN ---------------> (ASP1) Status Ind ---------> <-------------- ASP-Down-Ack | | --- T(r) Expiry Status Ind (AS Down)---------> <-------- MTP-Transfer Send failure --------> Pause Ind --------> Anshoo Sharma, Aricent [Page 66] Internet Draft M3UA Conformance Test Plan Jan 2003 TEST DESCRIPTION: 1. Send ASPIA Message for ASP1 from ASP to the SGP. ASP will move to Inactive state at the SGP. 2. Send ASPDN message from ASP to the SGP. ASP will move to down state at the SGP. 3. After Pending Timer T(r) Expires. 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. Some implementations may also indicate a Pause Ind at the SGP for the SPMC. 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. Anshoo Sharma, Aricent [Page 67] Internet Draft M3UA Conformance Test Plan Jan 2003 "Timer T(r) Cancellation" + TEST NUMBER : 5.3 + TITLE : AS management + SUBTITLE : Timer T(r) Cancellation + PURPOSE: To check that after last ASP becomes inactive then SGP 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 SGP and ASP. ASP is active. Arrange the data in ASP such that ASPIA and ASPAC messages are sent from ASP1 to SGP. The Traffic Mode field in ASPIA 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 SGP 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 Anshoo Sharma, Aricent [Page 68] Internet Draft M3UA Conformance Test Plan Jan 2003 TEST DESCRIPTION: 1. Send ASPIA Message from ASP1 to SGP. ASP will become Inactive at the SGP. 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 SGP 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. Anshoo Sharma, Aricent [Page 69] Internet Draft M3UA Conformance Test Plan Jan 2003 "Timer T(r) Expiry" + TEST NUMBER : 5.4 + TITLE : AS management + SUBTITLE : Timer T(r) Expiry + PURPOSE: To check that if timer T(r) expires without receiving an ASPAC Message then the AS moves into Inactive State. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is active. Arrange data in ASP such that ASPIA and ASPAC messages are sent from ASP to SGP. The Type field in ASPIA 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 SGP 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 ---------> (AS Inactive) Anshoo Sharma, Aricent [Page 70] Internet Draft M3UA Conformance Test Plan Jan 2003 <-------- MTP-Transfer Send Failure -------> TEST DESCRIPTION: 1. Send MTP-Transfer Primitive with N/w appearance A containing protocol Data to send to DPC X. Message will be sent to ASP. 2. Send ASPIA message from ASP1 to the SGP. ASP will become Inactive at SGP. AS will be in AS-Pending state at the SGP. 3. Check A: Timer T(r) is started. 4. Send MTP Transfer Primitive with Network Appearance A containing protocol data to send DPC X. Message will be buffered at SGP. 5. Timer T(r) is expired, and the message buffered is discarded, also after the expiry of T(r) AS will move to the AS-INACTIVE state. 6. Send MTP-Transfer Primitive from NIF with N/w appearance A containing protocol Data to send to DPC X. SGP will send Send Failure. 7. Repeat the above test case if ASPDN message 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. Anshoo Sharma, Aricent [Page 71] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPAC message with more than one Routing Context" + TEST NUMBER : 5.5 + 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 for which the RC was present in the Message and are served by this ASP. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP 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-Inactive state at SGP. Also arrange the data in ASP1 such that ASPAC message is sent from ASP1 to SGP 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 SGP and it should be same for both AS. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS1 & AS2 is Inactive ASPAC ------------------> Routing Context P and Q Status Ind ---------> <----------------- ASP-Active-Ack <----------------- NTFY (AS1 and AS2 Active) <-------- MTP-Transfer for Routing Context P <----------------- DATA <-------- MTP-Transfer for Routing Context Q <----------------- DATA Anshoo Sharma, Aricent [Page 72] Internet Draft M3UA Conformance Test Plan Jan 2003 TEST DESCRIPTION: 1. Send ASPAC Message with routing contexts P and Q to the SGP. 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. Anshoo Sharma, Aricent [Page 73] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPAC message without any Routing Context" + TEST NUMBER : 5.6 + 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 in all the AS which this ASP serves. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SGP and ASP. ASP is Inactive in both the AS at the SGP. Arrange data in ASP such that ASPAC messages is sent to the SGP from ASP. Don't fill any routing context parameter in ASPAC. EXPECTED MESSAGE SEQUENCE : ASP SGP 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 SGP. 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 using configuration Data present at the SGP. Note: If there is no Configuration Data present at the SGP and the ASP has not dynamically registered for any Routing Context, then the ASP Active Message is silently discarded at the SGP. No Ack or NTFY as shown above is sent in that case. Anshoo Sharma, Aricent [Page 74] Internet Draft M3UA Conformance Test Plan Jan 2003 "ASPIA message with more than one Routing Context" + TEST NUMBER : 5.7 + 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 SGP and ASP. 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 SGP. Also arrange the data in ASP1 such that ASPIA message is sent from ASP1 to SGP containing Routing Context P and Q. Fill any valid value in the Type parameter which is same as configured for AS1 and AS2 in SGP and it should be same for both AS. EXPECTED MESSAGE SEQUENCE : ASP SGP SM + NIF AS1 & AS2 is Active ASPIA ------------------> Routing Context P and Q Status Ind --------> <----------------- ASP-Inactive-Ack <----------------- NTFY(AS-Pending) | | ___ [T(r) Expires] Status Ind -------->(AS1,AS2 Inactive) <-------- MTP-Transfer Routing Context P Send Failure --------> Anshoo Sharma, Aricent [Page 75] Internet Draft M3UA Conformance Test Plan Jan 2003 <-------- MTP-Transfer Routing Context Q Send Failure --------> TEST DESCRIPTION: 1. Send ASPIA Message containing routing contexts P and Q from ASP1 to the SGP. 2. Check A: ASP-Inactive-Ack and NTFY (AS-Pending) message should