INTERNET-DRAFT Sachin Jindal Sunil Mahajan Hughes Software Systems July 20,2000 expires: Jan 20, 2001 Test Specification for MTP2 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. Sachin-Sunil, HSS [Page 1] Internet Draft Test Specs for M2UA July 2000 Abstract This document presents the test specification for M2UA (MTP2 User Adaptation) prototcol (ver 03), which can be used to test M2UA 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 M2UA specification by implementor of protocol as implementors 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 M2UA-04 and any subsequent RFC published by IETF. Sachin-Sunil, HSS [Page 2] Internet Draft Test Specs for M2UA July 2000 Table of Contents 1 Introduction------------------------------------------------3 1.1 Terms Used--------------------------------------------------4 2 General Principles of m3ua Tests----------------------------4 2.1 Presentation of Test Descriptions---------------------------5 2.1.1 Pre-Test Condition------------------------------------------5 3 Test Configurations-----------------------------------------5 3.1 Configuration for Testing the m3ua at SG--------------------5 3.2 Configuration for Testing The m3ua at AS--------------------7 4 Test Cases--------------------------------------------------9 4.1 Test cases for testing m3ua at SG---------------------------9 4.1.1 Send and Receive transfer primitive in AS Active state------9 4.1.2 Stream selection--------------------------------------------10 4.1.3 AS Management-----------------------------------------------11 4.1.4 Link Management---------------------------------------------32 4.1.5 Invalid Message Handling------------------------------------42 4.1.6 Duplicate Message Handling----------------------------------58 4.1.7 DATA message from AS in ASP-Down State----------------------65 4.1.8 ASPM messages when SG has locked out the ASP----------------66 4.1.9 Message Routing---------------------------------------------67 4.1.10 Mode of Traffic Handling by ASP in ASPAC message------------69 4.1.11 Mode of Traffic Handling by ASP in ASPIA message------------72 4.1.12 ERROR Message Handling--------------------------------------73 4.1.13 SCTP Connection Management----------------------------------74 4.2 Test Cases for Testing m3ua at AS---------------------------76 4.2.1 Send and receive of transfer primitive in AS Active state---76 4.2.2 Stream Selection--------------------------------------------77 4.2.3 SCTP Connection Management----------------------------------78 4.2.4 AS Management-----------------------------------------------80 4.2.5 Invalid Message Handling------------------------------------85 4.2.6 Link Management---------------------------------------------94 4.2.7 Duplicate Message Handling----------------------------------100 4.2.8 DATA message from SG in ASP-Down State----------------------102 4.2.9 ERROR Handling----------------------------------------------103 4.2.10 ASP in more than one AS-------------------------------------104 4.2.11 ASP Handling more than one SG-------------------------------105 5 Acknowledgement---------------------------------------------107 6 Authors address---------------------------------------------107 7 References--------------------------------------------------107 1 Introduction The M2UA is a protocol for the transport of any SS7 MTP2-User message (i.e. MTP 3 message) over IP using the Stream Control Transport Protocol (SCTP) or any other suitable transport protocol. This protocol would be used between a Signalling Gateway (SG) and an Application Service Provider (ASP) (e.g. Media Gateway Controller - MGC). Sachin-Sunil, HSS [Page 3] Internet Draft Test Specs for M2UA July 2000 1.1 Terms Used MTP2-User - A protocol that normally uses the services of MTP Level 2 (i.e. MTP3). Interface - For the purposes of this document, an interface is a SS7 signaling link. Association - An association refers to a SCTP association. The association will provide the transport for the delivery of protocol data units for one or more interfaces. Backhaul - Refers to the transport of signaling from the point of interface for the associated data stream (i.e., SG function in the MGU) back to the point of call processing (i.e., the MGCU), if this is not local. Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the MTP Level 3 and call processing for SS7 links terminated by the Signaling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary, ...). Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are primary or backup MGC instances. Application Server Process Path (ASP Path or just Path) - A Path to a remote Application Server Process instance. A Path maps 1:1 to an SCTP association. Fail-over - The capability to re-route signaling traffic as required to an alternate Application Server Process, or group of ASPs, within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Fail-back may apply upon the return to service of a previously unavailable Application Server Process. Layer Management: Layer Management is a nodal function in an SG or ASP that handles the inputs and outputs between the M2UA layer and a local management entity. Stream - A stream refers to an SCTP stream. 2 General Principles of M2UA 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 Sachin-Sunil, HSS [Page 4] Internet Draft Test Specs for M2UA July 2000 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. Therefore, for testing individual Administrations may unilaterally choose the tests to be performed 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. Seven test configurations are defined (named A, B, C, D, E, F and G); they are presented in clause 3. Each test is precisely described. Nevertheless, some events not directly concerning the point under test, or without direct link with the test nature, are not explicitly described. In order to preserve the test description implementation independence, certain flexibility has been left in the test descriptions. This is particularly the case when it is necessary to terminate the SCTP association (where it is only mentioned "Terminate" with no more precision). The operator will choose according to the implementation particularities and the events expected in the test description, the appropriate Termination means (MML- Man machine Language, provoked failure, etc.). 2.1.1 Pre-Test Condition Before starting the test we need to get the setup into a condition from where test can be started. These conditions are specified in Pre-Test condition. Note: Where NIF has been written it means NIF + SM. In some implementation these may be two entities and in some they may be implemented in a 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 M2UA protocol. These configurations and hence test cases have been divided on the basis of M2UA at SG and M2UA at AS. 3.2 Configuration for testing the M2UA at SG 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 interface identifier X and Y. AS is having only one ASP ASP1. Sachin-Sunil, HSS [Page 5] Internet Draft Test Specs for M2UA July 2000 ------------- -------------- | SG | | AS | | under Test | | ------- | | |-------------------------------|--| 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 are handling traffic for different interface identifiers. Configuration B is shown in figure 2. AS1 is handling the traffic for interface identifier X and Y. AS2 is handling the traffic for interface identifier P and Q. ASP1 is in both AS. ASP1 maintains single association with SG for both AS1 and AS2. -------------- | AS1 | ------------- | ------- | | |-------------------------------| | ASP1 | | | SG | | ------- | | Under Test | -------------- | | -------------- | |-------------------------------| AS2 | ------------- | ------- | | | 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 interface identifier X and Y. ASP1 and ASP2 may be in FAIL-OVER mode or LOADSHARE mode of traffic handling. -------------- | AS | ------------- | ------- | | |-------------------------------|-| ASP1 | | | SG | | ------- | | Under Test | | ------- | | | | | ASP2 | | | |-------------------------------|- ------- | ------------- -------------- Fig 3: Configuration C Sachin-Sunil, HSS [Page 6] Internet Draft Test Specs for M2UA July 2000 3.2.4 Configuration D: This configuration is used for all the procedures of tests concerning two AS which are handling traffic for different interface identifiers. Configuration D is shown in figure 4. AS1 is handling the traffic for interface identifier X and Y. AS2 is handling the traffic for interface identifier P and Q. ASP1 is in AS1 and ASP2 is in AS2. -------------- | AS1 | ------------- | ------- | | |-------------------------------| | ASP1 | | | SG | | ------- | | Under Test | -------------- | | -------------- | |-------------------------------| AS2 | ------------- | ------- | | | ASP2 | | | ------- | -------------- Fig 4: Configuration D 3.3 Configuration for testing the M2UA at ASP 3.3.1 Configuration E: This simple configuration is used for all the procedures of tests concerning only one SG. Configuration E is shown in figure 6. ASP1 is handling the traffic for interface identifier X and Y. ------------- -------------- | ASP1 | | SG | | under Test | | | | |-------------------------------| | | | | | ------------- -------------- Fig 5: Configuration E 3.3.2 Configuration F: This simple configuration is used for all the procedures of tests concerning one ASP in two AS. Configuration F is shown in figure 6. ASP1 is in two AS, AS1 and AS2. AS1 is handling traffic for interface identifier X and Y and AS2 is handling traffic for interface identifier P and Q. ------------- -------------- | ASP1 | | SG | | under Test | | Configured | | |-------------------------------| for AS1 and | | | | AS2 | ------------- -------------- Fig 6: Configuration F Sachin-Sunil, HSS [Page 7] Internet Draft Test Specs for M2UA July 2000 3.3.3 Configuration G: This simple configuration is used for all the procedures of tests concerning one ASP connected to two SG. Configuration G is shown in figure 7. ASP1 is connected to SG1 and SG2. Interface identifiers in SG1 are X and Y. Interface identifiers in SG2 are also X and Y. ASP is handling interface identifier X and Y of both SG1 and SG2. -------------- | SG1 | ------------- | | | |-------------------------------| | | ASP1 | | | | Under Test | -------------- | | -------------- | |-------------------------------| SG2 | ------------- | | | | | | -------------- Fig 7: Configuration G Sachin-Sunil, HSS [Page 8] Internet Draft Test Specs for M2UA July 2000 4 Test Cases 4.1 Test Cases for Testing M2UA at SG These test cases are used to test the M2UA at SG. "Send and Receive of DATA Primitive in AS active state" + TEST NUMBER : 1.1 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.1.1 + TITLE: DATA Primitive + SUBTITLE : Send and Receive of DATA Primitive + PURPOSE: To check that on receiving DATA primitive from ULP, DATA message is sent to the AS. Also if DFATA message is received the Data primitive is sent to the NIF + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Also arrange the data in SG such that NIF send Data primitive to M2UA with interface identifier X. EXPECTED MESSAGE SEQUENCE : ASP SG NIF a) AS is Active <----------- Send Data <------------- DATA Interface Id X b) DATA --------------> Interface Id X Receive Data ---------> TEST DESCRIPTION: 1. Send DATA Primitive from the NIF at SG side to send Protocol Data to the ASP. 2. Check A: DATA message is received at the ASP containing the data and the interface identifier X passed by the NIF. 3. Send DATA message containing Protocol Data and Interface Identifier X. 4. Check B: DATA primitive is received at the NIF with the Protocol Data and interface identifier. Sachin-Sunil, HSS [Page 9] Internet Draft Test Specs for M2UA July 2000 "Stream Selection" + TEST NUMBER : 1.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 1.5.3 + TITLE : Stream Selection + SUBTITLE : Stream Selection + PURPOSE: To check that all the messages for the same link identifier are sent on the same SCTP stream. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP with two streams and ASP is active. Also arrange the data in SG such that NIF send three or more DATA primitive to M2UA containing the same interface identifier value X. EXPECTED MESSAGE SEQUENCE : ASP SG NIF ASP is active <--------- Data Check Stream id <------------- DATA Interface Id X <--------- Data Check Stream id <------------- DATA Interface Id X <--------- Data Check Stream id <------------- DATA Interface Id X <--------- Data Check Stream id <------------- DATA Interface Id Y TEST DESCRIPTION: 1. Send three or more DATA Primitives with same interface identifier value X from the NIF at SG side to send Protocol Data to the ASP. 2. Check A: DATA messages are received at the ASP containing the same Stream Sequence number. 3. Send Data primitive with interface identifier Y. 4. Check B: The DATA message should be received on other stream. 5. Repeat the above case if number of streams between AS and SG is more than two but AS is handling only two interface identifiers. One or more stream may not be used for sending DATA message. 6. Repeat the above case if number of streams between AS and SG is two but AS is handling four interface identifiers. Send DATA messages for all interface identifiers. DATA messages should be sent on both the streams and DATA messages for the same interface identifier are sent on the same stream. Sachin-Sunil, HSS [Page 10] Internet Draft Test Specs for M2UA July 2000 "Data Send Primitive from NIF in AS Up State" + TEST NUMBER : 1.3.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.2 + TITLE : AS management + SUBTITLE : DATA send Primitive from NIF in AS Up State + PURPOSE: To check that if AS is not active at SG and NIF sends Data send Primitive to send DATA to that ASP then it receives a send failure. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is in active state. Arrange the data in ASP such that ASPIA message with interface identifier X and Type field equal to the traffic handling mode defined at the SG for this AS is sent from ASP to SG on stream 0. Arrange data in NIF at SG such that DATA primitive with interface identifier X and protocol Data is sent to SG. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM ASPIA ---------------> (ASP1) M-ASP-Status --------> <-------------- NTFY( ASP-Up) <-------------- NTFY(AS-Up/AS-Pending) <-------- Data interface Id X Send failure --------> TEST DESCRIPTION: 1. Send ASPIA Message from ASP to the SG. ASP and AS will become Up at the SG. Send Data send Primitive containing Protocol Data to send to the AS. 2. Check A: Send failure should be received at the NIF and DATA message should not be sent to AS. 3. Check B: NTFY message is received on stream 0. 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. Sachin-Sunil, HSS [Page 11] Internet Draft Test Specs for M2UA July 2000 "Data Send Primitive from NIF in AS Down State" + TEST NUMBER : 1.3.2 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : AS management + SUBTITLE : DATA send Primitive from NIF in AS Down State + PURPOSE: To check that if AS is down at SG and NIF sends Data send Primitive to send DATA to that ASP then it receives a send failure. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that ASPDN message with reason parameter 0x1 is sent from ASP to SG on stream 0. Arrange data in NIF at SG such that DATA primitive with interface identifier X and protocol Data is sent to SG. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM ASPIA ---------------> (ASP1) M-ASP-Status ---------> <--------------- NTFY( ASP-Up) <--------------- NTFY(AS-Up/AS-Pending) ASPDN ---------------> (ASP1) M-ASP-Status ---------> <--------------- NTFY( ASP-Down) <-------------- NTFY(AS-Down/AS-Pending) <-------- Data Interface id X Send failure --------> Sachin-Sunil, HSS [Page 12] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPIA Message for ASP1 from ASP to the SG. ASP will move to Up state at the SG. 2. Send ASPDN Message from ASP to the SG. ASP and AS will become down at the SG. Send Data send Primitive containing Protocol Data to send to the AS. 2. Check A: Send failure should be received at the NIF and DATA message should not be sent to AS. 3. Check B: NTFY message is received on stream 0. 4. Repeat the above test if instead of sending ASPDN 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. Sachin-Sunil, HSS [Page 13] Internet Draft Test Specs for M2UA July 2000 "Timer T(r) Cancellation" + TEST NUMBER : 1.3.3 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.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 ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Arrange data in ASP such that ASPIA and ASPAC messages are sent on stream 0 from ASP to SG with interface identifier X & Y and type parameter any valid value which is equal to the traffic handling mode configured for AS at the SG. Let the value of Timer T(r) is z sec. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is active ASPIA -----------------> (ASP1) M-ASP-Status --------> <---------------- NTFY( ASP-Up) <---------------- NTFY(AS-Pending) | Timer T(r) is started | | Time < z sec. <------- Data | Message will be buffered | <------- Data | Message will be buffered ASPAC ---------------> (ASP1) Status Ind --------> <--------------- NTFY ( ASP-Active) <--------------- NTFY(AS-Active) <--------------- DATA <--------------- DATA Sachin-Sunil, HSS [Page 14] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPIA Message from ASP to the SG. AS will become Up at the SG. Send Transfer Primitive containing Protocol Data with interface identifier X to send to ASP. 2. Check A: DATA message will not be received at ASP. 3. Send ASPAC message before Timer T(r) expires. 4. Check B: DATA messages buffered at the SG will be received at ASP. 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. Sachin-Sunil, HSS [Page 15] Internet Draft Test Specs for M2UA July 2000 "Timer T(r) Expiry" TEST NUMBER : 1.3.4 Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.5 TITLE : AS management SUBTITLE : Timer T(r) Cancellation 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 and ASP is active. Arrange data in ASP such that ASPIA and ASPAC messages are sent on stream 0 from ASP to SG with type field any valid value which is equal to the traffic handling mode configured for AS at the SG. Let value of Timer T(r) is z sec. The interface identifier values in ASPIA and ASPAC messages are X and Y. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is active ASPIA -----------------> (ASP1) M-ASP-Status --------> <---------------- NTFY( ASP-Up) <---------------- NTFY(AS-Pending) | Timer T(r) is started | | Time < z sec. <------- Data | Message will be buffered | <------- Data | Message will be buffered ASPAC ---------------> (ASP1) M-ASP-Status --------> <--------------- NTFY ( ASP-Active) <--------------- NTFY(AS-Active) <--------------- DATA <--------------- DATA ASPIA ----------------> M-ASP-Status --------> <--------------- NTFY (ASP-Up) Sachin-Sunil, HSS [Page 16] Internet Draft Test Specs for M2UA July 2000 <--------------- NTFY(AS-Pending) | |Time = z sec | | - M-ASP-Status ---------> <--------------- NTFY(AS-Up) <-------- Data Send Failure -------> TEST DESCRIPTION: 1. Send ASPIA Message from ASP to SG. ASP and AS will become Up at the SG. Send Transfer Primitive containing Protocol Data with interface id X. Send Transfer primitive from NIF to send some DATA to the ASP. Message will be buffered at SG. Send ASPAC message from ASP before timer T(r) expires. DATA message will be sent to ASP. Again send ASPIA message from ASP. 2. Check A: Timer T(r) is started again i.e. only after z sec AS will move to the AS-Down state. 3. Send Transfer Primitive from NIF to the SG. SG will send Send-Failure. 4. Check B: DATA messages buffered at the SG will be received ASP. 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. Sachin-Sunil, HSS [Page 17] Internet Draft Test Specs for M2UA July 2000 "Notify Message with ASP and AS Status" + TEST NUMBER : 1.3.5 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.2 + TITLE : AS management + SUBTITLE : Notify Message with ASP 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 AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange data in ASP such that first ASPDN message and then ASPUP, ASPAC and ASPIA messages are sent from ASP to SG on stream zero. Reason parameter in ASPDN message is 0x1. Type parameter in ASPAC and ASPIA message is equal to the traffic handling mode configured for AS at the SG. Interface id in ASPIA and ASPAC is X and Y. ALI parameter in ASPUP is M2UA. EXPECTED MESSAGE SEQUENCE : ASP SG SM ASP is active ASPDN ---------------> (ASP1) M-ASP-Status ----------> <--------------- NTFY( ASP-Down) <--------------- NTFY(AS-Down) ASPUP ---------------> (ASP1) M-ASP-Status -----------> <--------------- NTFY( ASP-Up) <-------------- NTFY (AS-Up) ASPAC ---------------> (ASP1) M-ASP-Status -----------> <-------------- NTFY( ASP-Active) <-------------- NTFY (AS-Active) Sachin-Sunil, HSS [Page 18] Internet Draft Test Specs for M2UA July 2000 ASPIA ---------------> (ASP1) M-ASP-Status -----------> <-------------- NTFY( ASP-Up) <-------------- NTFY (AS-Up) TEST DESCRIPTION: 1. Send ASPDN message for ASP from ASP to the SG. 2. Check A: NTFY messages with status ASP-Down and AS-Down will be received at the ASP. 3. Check B: Send ASPUP message and check that NTFY with status ASP-Up and AS-Up is received at ASP. 4. Check C: Send ASPAC message and check that NTFY with status ASP-Active and AS-Active is received at ASP. 5. Check D: Send ASPIA message and check that NTFY with status ASP-Up and AS-Up is received at ASP. 6. Check E: NTFY message is sent on stream 0. 7. Repeat the above test case if all messages from AS are sent on stream other than zero. 8. Repeat the above test case if optional parameters like ALI in ASPUP, interface identifier in ASPAC and ASPIA are not present. Response should be same. Note: In some cases on receiving ASPIA the NTFY(AS-Pending) may come in place of NTFY(AS-Up). This is implementation Specific. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 19] Internet Draft Test Specs for M2UA July 2000 "ASPAC message with more than one Interface Identifier" + TEST NUMBER : 1.3.6 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.4 + TITLE : AS management + SUBTITLE : ASPAC message with more than one interface identifier + PURPOSE: To check that If ASPAC message is received with more than one Interface Identifier then status of ASP is up in all the AS to which this ASP belongs. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. Arrange the data in ASP such that ASPAC message is sent on stream 0 from ASP to SG containing interface identifiers X, Y, P and Q. Traffic handling mode in AS1 and AS2 configured at SG is Loadshare and ASPAC message is sent with the Loadshare mode in Type parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Up ASPAC ------------------> Interface Id X,Y,P,Q M-ASP-Status ---------> <----------------- NTFY( ASP-Active) <----------------- NTFY(AS-Active) <-------- Data Interface Id X <----------------- DATA <-------- Data Interface Id Q <----------------- DATA Sachin-Sunil, HSS [Page 20] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPAC Message containing interface identifiers X, Y, P and Q from ASP to the SG. 2. Check A: NTFY messages should be received at ASP with status ASP-Active and AS-active with interface identifier X, Y, P and Q. 3. Check B: NTFY message is received on stream 0. 4. Check C: Check that state of ASP is active in all the AS to which this ASP belongs. This can be checked by sending DATA message with interface identifiers X and P. 5. Repeat the above test case if interface identifier parameter is not present in ASPAC message. The response should be same. Note: Interface identifier is an optional parameter in the NTFY message. In some implementation this parameter may not be present in NTFY message. In that case two NTFY messages with status AS-Up/ AS-Pending will be received one for AS1 and other for AS2. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 21] Internet Draft Test Specs for M2UA July 2000 "ASPAC message with Interface Identifiers less than configured" + TEST NUMBER : 1.3.7 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : AS management + SUBTITLE : ASPAC message with Interface Identifiers less than configured + PURPOSE: To check that If ASPAC message is received with Interface Identifiers less than it is configured for then NTFY message is returned with those interface identifier and ASP is active only for those interface identifiers + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. Arrange the data in ASP such that ASPAC message is sent on stream 0 from ASP to SG containing interface identifiers X and Q. Traffic handling mode in AS1 and AS2 configured at SG is Loadshare and ASPAC message is sent with the Loadshare mode in Type parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Up ASPAC ------------------> Interface Id X,Q M-ASP-Status ---------> <----------------- NTFY( ASP-Active) <----------------- NTFY(AS-Active) <-------- Data Interface Id X <----------------- DATA <-------- Data Interface Id P Send Failure ----------> Sachin-Sunil, HSS [Page 22] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPAC Message containing interface identifiers X and Q from ASP to the SG. 2. Check A: NTFY messages should be received at ASP with status ASP-Active and AS-active with interface identifier X and Q. 3. Check B: NTFY message is received on stream 0. 4. Check C: Check that state of ASP is active only for interface identifier X and Q. Send DATA message with interface identifiers X and Data primitive should be received at NIF. Send Data primitive from NIF with interface identifier P. Send failure should be received. Note: Interface identifier is an optional parameter in the NTFY message. In some implementation this parameter may not be present in NTFY message. In that case response to ASPAC message is implementation specific. An implementation may reject the ASPAC message or send ERROR message with cause "Invalid Interface Identifier". Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 23] Internet Draft Test Specs for M2UA July 2000 "ASPIA message with more than one Interface Identifier" + TEST NUMBER : 1.3.8 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5 + TITLE : AS management + SUBTITLE : ASPIA message with more than one interface identifier + PURPOSE: To check that If ASPIA message is received with more than one interface identifier then status of ASP is up in all the AS to which this ASP belongs. + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Arrange the data in ASP such that ASPIA message is sent from ASP to SG on stream 0 containing interface identifiers for AS1 and AS2. Traffic handling mode in AS1 and AS2 configured at SG is Loadshare and ASPAC message is sent with the Loadshare mode in Type parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Active ASPIA ------------------> Interface Id X,Y,P,Q M-ASP-Status ---------> <----------------- NTFY( ASP-Up) <----------------- NTFY(AS-Up/AS-Pending) <----------- Data Interface Id X Send Failure --------> <------------ Data interface id Q Send Failure --------> Sachin-Sunil, HSS [Page 24] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPIA Message containing interface identifiers P, Q, X and Y from ASP to the SG. 2. Check A: NTFY messages will be received at the ASP with status ASP-Up and AS-Up with interface id X, Y, P and Q. 3. Check B: NTFY message is sent on stream 0. 4. Check C: Check that state of ASP is Up in all the AS to which this ASP belongs. This can be checked by sending Data primitive from NIF at SG containing interface identifier X and P. 5. Repeat the above test case if interface identifier parameter is not present in ASPIA message. The response should be same. Note: Interface identifier is an optional parameter in NTFY message. In some implementation this parameter may not be present in NTFY message. In that case four NTFY messages with status AS-Up/ AS-Pending will be received two for AS1 and two for AS2. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 25] Internet Draft Test Specs for M2UA July 2000 "ASPIA message with Interface Identifiers less than configured" + TEST NUMBER : 1.3.9 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5 + TITLE : AS management + SUBTITLE : ASPIA message with Interface Identifiers less than configured + PURPOSE: To check that If ASPIA message is received with Interface Identifiers less than it is configured for then NTFY message is returned with those interface identifier and ASP is Up only for those interface identifiers + TEST CONFIGURATION: B + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Arrange the data in ASP such that ASPIA message is sent from ASP to SG on stream 0 containing interface identifiers for AS1 and AS2. Traffic handling mode in AS1 and AS2 configured at SG is Loadshare and ASPAC message is sent with the Loadshare mode in Type parameter. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF AS1 & AS2 is Active ASPIA ------------------> Interface Id X,Q M-ASP-Status ---------> <----------------- NTFY( ASP-Up) <----------------- NTFY(AS-Up/AS-Pending) <----------- Data Interface Id X Send Failure --------> <----------- Data interface id P <---------------- DATA Sachin-Sunil, HSS [Page 26] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPIA Message containing interface identifiers Q and X from ASP to the SG. 2. Check A: NTFY messages will be received at the ASP with status ASP-Up and AS-Up with interface id X and Q. 3. Check B: NTFY message is sent on stream 0. 4. Check C: Check that state of ASP is Up in all the AS to which this ASP belongs. This can be checked by sending Data primitive from NIF at SG containing interface identifier X and P. 5. Repeat the above test case if interface identifier parameter is not present in ASPIA message. The response should be same. Note: Interface identifier is an optional parameter in the NTFY message. In some implementation this parameter may not be present in NTFY message. In that case four NTFY messages with status AS-Up/ AS-Pending will be received two for AS1 and two for AS2. Note1: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 27] Internet Draft Test Specs for M2UA July 2000 "Notify Message with AS Status is sent only for AS State change - A" + TEST NUMBER : 1.3.10 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.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: SG is having SCTP association with ASP1 and ASP2. ASP1 is active while ASP2 is down. Arrange the data in AS such that ASPUP, ASPAC, ASPIA and ASPDN messages are sent on stream 0 for ASP2. ALI parameter in ASPUP message should be M2UA. Reason parameter in ASPDN message should be 0x1.Type parameter in ASPAC and ASPIA message should be same as the traffic handling mode configured for AS at SG. Interface identifiers parameter should be having values X and Y. EXPECTED MESSAGE SEQUENCE : AS SG SM Both ASP are active ASPIA(ASP1) -----------------> <---------------- NTFY( ASP-Up) Check: NTFY(AS-Up) is not received M-ASP-Status ---------> ASPDN(ASP1) -----------------> <---------------- NTFY( ASP-Down) Check: NTFY(AS-Down) is not received M-ASP-Status ---------> ASPUP(ASP1) -----------------> <---------------- NTFY( ASP-Up) Check: NTFY(AS-Up) is not received M-ASP-Status ---------> ASPAC(ASP1) -----------------> <---------------- NTFY( ASP-Active) Check: NTFY(AS-Active) is not received M-ASP-Status ---------> Sachin-Sunil, HSS [Page 28] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPUP message for ASP2 from AS to the SG. 2. Check A: NTFY messages with status ASP-Up will be received at the AS and NTFY message with status AS-Up is not received as AS is already Up. 3. Repeat the above test case for other messages like ASPAC, ASPIA and ASPDN for ASP2 from AS to SG. NTFY message with AS status should not be received in any case. Sachin-Sunil, HSS [Page 29] Internet Draft Test Specs for M2UA July 2000 "Notify Message with AS Status is sent only for AS State change- B" + TEST NUMBER : 1.3.11 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.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 received if AS state has changed. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SCTP association is established between SG and AS. There are two ASP in AS, ASP1 and ASP2. 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 ASP1and ASP2 on stream 0. Fill the interface identifier X and Y 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) -----------------> <---------------- NTFY( ASP-Up) M-ASP-Status ---------> ASPIA(ASP2) -----------------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up/AS-Pending) M-ASP-Status ---------> ASPDN(ASP1) -----------------> <---------------- NTFY( ASP-Down) M-ASP-Status ---------> ASPDN(ASP2) -----------------> <---------------- NTFY( ASP-Down) <---------------- NTFY( AS-Down/AS-Pending) Sachin-Sunil, HSS [Page 30] Internet Draft Test Specs for M2UA July 2000 M-ASP-Status ---------> ASPUP(ASP1) -----------------> <---------------- NTFY( ASP-Up) M-ASP-Status ---------> ASPUP(ASP2) -----------------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) M-ASP-Status ---------> ASPAC(ASP1) -----------------> <---------------- NTFY( ASP-Active) M-ASP-Status ---------> ASPAC(ASP2) -----------------> <---------------- NTFY( ASP-Active) <---------------- NTFY( AS-Active) M-ASP-Status ---------> TEST DESCRIPTION: 1. Send ASPIA message for ASP1 and ASP2 from ASP to the SG with interface identifier X and Y and Type parameter any valid value. 2. Check A: NTFY messages with status ASP-Up and AS-Up are received at the AS. 3. Repeat the above test case for other messages like ASPDN, ASPUP and ASPAC for ASP1 and ASP2 from AS to SG. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 31] Internet Draft Test Specs for M2UA July 2000 "Link Establish and Release Request and Confirmation" + TEST NUMBER : 1.4.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 + TITLE : Link management + SUBTITLE : Link Establish and Release Request and Confirmation + PURPOSE: To check that if Establish Request is received from ASP then NIF are indicated that establish request has been received. Also if NIF sends Establish confirm primitive then ESTABLISH CONFIRMATION message is sent to the concerned ASP. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2. Both ASPs are active. Arrange the data at ASP1 such that ESTABLISH REQUEST and RELEASE REQUEST messages are sent to the SG with the interface identifier X. Reason Parameter in the RELEASE REQUEST message should be Release_Mgmt. Also arrange the data in NIF at SG such that Establish Confirmation and Release Confirmation primitives are sent to the SG with interface identifier X in response to the received Establish and Release primitive. In Release Confirmation fill the reason with Release_Mgmt. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active a) ESTABLISH REQUEST ---------------> Establish -----------> <--------- Establish confirm Interface id X <-------------- ESTABLISH CONFIRM b) RELEASE REQUEST ---------------> Reason= Release_Mgmt Release -----------> <--------- Release confirm Interface id X <-------------- RELEASE CONFIRM Sachin-Sunil, HSS [Page 32] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ESTABLISH REQUEST message from ASP1 to the SG with interface identifier X. 2. Check A: Establish Request indication should be received at the NIF. 3. Send Establish confirm primitive from NIF at SG with interface id X. 4. Check B: ESTABLISH CONFIRMATION message is received only at ASP1 and not at ASP2. 5. Repeat the above test case for RELEASE REQUEST message from ASP1 to SG. Release Request indication should be sent to the NIF with the reason received in RELEASE REQUEST message. Send Release Confirmation Primitive from NIF with interface identifier X. RELEASE CONFIRAMTION message will be received at ASP1 and not at ASP2. Sachin-Sunil, HSS [Page 33] Internet Draft Test Specs for M2UA July 2000 "Release indication Primitive from NIF" + TEST NUMBER : 1.4.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 + TITLE : Link management + SUBTITLE: Release indication Primitive from NIF + PURPOSE: To check that if Release indication Primitive is received from NIF at SG then SG sends RELEASE INDICATION message to the concerned ASP. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2. Both ASP are Active. Also arrange the data in NIF at SG such that Release Indication primitive is sent to the SG with interface identifier X. In Release indication fill the reason with Release_Sios. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active <--------- Release Indication Interface id X <-------------- RELEASE INDICATION TEST DESCRIPTION: 1. Send Release Indication Primitive from NIF in the SG containing the interface identifier X. 2. Check A: RELEASE INDICATION message will be received at ASP1 containing the interface identifier passed to it from NIF. 3. Check B: RELEASE INDICATION message is received only at ASP1 and not at ASP2. 4. Repeat the test case with different valid value of reason parameter in Release Indication primitive. In these cases, RELEASE INDICATION message will be sent to ASP1 with the reason value received from NIF. 5. Repeat the above test case with interface identifier P. In this case message will be received at ASP2 and not at ASP1. Sachin-Sunil, HSS [Page 34] Internet Draft Test Specs for M2UA July 2000 "STATE Request primitive" + TEST NUMBER : 1.4.3 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 and 2.3.1.4 + TITLE : Link management + SUBTITLE : STATE Request primitive + PURPOSE: To check that if State request message is received from ASP then NIF is sent state primitive. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that STATE REQUEST Message is sent from ASP to the SG with Interface identifier X and State parameter Status_LPO_Set. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active STATE REQUEST ---------------> State = Status_LPO_Set State Request -----------> TEST DESCRIPTION: 1. Send STATE REQUEST message from ASP to SG with state parameter Status_LPO_Set. 2. Check A: State Request primitive will be received at the NIF at SG containing the interface identifier X and State received. 3. Repeat the above test case for other valid State parameter values. Sachin-Sunil, HSS [Page 35] Internet Draft Test Specs for M2UA July 2000 "STATE Confirm and Indication primitive" + TEST NUMBER : 1.4.4 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 and 2.3.1.4 + TITLE : Link management + SUBTITLE : STATE Confirm and Indication primitive + PURPOSE: To check that if State Confirm primitive is received from ULP at SG with interface identifier and State then STATE CONFIRM message is sent from SG to all the ASP which are handling traffic for that interface identifier. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2 and both ASP are active. Arrange the data in NIF at SG such that State Confirm primitive with state as Status_LPO_Set is sent to SG for interface identifier X. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active a) STATE REQUEST ---------------> State = Status_LPO_Set State Request -----------> <--------- State confirm Status_LPO_Set Interface id X To AS1 <-------------- STATE CONFIRM b) <--------- State Indication Event_Enter_RPO Interface id X <-------------- STATE INDICATION Sachin-Sunil, HSS [Page 36] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send STATE REQUEST message from AS to SG with state status_LPO_Set. Send State Confirm primitive from NIF at SG in its response with state Status_LPO_Set and interface identifier X. 2. Check A: STATE CONFIRM message will be received at ASP1 with state as Status_LPO_Set. 3. Check B: STATE CONFIRM message will not be received at ASP2. 4. Repeat the above test case for different valid values of State Parameter. STATE CONFIRM message will be received at ASP1 with the State parameter sent in State Confirm primitive from NIF at the SG. 5. Repeat the above test case for State Indication primitive with State parameter Event_Enter_RPO. STATE INDICATION message with state Event_Enetr_RPO will be received at AS1 and not at AS2. Repeat the test case for different valid values of State Parameter. 6. Repeat the above test case for interface identifier P. In this case STATE CONFIRM and STATE INDICATION messages will be received at ASP2 and not at ASP1. Sachin-Sunil, HSS [Page 37] Internet Draft Test Specs for M2UA July 2000 "RETRIEVAL REQUEST and CONFIRM message" + TEST NUMBER : 1.4.5 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.1 and 2.3.1.6 + TITLE : Link management + SUBTITLE : RETRIEVAL REQUEST and CONFIRM Message + PURPOSE: To check that if RETRIEVAL REQUEST message is received from ASP with action Action_Rtrv_BSN then SG sends Retrieval primitive to the NIF. Also if Retrieval primitive is received from NIF then RETRIEVAL CONFIRM message is sent to the ASP. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data at ASP such that RETRIEVAL REQUEST message is sent from ASP to SG with interface identifier X and action Action_Rtrv_BSN. Fsn_bsn parameter may be having any value. Arrange the data in NIF such that Retrieval primitive is sent from NIF at SG to M2UA with action Action_Rtrv_BSN. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active <--------- State Indication Event_Enter_RPO Interface id X <-------------- STATE INDICATION RETRIEVAL REQUEST ---------------> Action = Action_Rtrv_BSN Retrieval -----------> Action_Rtrv_BSN <--------- Retrieval Action_Rtrv_BSN <-------------- RETRIEVAL CONFIRM Sachin-Sunil, HSS [Page 38] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send State Indication from NIF with State Event_Enter_RPO to M2UA at SG. STAE INDICATION message will be received at the ASP. 2. Send RETRIEVAL REQUEST message from ASP to SG with action Action_Rtrv_BSN and fsn_bsn field any value in response to STATE INDICATION message. 3. Check A: NIF at SG will receive Retrieval primitive with action Action_Rtrv_BSN and FSN received. 4. Send Retrieval primitive from NIF to M2UA at SG with action Action_Rtrv_BSN and fsn_bsn any value. 5. Check B: RETRIEVAL CONFIRM message will be received at the ASP. 6. Repeat the above test case if fsn_bsn field in Retrieval primitive is -1. This value should be received at the ASP in the fsn_bsn field of the RETRIEVAL CONFIRM message. 7. Repeat the above test case with action Action_Rtrv_Msgs and Action_Drop_Msgs. In case of these actions also fill the fsn_bsn field with some value. Sachin-Sunil, HSS [Page 39] Internet Draft Test Specs for M2UA July 2000 "RETRIEVAL CONFIRM, INDICATION and COMLETE INDICATION messages" + TEST NUMBER : 1.4.6 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1, 2.3.1.6 and 2.3.1.7 + TITLE : Link management + SUBTITLE : RETRIEVAL CONFIRM, INDICATION and COMPLETE INDICATION Messages + PURPOSE: To check that if Retrieval Confirm Primitive is received from NIF with Action Action_Rtrv_BSN and BSN number retrieved then SG sends RETRIEVAL CONFIRM message to the concerned ASP with the action and BSN number passed to it from NIF. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2 and both ASP are Active. Arrange data in NIF at SG such that Retrieval primitive is sent to SG with interface identifier X, action Action_Rtrv_BSN and BSN any value. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active RETRIEVAL REQUEST ---------------> Action = Action_Rtrv_Msgs Retrieval -----------> Action_Rtrv_Msgs <--------- Retrieval Action_Rtrv_Msgs <-------------- RETRIEVAL CONFIRM Action_Rtrv_Msgs <--------- Retrieval MSU from retransmit Queue and not last MSU Interface Id X <-------------- RETRIEVAL INDICATION <--------- Retrieval MSU from retransmit Queue and last MSU Interface Id X <-------------- RETRIEVAL COMPLETE INDICATION Sachin-Sunil, HSS [Page 40] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send RETRIEVAL REQUEST message but with action Action_Rtrv_Msgs. Retrieval primitive will be received at the NIF. Send Retrieval primitive from NIF to the M2UA at SG in response. RETRIEVAL CONFIRM message will be sent from SG to ASP. 2. Send Retrieval primitive containing MSU and it is not the last MSU which will be told by the NIF. 3. Check A: RETRIEVAL INDICATION is received at the ASP1 with the PDU containing the MSU received from NIF. 4. Send Retrieval primitive containing MSU and it is the last MSU which will be told by the NIF. 5. Check B: RETRIEVAL COMPLETE INDICATION is sent to the ASP1 with the PDU containing the MSU received from NIF. 6. Repeat the above test cases for interface identifier P. In this case messages will be received at ASP2 and not at ASP1. Sachin-Sunil, HSS [Page 41] Internet Draft Test Specs for M2UA July 2000 "Invalid Version Error" + TEST NUMBER : 1.5.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 and 3.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. Arrange the data in ASP such that ASPIA message is sent to SG with the version other than Release 1.0 protocol. Type parameter in ASPIA message should be same as is the traffic handling mode configured for AS at the SG. Interface identifier parameter should be X and Y. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active ASPIA -----------------> Version = 2 <---------------- ERROR Cause = Invalid Version TEST DESCRIPTION: 1. Send ASPIA message ASP to SG containing version 2 in the common header. 2. Check A: ERROR message will be received at 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 SG like ASPAC, ASPUP, ASPDN, RETRIEVAL REQUEST, ESTABLISH REQUEST, RELEASE REQUEST, STATE REQUEST and DATA. Sachin-Sunil, HSS [Page 42] Internet Draft Test Specs for M2UA July 2000 "Invalid Traffic Handling Mode Error" + TEST NUMBER : 1.5.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1, 3.3.3.4 and 3.3.3.5 + 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 ASP is Active. Arrange the data in ASP such that ASPAC and ASPIA messages are sent on stream 0 with Type field filled with Loadshare mode of Traffic handling. Traffic Handling Mode at SG for AS is Override Mode. Interface identifier parameter should be X and common header should be valid. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active a) ASPAC -----------------> Type = Loadshare <---------------- ERROR Cause = Invalid Traffic Handling mode b) ASPIA -----------------> Type = Loadshare <---------------- ERROR Cause = Invalid Traffic Handling mode TEST DESCRIPTION: 1. Send ASPAC message from ASP to SG containing Type field Loadshare. 2. Check A: ERROR message will be received at 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 0x3. 5. Repeat all the above tests for ASPIA message with same parameters that were used for ASPAC message. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 43] Internet Draft Test Specs for M2UA July 2000 "Invalid Traffic Handling Mode Error if there are two ASP in one AS" + TEST NUMBER : 1.5.3 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1, 3.3.3.4 and 3.3.3.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 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 AS such that ASPAC message for ASP1 is sent on stream 0 with Type field filled with Override mode of Traffic handling and ASPAC message for ASP2 is sent on stream 0 with Type field filled with Loadshare mode of Traffic handling. Traffic Handling Mode defined at SG for AS is Override Mode. Fill value X and Y in interface identifier parameter. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active ASPAC (ASP1) -----------------> Type = Override M-ASP-Status ---------> <---------------- NTFY( ASP-Active) <---------------- NTFY( AS-Active) ASPAC (ASP2) -----------------> Type = Loadshare <---------------- ERROR Cause = Invalid Traffic Handling mode Sachin-Sunil, HSS [Page 44] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPAC message from ASP1 to SG containing Type field Override. 2. Check A: NTFY messages with ASP-Up and AS-Up status are received at the AS. 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 field. 6. Repeat the test case with Type field having value that is not defined i.e. any value greater than 0x03. 7. Repeat all the above tests for ASPIA message. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 45] Internet Draft Test Specs for M2UA July 2000 "Unrecognised Message Type" + TEST NUMBER : 1.5.4 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : Unrecognised 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 ASP is Active. Arrange the data in ASP such that a message with Message type not defined is sent to SG. Other parameters in the message can be like any other valid message. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active Message -----------------> Message Type = 0708 <---------------- ERROR Cause = Invalid Message Type DATA --------------> Interface Id X Receive Data ---------> TEST DESCRIPTION: 1. Send a message with message type 0708 or any other value which is not defined from ASP to SG. 2. Check A: ERROR message will be received at the ASP containing cause "Invalid Message Type". 3. Check B: State of ASP at SG is not disturbed. 4. Repeat the above test case by sending ESTABLISH CONFIRMATION, RELEASE CONFIRMATTION, RELEASE INDICATION, STATE CONFIRM, STATE INDICATION, RETRIEVAL CONFIRM and RETRIEVAL INDICATION messages which the SG is not expected to receive. In this case an error will be reported to the SM and message will be discarded. Sachin-Sunil, HSS [Page 46] Internet Draft Test Specs for M2UA July 2000 "Invalid Interface Identifier in MAUP messages" + TEST NUMBER : 1.5.5 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 and 2.2 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Interface Identifier + PURPOSE: To check that if a message with "invalid interface identifier" i.e. interface identifier not defined at SG is received then SG responds with ERROR message containing cause "Invalid Interface Identifier". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that DATA message with interface identifier P is sent to SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active DATA -----------------> Interface Id P <---------------- ERROR Cause = Invalid Interface Identifier DATA --------------> Interface Id X Receive Data ---------> TEST DESCRIPTION: 1. Send DATA message with interface identifier P that is not defined at SG. 2. Check A: ERROR message will be received at ASP containing cause "Invalid Interface Identifier". 3. Check B: State of ASP at SG is not disturbed. 4. Repeat the above test case for test configuration D. DATA message is sent from ASP1 with Interface identifier P that is defined at SG for ASP2. In this case also ERROR message should be received at ASP with cause "Invalid Interface identifier". 5. Repeat the above test case for other messages like RELEASE REQUEST, ESTABLISH REQUEST, STATE REQUEST and RETRIEVAL REQUEST. Other parameters in these messages should be having valid values. Response will be same in all cases. Sachin-Sunil, HSS [Page 47] Internet Draft Test Specs for M2UA July 2000 "Invalid interface Identifier parameter in ASPAC message" + TEST NUMBER : 1.5.6 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : Invalid Parameter in ASPAC message + PURPOSE: To check that if ASPAC message with Invalid interface identifier 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-Up state i.e. ASP1 is Up. Arrange the data in AS such that ASPAC message with interface identifier not equal to X and Y is sent to the SG on stream 0. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF AS is Up ASPAC -----------------> Interface Id Q <---------------- ERROR Cause = Invalid Interface Identifier ASPAC -----------------> Interface Id X and Q M-ASP-Status ---------> <---------------- NTFY( ASP-Active interface id X) <---------------- NTFY( AS-Active interface id X) <---------------- ERROR(Diagnostic field = Q) Cause = Invalid Interface Identifier TEST DESCRIPTION: 1. Send ASPAC message with interface identifier Q. 2. Check A: SG will take no action and will discard the ASPAC message. 3. Send ASPAC message with interface identifier X and Q. 4. Check B: NTFY messages will be received at the AS with status ASP-Active and AS-Active for interface identifier X. 5. Repeat the above test case with ASPIA message in ASP Active state. Response should be same. Note: Interface identifier is an optional parameter in ASPAC message. In some implementation this field may not come in ASPAC and ASPIA message. In those implementation test case need not be run. Note1: NTFY with AS status may come before the MTFY message with ASP status. Sachin-Sunil, HSS [Page 48] Internet Draft Test Specs for M2UA July 2000 "Invalid Reason parameter in ASPDN message" + TEST NUMBER : 1.5.7 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 + 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 ASPDN message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that ASPDN message with Reason Parameter filled with value 02 or more is sent to the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active ASPDN -----------------> Reason = 0x2 M-ASP-Status ---------> <---------------- NTFY( ASP-Down) <---------------- NTFY( AS-Down) TEST DESCRIPTION: 1. Send ASPDN message with Reason Parameter 0X2 from ASP to SG. 2. Check A: NTFY messages with status ASP-Down and AS-Down are received at ASP. Note1: NTFY with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 49] Internet Draft Test Specs for M2UA July 2000 "Invalid ALI parameter in ASPUP message" + TEST NUMBER : 1.5.8 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : Invalid ALI Parameter in ASPUP message + PURPOSE: To check that if ASPUP message with Invalid ALI parameter is received then ASPUP message is discarded. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Down. Arrange the data in ASP such that ASPUP message with ALI Parameter filled with value other than M2UA is sent to SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active ASPUP -----------------> ALI <> M2UA Message is discarded DATA -----------------> Interface id X Data ------------> TEST DESCRIPTION: 1. Send ASPUP message with ALI Parameter not equal to M2UA. 2. Check A: ASPUP message will be discarded and no message will be received at ASP. 3. Check B: State of ASP at SG is not disturbed. Note: ALI is an optional parameter. In some implementation this parameter may not come in ASPUP message. In these implementations this test case need not be run. Sachin-Sunil, HSS [Page 50] Internet Draft Test Specs for M2UA July 2000 "Message length less than the length of mandatory Parameters" + TEST NUMBER : 1.5.9 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Message length less than 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 ASP and ASP is Active. Arrange the data in ASP such that RELEASE REQUEST message with length parameter filled with value equal to the length of M2UA message header only. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active RELEASE REQUEST ---------------> Error --------> DATA ---------------> Interface id X Data --------> TEST DESCRIPTION: 1. Send RELEASE REQUEST message with length parameter filled with value equal to the length of M2UA message header only. 2. Check A: RELEASE REQUEST message will be discarded and Error is reported to SM. 3. Check B: State of ASP at SG is not disturbed. 4. Repeat the above test case for other messages like STATE REQUEST, RETRIEVAL REQUEST. Sachin-Sunil, HSS [Page 51] Internet Draft Test Specs for M2UA July 2000 "Interface Identifier not present in MAUP and MGMT messages" + TEST NUMBER : 1.5.10 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Interface Identifier not present in MAUP and MGMT messages + PURPOSE: To check that if a MAUP or MGMT message without Interface Identifier is sent to SG then SG responds with ERROR message "Invalid Interface Id". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that RELEASE REQUEST message without Interface Identifier (Tag 0x1 is not there after common header) is sent to SG. Reason parameter is having valid value. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active RELEASE REQUEST ---------------> <--------------- ERROR Invalid Interface Id DATA ---------------> Interface id X Data --------> TEST DESCRIPTION: 1. Send RELEASE REQUEST message without interface identifier to the SG. 2. Check A: RELEASE REQUEST message will be discarded and ASP will receive ERROR message with cause "Invalid Interface Id". 3. Check B: State of ASP at SG is not disturbed. 4. Repeat the above test case for other messages like STATE REQUEST, RETRIEVAL REQUEST. Note: A new Cause value in ERROR message can be added. Sachin-Sunil, HSS [Page 52] Internet Draft Test Specs for M2UA July 2000 "Length of Interface Identifier parameter in M2UA message header is other than four" + TEST NUMBER : 1.5.11 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Length of Interface Identifier parameter in M2UA message header is other than 4 + PURPOSE: To check that if a MAUP or MGMT message with length field in M2UA message header less than four is sent to SG then SG responds with ERROR message with cause "Invalid Interface Id". + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that RELEASE REQUEST message with length in M2UA message header less than four is sent to SG. Reason parameter is having the RELEASE_MGMT. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active RELEASE REQUEST ---------------> length in M2Ua header = 3 <--------------- ERROR Invalid Interface Id DATA ---------------> Interface id X Data --------> TEST DESCRIPTION: 1. Send RELEASE REQUEST message with length in M2UA message header less than four to the SG. 2. Check A: RELEASE REQUEST message will be discarded and ERROR message will be received at the ASP with cause "invalid Interface Id". 3. Check B: State of ASP at SG is not disturbed. 4. Repeat the above test case for other messages like STATE REQUEST, RETRIEVAL REQUEST. Sachin-Sunil, HSS [Page 53] Internet Draft Test Specs for M2UA July 2000 "Invalid Reason Parameter in RELEASE REQUEST message" + TEST NUMBER : 1.5.12 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Invalid Reason Parameter in RELEASE REQUEST message + PURPOSE: To Check that if RELEASE REQUEST message is received with invalid value of reason parameter then + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that RELEASE REQUEST message with interface identifier X and invalid value of Reason parameter is sent to SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active RELEASE REQUEST ---------------> Reason = 0xA Release request --------> TEST DESCRIPTION: 1. Send RELEASE REQUEST message with reason value 0xA, which is invalid, to the SG. 2. Check A: Release Primitive will be received at NIF at SG. Sachin-Sunil, HSS [Page 54] Internet Draft Test Specs for M2UA July 2000 "Invalid State Parameter in STATE REQUEST message" + TEST NUMBER : 1.5.13 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Invalid State Parameter in STATE REQUEST message + PURPOSE: To check that if STATE REQUEST message is received with invalid value of State parameter then SG discards the STATE REQUEST message + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that STATE REQUEST message with interface identifier X and invalid value of State parameter is sent to SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active STATE REQUEST ---------------> State = 0x6 DATA ---------------> Interface id X Data --------> TEST DESCRIPTION: 1. Send STATE REQUEST message with state value 0x6, which is invalid, to the SG. 2. Check A: STATE REQUEST message will be discarded and no message will be received at ASP. 3. Check B: State of ASP at SG is not disturbed. Sachin-Sunil, HSS [Page 55] Internet Draft Test Specs for M2UA July 2000 "Invalid Action Parameter in RETRIEVAL REQUEST message" + TEST NUMBER : 1.5.14 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Invalid Action Parameter in RETRIEVAL REQUEST message + PURPOSE: To check that if RETRIEVAL REQUEST message is received with invalid value of Action parameter then SG discards the RETRIEVAL REQUEST message. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that RETRIEVAL REQUEST message with interface identifier and invalid value of Action parameter is sent to SG. Fsn_bsn parameter may be having any value. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active RETRIEVAL REQUEST ---------------> Action = 0x4 DATA ---------------> Interface id X Data --------> TEST DESCRIPTION: 1. Send RETRIEVAL REQUEST message with action value 0x4, which is invalid, to the SG. 2. Check A: RETRIEVAL REQUEST message will be discarded and no message will be received at the ASP. 3. Check B: State of ASP at SG is not disturbed. 4. Repeat the above test case for invalid value of fsn_bsn field like -2 etc. Response should be same. Sachin-Sunil, HSS [Page 56] Internet Draft Test Specs for M2UA July 2000 "ERROR message with invalid error code" + TEST NUMBER : 1.5.15 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Invalid Message Handling + SUBTITLE : ERROR message with invalid error code + PURPOSE: To check that if ERROR message with Invalid Error code parameter is received then M2UA at ASP doesn't take any action but discard the message. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and AS is Active. Arrange the data in ASP such that ERROR message with invalid error code parameter( error code > 0x6) is sent to the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is active <--------- State Indication Event_Enter_RPO Interface id X <-------------- STATE INDICATION ERROR ---------------> Error Code = 0x6 Error --------> TEST DESCRIPTION: 1. Send STATE INDICATION message from SG to the ASP. In response to this message, send ERROR message with error code greater than or equal to 0x6 from ASP to the SG. 2. Check A: Error will be reported to the SM. 3. Further actions are implementation dependent. Implementation may close the association in this case. Sachin-Sunil, HSS [Page 57] Internet Draft Test Specs for M2UA July 2000 "ASPUP message in ASP-Up state" + TEST NUMBER : 1.6.1 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Duplicate Message Handling + SUBTITLE : ASPUP message in ASP-Up state + PURPOSE: To check that if ASPUP message is received in ASP-Up state then NTFY message with status ASP-Up is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Down. Arrange the data in ASP such that ASPUP message is sent to the SG two times on stream 0. ALI parameter in ASPUP message should be M2UA. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Down ASPUP ----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) ASPUP -----------------> <----------------- NTFY( ASP-Up) ASPAC -----------------> M-ASP-Status ---------> <----------------- NTFY( ASP-Active) <----------------- NTFY( AS-Active) TEST DESCRIPTION: 1. Send ASPUP message to the SG in ASP-Down state. NTFY messages will come from the SG with status ASP-Up and AS-Up. Send ASPUP message again from the ASP. 2. Check A: NTFY message with status ASP-Up will be received at the ASP. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Up state. Send ASPAC message for the ASP and NTFY with ASP-Active should come. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 58] Internet Draft Test Specs for M2UA July 2000 "ASPDN message in ASP-Down state" + TEST NUMBER : 1.6.2 + Reference: draft-ietf-sigtran-m2ua-02.txt + 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 NTFY message with status ASP-Down is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange the data in ASP such that ASPDN message is sent on stream 0 to the SG two times with the valid Reason Parameter. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Up ASPDN -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Down) <---------------- NTFY( AS-Down) ASPDN -----------------> <---------------- NTFY( ASP-Down) ASPUP -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) TEST DESCRIPTION: 1. Send ASPDN message to the SG in ASP-Up state. NTFY (ASP-Down) and NTFY (AS-Down) messages will come from the SG. Send ASPDN message again from the ASP. 2. Check A: NTFY message with status ASP-Down should be received at ASP. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Down state. Send ASPUP message with valid ALI for the ASP and NTFY with status ASP-Up should come. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 59] Internet Draft Test Specs for M2UA July 2000 "ASPAC message in ASP-Active state" + TEST NUMBER : 1.6.3 + Reference: draft-ietf-sigtran-m2ua-02.txt + 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 NTFY message with status ASP-Active is sent to the AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and AS is in AS-Up state i.e. ASP1 is Up. Arrange the data in ASP such that ASPAC message with correct Type (Type is same as defined at SG for the AS) and interface identifier X and Y is sent on stream 0 to the SG two times. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Up ASPAC -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Active) <---------------- NTFY( AS-Active) ASPAC -----------------> <---------------- NTFY( ASP-Active) DATA -----------------> Data ---------> TEST DESCRIPTION: 1. Send ASPAC message to the SG in ASP-Up state. NTFY (ASP-Active) and NTFY (AS-Active) messages will come from the SG. Send ASPAC message again from the ASP. 2. Check A: NTFY (ASP-Active) message should be received at ASP. 3. 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 Data indication to the NIF. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 60] Internet Draft Test Specs for M2UA July 2000 "ASPIA message in ASP-Up state" + TEST NUMBER : 1.6.4 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Duplicate Message Handling + SUBTITLE : ASPIA message in ASP-Up state + PURPOSE: To check that if ASPIA message is received in ASP-Up state then NTFY message with status ASP-Up is sent to the ASP. + 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 ASP such that ASPIA message with correct Type (Type is same as defined at SG for the AS) and interface identifier X and Y is sent on stream 0 to the SG two times. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active ASPIA -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-up/Pending) ASPIA -----------------> <---------------- NTFY( ASP-Up) ASPAC -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Active) <---------------- NTFY( AS-Active) TEST DESCRIPTION: 1. Send ASPIA message to the SG in ASP-Active state. NTFY (ASP-Up) and NTFY (AS-Up) messages will come from the SG. Send ASPIA message again from the ASP. 2. Check A: NTFY message with status ASP-Up will be received at ASP. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Up state. Send ASPAC message with correct Type ((Type is same as defined at SG for the AS) for the ASP1 and NTFY message with status ASP-Active should be received at ASP. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 61] Internet Draft Test Specs for M2UA July 2000 "ASPAC message in ASP-Down state" + TEST NUMBER : 1.6.5 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Duplicate Message Handling + SUBTITLE : ASPAC message in ASP-Down state + PURPOSE: To check that if ASPAC message is received in ASP-Active state then message is discarded. + 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 ASP such that ASPAC message with correct Type (Type is same as defined at SG for the AS) and interface identifier X and Y is sent to the SG on stream 0. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Down ASPAC -----------------> <---------------- NTFY( ASP-Down) ASPUP -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) TEST DESCRIPTION: 1. Send ASPAC message to the SG in ASP-Down state. 2. Check A: NTFY with status ASP-Down should be received at the ASP. 3. Check B: State of ASP at SG is not disturbed i.e. ASP remains in the Down state. Send ASPUP message with ALI M2UA for the ASP and SG should respond with NTFY message with status ASP-Up. 4. Repeat the above test case for ASPIA message i.e. ASPIA message is received in ASP-Down state with the same parameters as were in the ASPAC message. Response should be same. Note: NTFY message with AS status may come before the NTFY message with ASP status. Sachin-Sunil, HSS [Page 62] Internet Draft Test Specs for M2UA July 2000 "ASPUP message in ASP-Active state" + TEST NUMBER : 1.6.6 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5 + TITLE : Duplicate Message Handling + SUBTITLE : ASPUP message in ASP-Active state + PURPOSE: To check that if ASPUP message is received in ASP-Active state then NTFY message with status ASP-Up is sent to ASP and ASP state is moved to ASP-up. + CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and ASP1 is Active. Arrange the data in ASP such that ASPUP message with ALI parameter M2UA is sent to the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active ASPUP -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) ASPAC -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Active) <---------------- NTFY( AS-Active) TEST DESCRIPTION: 1. Send ASPUP message to the SG in ASP-Active state. 2. Check A: NTFY message with ASP-Up status should be received at ASP. 3. Check B: State of ASP should become ASP-Up. Note: In some implementation there may be T(r) running on receiving ASPUP 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 Data primitive. Sachin-Sunil, HSS [Page 63] Internet Draft Test Specs for M2UA July 2000 "ASPDN message in ASP-Active state" + TEST NUMBER : 1.6.7 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5 + TITLE : Duplicate Message Handling + SUBTITLE : ASPDN message in ASP-Active state + PURPOSE: To check that if ASPDN message is received in ASP-Active state then NTFY message with status ASP-Down 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 ASP and ASP is Active. Arrange the data in ASP such that ASPDN message with valid Reason parameter is sent to the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Active ASPDN -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Down) <---------------- NTFY( AS-Down/Pending) ASPUP -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) TEST DESCRIPTION: 1. Send ASPDN message to the SG in ASP-Active state. 2. Check A: NTFY message with ASP-Down status should be received at ASP. 3. Check B: State of ASP should become Down. Send Data primitive from NIF with interface idnetifier X to send DATA to the ASP and send failure should be received at the NIF. 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 Data primitive. Sachin-Sunil, HSS [Page 64] Internet Draft Test Specs for M2UA July 2000 "DATA message from AS in ASP-Down state" + TEST NUMBER : 1.7 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5 + TITLE : DATA message in ASP-Down State + 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 ASP and ASP is Down. Arrange the data in ASP such that DATA message with interface identifier X is sent to the SG. EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Down DATA -----------------> <----------------- NTFY(ASP-Down) ASPUP -----------------> M-ASP-Status ---------> <---------------- NTFY( ASP-Up) <---------------- NTFY( AS-Up) TEST DESCRIPTION: 1. Send DATA message to the SG in ASP-Down state. 2. Check A: DATA message should be discarded and no message will be received at the ASP in response to DATA message. 3. Check that state of SG is not disturbed. Send ASPUP message with ALI parameter M2UA. SG will respond with NTFY (ASP-Up). Sachin-Sunil, HSS [Page 65] Internet Draft Test Specs for M2UA July 2000 "ASPM messages when SG has locked the ASP for Management reason" + TEST NUMBER : 1.8 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.5 + TITLE : AS management + SUBTITLE : ASPM messages when SG has locked the ASP for Management reason + PURPOSE: To check that if ASPM message is received when SG has locked the ASP for management reason then NTFY message wit ASP-Down status is sent to AS. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and AS and ASP1 may be in any state. Arrange the data in SG such that ASP is locked at the SG. Arrange the data in AS such that ASPM message with valid parameters are sent to the SG on stream 0 EXPECTED MESSAGE SEQUENCE : AS SG SM + NIF ASP is Down <---------- Lock ASP ASPUP -----------------> <----------------- NTFY(ASP-Down) TEST DESCRIPTION: 1. Lock out the ASP at the SG by sending primitive for locking ASP from SM. Now send ASPUP message with valid parameters from ASP to SG. 2. Check A: NTFY message with ASP-Down status 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. Sachin-Sunil, HSS [Page 66] Internet Draft Test Specs for M2UA July 2000 "Message Routing towards ASP" + TEST NUMBER : 1.9.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.5 + TITLE : Message Routing + SUBTITLE : Message Routing towards ASP + PURPOSE: To check that if NIF sends a Data Transfer primitive containing Protocol DATA to send to the ASP then it is sent to the correct ASP. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2 and both ASP are Active. Also arrange the data in NIF at SG such that Data transfer primitive is sent to M2UA at SG with Protocol Data and interface identifier X. EXPECTED MESSAGE SEQUENCE : AS1 AS2 SG NIF All AS are active <---------- Data Interface Id X <---------------------------- DATA <---------- Data Interface Id Y <---------------------------- DATA <---------- Data Interface Id P <--------------- DATA TEST DESCRIPTION: 1. Send Data Transfer primitive from NIF in the SG with interface id X. 2. Check A: DATA message will be received at the ASP1. 3. Repeat the above test case for Data Transfer primitive containing Protocol Data and interface id Y. Data message should be received at ASP1. 4. Repeat the above test case for Data Transfer primitive containing Protocol Data and interface id P. Data message should be received at ASP2. Sachin-Sunil, HSS [Page 67] Internet Draft Test Specs for M2UA July 2000 "Routing for DATA not matching any Interface id" + TEST NUMBER : 1.9.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3.5 + TITLE : Message Routing + SUBTITLE : Routing for DATA not matching any Interface id + PURPOSE: To check that if NIF sends a Data Transfer primitive containing Protocol DATA and interface identifier not defined at the SG then default routing is given to this message. + TEST CONFIGURATION: D + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2 and both ASP are Active. Arrange the data in NIF at SG such that Data Transfer Primitive is sent to M2UA at SG with Protocol Data with interface id Z which is not defined at SG. EXPECTED MESSAGE SEQUENCE : ASP SG NIF + SM AS is Active <----------- Data Interface Id Z Error ----------> TEST DESCRIPTION: 1. Send Data Transfer Primitive from NIF in the SG containing the Protocol Data and interface id Z. 2. Check A: Error should be returned or some default routing will be given to this protocol data. Sachin-Sunil, HSS [Page 68] Internet Draft Test Specs for M2UA July 2000 "Loadshare Mode of Traffic handling" + TEST NUMBER : 1.10.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1 + 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 sent to the that ASP in addition to all other ASPs which are handling the traffic. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2. ASP1 is active and ASP2 is Up. Arrange the DATA in AS such that it sends ASPAC message for ASP2 with Loadshare mode and interface id X and Y. 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 M-ASP-Stataus -------> To ASP2 <--------------- NTFY(ASP-Active) <----------- Data Interface Id X To ASP1 <--------------- DATA <----------- Data Interface Id Y To ASP2 <--------------- DATA ASPIA(ASP1) ----------------> M-ASP-Stataus -------> <--------------- NTFY(ASP-Up) <----------- Data Interface Id X To ASP2 <--------------- DATA <----------- Data Interface Id Y To ASP2 <--------------- DATA Sachin-Sunil, HSS [Page 69] Internet Draft Test Specs for M2UA July 2000 TEST DESCRIPTION: 1. Send ASPAC message with loadshare mode in type field and interface id X and Y from AS to SG for ASP2. 2. Check A: SG should send NTFY message with status ASP-Active. 3. Check B: Traffic should also go ASP2 which has sent the ASPAC. Check this by sending Transfer Ind from NIF at SG containing interface id X and Y assuming traffic is load shared based on interface id. Sachin-Sunil, HSS [Page 70] Internet Draft Test Specs for M2UA July 2000 "Over-ride Mode of Traffic handling" + TEST NUMBER : 1.10.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1 + 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 override mode then all traffic is sent to that ASP which sent ASPAC message. + TEST CONFIGURATION: C + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2. ASP1 is active and ASP2 is Up. Arrange the DATA in AS such that it sends ASPAC message on stream 0 for ASP2 with Override mode and interface id X and Y. Also mode of traffic handling for AS at SG is Override. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 is Active ASPAC(ASP2) ----------------> Override Mode M-ASP-Status -------> To ASP2 <--------------- NTFY(ASP-Active) To ASP1 <--------------- NTFY(ASP-Up) <----------- Data Interface Id X To ASP2 <--------------- DATA <----------- Data Interface Id Y To ASP2 <--------------- DATA TEST DESCRIPTION: 1. Send ASPAC message with override mode in type field and interface identifier X and Y from AS to SG for ASP2. 2. Check A: SG should send NTFY message with status ASP-Active. 3. Check B: All traffic should also go to ASP2 which has sent the ASPAC. Check this by sending Data Transfer from NIF at SG containing interface identifier X and Y. DATA messages will be sent to ASP2. Sachin-Sunil, HSS [Page 71] Internet Draft Test Specs for M2UA July 2000 "Loadshare Mode of Traffic handling" + TEST NUMBER : 1.11.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1 + 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: B + PRE-TEST CONDITIONS: SG is having SCTP association with ASP1 and ASP2. ASP1 and ASP2 are active. Arrange the DATA in AS such that it sends ASPIA message for ASP2 with Loadshare mode and interface id X and Y. Also mode of traffic handling for AS at SG is Loadshare. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP1 & ASP2 are Active ASPIA(ASP2) ----------------> Loadshare Mode M-ASP-Stataus -------> To ASP2 <--------------- NTFY(ASP-Up) <----------- Data Interface Id X To ASP1 <--------------- DATA <----------- Data Interface Id Y To ASP1 <--------------- DATA TEST DESCRIPTION: 1. Send ASPIA message with loadshare mode in type field and interface identifier X and Y from ASP2 to SG. 2. Check A: NTFY message with status ASP-Up should be received at the AS. 3. Check B: All traffic should go ASP1. Check this by sending Data Transfer from NIF at SG with Protocol Data containing interface identifier X and y. Sachin-Sunil, HSS [Page 72] Internet Draft Test Specs for M2UA July 2000 "ERROR Handling" + TEST NUMBER : 1.12 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1 + 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 SG and ASP. ASP is active. Arrange data in ASP such that ERROR with cause "invalid version" is sent to the SG. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is Active ERROR ----------------> cause=Invalid version Error -------> DATA -----------------> Interface id X Data ---------> TEST DESCRIPTION: 1. Send ERROR message with cause invalid version from ASP to SG. 2. Check A: SM should receive error indication. 3. Check B: No other action should be taken at the SG. Check this by sending DATA message from the ASP with interface identifier X and Data primitive should be received at NIF at SG. 4. Repeat the test case for other cause values in ERROR message. Response should be same. Sachin-Sunil, HSS [Page 73] Internet Draft Test Specs for M2UA July 2000 "SCTP Connection Establishment" + TEST NUMBER : 1.13.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1 + TITLE : SCTP Connection Management + SUBTITLE : SCTP Connection Establishment + PURPOSE: To check that on receiving Communication Up primitive from SCTP, SG M2UA will send M-SCTP-Establish indication to the SM. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is not established between SG and ASP. Arrange the data in ASP such that SCTP association is established between ASP and SG. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF SCTP Establish request to SCTP SCTP association will be established by SCTP SG will receive Communication-Up primitive from SCTP M-SCTP-Establish Ind -------> ASPUP ------------------> M-ASP-Status --------> <----------------- NTFY(ASP-Up) <----------------- NTFY(AS-Up) TEST DESCRIPTION: 1. Make an SCTP association between ASP and SG. SG will receive Communication Up primitive from SCTP. 2. Check A: M-SCTP-Establish indication will be sent to the SM. 3. Send ASPUP message from ASP to SG 4. Check B: NTFY messages with status ASP-Up and AS-Up should be received at the ASP. Sachin-Sunil, HSS [Page 74] Internet Draft Test Specs for M2UA July 2000 "SCTP Connection Termination" + TEST NUMBER : 1.13.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 2.2.1 + TITLE : SCTP Connection Management + SUBTITLE : SCTP Connection Termination + PURPOSE: To check that on receiving SCTP-Communication Down indication primitive from SCTP, AS will send the M-SCTP Status primitive to the upper layer. + TEST CONFIGURATION: A + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Arrange for terminating the SCTP association between ASP and SG. EXPECTED MESSAGE SEQUENCE : ASP SG SM + NIF ASP is active ASPDN -------------> M-ASP-Status ---------> <----------------- NTFY(ASP-Down) <----------------- NTFY(AS-Down/AS-Pending) SCTP association is terminated SG will receive Communication-Down primitive from SCTP M-SCTP Status --------> <-------- Data Send Failure ---------> TEST DESCRIPTION: 1. Terminate the association between SG and AS. 2. Check A: SCTP association will be down and on receiving Communication Down primitive from SCTP, M-SCTP Status indication will be received at SM. 3. Check B: State of ASP will be down at the SG. Send data primitive from the NIF to send some Protocol DATA. SG will report send failure. Sachin-Sunil, HSS [Page 75] Internet Draft Test Specs for M2UA July 2000 4.2 Test Cases for Testing M2UA at AS These test cases are used to test the M2UA at AS. "Send and Receive of Data Primitive in AS active state" + TEST NUMBER : 2.1 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.1.1 + TITLE : Data Transfer Primitive + SUBTITLE : Send and receive of Data Transfer Primitive in AS active state + PURPOSE: To check that on receiving Data primitive from SU, DATA message is sent to the SG. Also if DFATA message is received the Data primitive is sent to the SU. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is in ASP-Active state. Arrange the data in ASP such that SU sends Data primitive to M2UA with interface identifier X. Also arrange data in SG such that DATA message with interface identifier X is sent to ASP. EXPECTED MESSAGE SEQUENCE : SG ASP SU ASP is Active a) <----------- Data <------------- DATA Interface Id X b) DATA --------------> Interface Id X Data ---------> TEST DESCRIPTION: 1. Send Data Primitive from the SU at ASP to send Protocol Data to SG. 2. Check A: DATA message is received at ASP with the data passed by the SU and the interface identifier X. 3. Send DATA message from SG containing Protocol Data and interface identifier X to the ASP. 4. Check B: Data primitive is received at SU with the Protocol Data and interface identifier X. Sachin-Sunil, HSS [Page 76] Internet Draft Test Specs for M2UA July 2000 "stream Selection" + TEST NUMBER : 2.2 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 1.5.3 + TITLE : Stream Selection + SUBTITLE : Stream Selection + PURPOSE: To check that all the messages for the same interface identifier are sent on the same SCTP stream. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP with two streams. ASP is active. Also arrange the data in ASP such that SU sends three or more Data primitive to M2UA containing the same interface identifier X. EXPECTED MESSAGE SEQUENCE : SG ASP SU AS is active <--------- Data Check Stream id <------------- DATA Interface Id X <--------- Data Check Stream id <------------- DATA Interface Id X <--------- Data Check Stream id <------------- DATA Interface Id X <--------- Data Check Stream id <------------- DATA Interface Id Y TEST DESCRIPTION: 1. Send three or more data Primitive from the SU at SG side to send Protocol Data to the SG with interface id X. 2. Check A: DATA messages are sent to the SG containing the same Stream Sequence number. 3. Send data primitive with interface identifier Y. 4. Check B: DATA messages should be received on the other stream. 5. Repeat the above case if number of streams between AS and SG is more than two but AS is handling only two interface identifiers. One or more stream may not be used for sending DATA message. 6. Repeat the above case if number of streams between AS and SG is two but AS is handling four interface identifiers. Send data primitives for all interface identifiers. DATA messages should be sent on both the streams and DATA messages for the same interface identifier are sent on the same stream. Note: How the message will be distributed on different streams is implementation specific. Sachin-Sunil, HSS [Page 77] Internet Draft Test Specs for M2UA July 2000 "SCTP Connection Establishment" + TEST NUMBER : 2.3.1 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.2.1 + TITLE : SCTP Connection Management + SUBTITLE : SCTP Connection Establishment + PURPOSE: To check that on receiving M-SCTP-Establish primitive from SM ASP initiates and establishes an SCTP association with the SG. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is not established between SG and ASP. Also arrange the data in ASP such that SM sends M-SCTP-Establish primitive to M2UA with the SG id to which the connection is to be established. EXPECTED MESSAGE SEQUENCE : SG ASP SU + SM <--------- M-SCTP-Establish Request <-------------------> SCTP association will be established by SCTP AS will receive Communication-Up primitive from SCTP M-SCTP-Establish Ind-------> TEST DESCRIPTION: 1. Send M-SCTP-Establish Request Primitive from the SM at ASP side to establish an SCTP association with the SG. 2. Check A: SCTP association will be established and M-SCTP-Establish indication will be received at the SM. Sachin-Sunil, HSS [Page 78] Internet Draft Test Specs for M2UA July 2000 "SCTP Connection Termination" + TEST NUMBER : 2.3.2 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.2.1 + TITLE : SCTP Connection Management + SUBTITLE : SCTP Connection Termination + PURPOSE: To check that on receiving SCTP-Communication Down indication primitive from SCTP, ASP will send the M-SCTP Status primitive to the SM. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is in active state. Also arrange the data in SG such that SCTP association is terminated between SG and AS. EXPECTED MESSAGE SEQUENCE : SG ASP SM + SU ASP is active <------------- ASPDN NTFY(ASP-Down) --------------> NTFY(AS-Down) --------------> SCTP association is terminated ASP will receive Communication-Down primitive from SCTP M-SCTP Status --------> <-------- Data Send Failure ---------> TEST DESCRIPTION: 1. Terminate the association between SG and ASP. 2. Check A: SCTP association will be down and on receiving Communication Down primitive from SCTP, M-SCTP Status indication will be received at the SM. 3. Check B: State of ASP will be down. Send Transfer primitive from the SU to send some Protocol DATA. ASP will report send failure. Note: It is possible that SCTP connection is terminated without exchanging the ASPDN message. Sachin-Sunil, HSS [Page 79] Internet Draft Test Specs for M2UA July 2000 "NTFY message is not received in response to ASPUP message" + TEST NUMBER : 2.4.1 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2 + TITLE : AS management + SUBTITLE : NTFY message is not received in response to ASPUP message + PURPOSE: To check that if NTFY message is not received in response to the ASPUP message then SG keeps on sending ASPUP message at an interval for some time and after some time will report the SM. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. Also arrange the data in ASP such that SM sends ASP Up primitive to the M2UA. Arrange data in SG such that NTFY message is not sent in response to the ASPUP message. EXPECTED MESSAGE SEQUENCE : SG ASP SM <----------- ASP-Up <------------ ASPUP | |time t1 <------------ ASPUP | |time t1 <------------ ASPUP . . . n tries . M-ASP-Status ----------> TEST DESCRIPTION: 1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message to the SG. Don't send NTFY message from the SG. 2. Check A: ASPUP message will be retransmitted to the SG. 3. Check B: Note the time for which ASPUP will be retransmitted. 4. Repeat the above test case for ASPDN message i.e. NTFY message is not sent in response to ASPDN message. Note: This case is implementation specific. In some implementation there may not be any retransmission. Also the time for which it will be retransmitted is implementation specific. Value of time t1 and n is also implementation dependent. Sachin-Sunil, HSS [Page 80] Internet Draft Test Specs for M2UA July 2000 "NTFY message with status ASP-Down is received in response to ASPUP message" + TEST NUMBER : 2.4.2 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2 + TITLE : AS management + SUBTITLE : NTFY message with status ASP-Down is received in response to ASPUP message + PURPOSE: To check that if NTFY message with status ASP-Down is received in response to the ASPUP message then SG sends ASPUP message again + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. Also arrange the data in ASP such that SM sends ASP Up primitive to the M2UA. Arrange data in SG such that NTFY message with status ASP-Down is sent in response to the ASPUP message on stream 0. EXPECTED MESSAGE SEQUENCE : SG ASP SM <----------- ASP-Up <------------ ASPUP NTFY(ASP-Down) ------------> <------------ ASPUP TEST DESCRIPTION: 1. Send ASP-Up primitive from SM at ASP. ASP will send ASPUP message to the SG. Send NTFY message with status ASP-Down from the SG. 2. Check A: ASPUP message will be retransmitted to the SG. Note: This case is implementation specific. In some implementation there may not be any retransmission. Sachin-Sunil, HSS [Page 81] Internet Draft Test Specs for M2UA July 2000 "ASP Management messages towards SG" + TEST NUMBER : 2.4.3 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.3 + TITLE : AS management + SUBTITLE : ASP Management messages towards SG + PURPOSE: To check that if SM sends primitive to send ASP management messages to the SG then the corresponding message is sent to the SG. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is active. Also arrange the data in ASP such that SM sends different ASP status primitive to the ASP with valid parameters. EXPECTED MESSAGE SEQUENCE : SG ASP SM <--------- ASP-Inactive <----------- ASPIA NTFY(ASP-Up) ------------> M-ASP-Status ---------> <--------- ASP-Down <----------- ASPDN NTFY(ASP-Down) ------------> M-ASP-Status ---------> <--------- ASP-Up <----------- ASPUP NTFY(ASP-Up) ------------> M-ASP-Status ---------> <--------- ASP-Active <----------- ASPAC NTFY(ASP-Active)------------> M-ASP-Status ---------> TEST DESCRIPTION: 1. Send ASP-Inactive Primitive from SM in ASP to M2UA. 2. Check A: ASPUP message will be received at the SG. Send NTFY(ASP-Up) in response to the ASPUP message. 3. Check B: ASPM messages are received on stream 0. 4. Repeat the test case for other primitives like ASP-Down, ASP-Active and ASP-Up. ASPDN, ASPAC and ASPUP messages will be sent from ASP to SG. 5. Repeat the above test case if NTFY message is sent on stream other than 0. Sachin-Sunil, HSS [Page 82] Internet Draft Test Specs for M2UA July 2000 "NTFY message with interface ID less than present in ASPAC message sent is received in response to ASPAC message" + TEST NUMBER : 2.4.4 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2 + TITLE : AS management + SUBTITLE : NTFY message with interface ID less than present in ASPAC message sent is received in response to ASPAC message + PURPOSE: To check that if NTFY message with interface Id less than those present in ASPAC message is received in response to the ASPAC message then ASP is marked active only for those interface ids. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Up. Also arrange the data in ASP such that SM sends ASP Active primitive to the M2UA with interface id X and Y. Arrange data in SG such that NTFY message is sent in response to the ASPAC message with interface id X. EXPECTED MESSAGE SEQUENCE : SG ASP SM <--------- ASP-Active Interface id X and Y <----------- ASPAC NTFY(ASP-Active)------------> interface Id X M-ASP-Status ---------> <--------- Data interface Id X <----------- DATA <--------- Data interface Id Y Send Failure ---------> TEST DESCRIPTION: 1. Send ASP-Active primitive from SM at ASP with interface id X and Y. ASP will send ASPAC message to the SG with interface id X and Y. Send NTFY message from the SG with interface id X. 2. Check A: Status Indication should be received at the SM. 3. Check B: Status of ASP will be active only for the interface id X and not for Y. Note: This case is implementation specific. In some implementation there may not be interface identifier parameter present in NTFY message. In those implementation, this test case need not be run. Sachin-Sunil, HSS [Page 83] Internet Draft Test Specs for M2UA July 2000 "NTFY message with interface ID less than present in ASPIA message sent is received in response to ASPIA message" + TEST NUMBER : 2.4.5 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.2 + TITLE : AS management + SUBTITLE : NTFY message with interface ID less than present in ASPIA message sent is received in response to ASPAC message + PURPOSE: To check that if NTFY message with interface Id less than those present in ASPAC message is received in response to the ASPIA message then ASP is marked Up only for those interface ids. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Also arrange the data in ASP such that SM sends ASP inactive primitive to the M2UA with interface id X and Y. Arrange data in SG such that NTFY message is sent in response to the ASPIA message with interface id X. EXPECTED MESSAGE SEQUENCE : SG ASP SM <--------- ASP-Inactive Interface id X and Y <----------- ASPIA NTFY(ASP-Up) ------------> interface Id Y M-ASP-Status ---------> <--------- Data interface Id X <----------- DATA <--------- Data interface Id Y Send Failure ---------> TEST DESCRIPTION: 1. Send ASP-Inactive primitive from SM at ASP with interface id X and Y. ASP will send ASPIA message to the SG with interface id X and Y. Send NTFY message from the SG with interface id Y. 2. Check A: Status Indication should be received at the SM. 3. Check B: Status of ASP will be Up only for the interface id Y and not for X. Note: This case is implementation specific. In some implementation there may not be interface identifier parameter present in NTFY message. In those implementation, this test case need not be run. Sachin-Sunil, HSS [Page 84] Internet Draft Test Specs for M2UA July 2000 "Invalid Version Error" + TEST NUMBER : 2.5.1 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1 and 3.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 ASP then ASP responds with ERROR message containing cause "Invalid Version" and diagnostic information filled with the version the SG supports. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Also arrange the data in SG such that DATA message with version other than release 1.0 is sent to the ASP. Interface identifier in DATA message is X. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active DATA ---------------> Version = 2 <-------------- ERROR Cause = Invalid Version TEST DESCRIPTION: 1. Send DATA message from SG to ASP containing version 2 in the common header. 2. Check A: ERROR message containing cause Invalid Version will be received at SG. 3. Check B: Diagnostic Field Parameter in ERROR is filled with version 1. 4. Repeat the above test cases for other messages from SG to ASP like ESTABLISH CONFIRM, RELEASE CONFIRM, RELEASE INDICATION, STATE CONFIRM, STATE INDICATION, DATA RETRIEVAL CONFIRM, DATA RETRIEVAL INDICATION and DATA RETRIEVAL COMPLETE INDICATION. Sachin-Sunil, HSS [Page 85] Internet Draft Test Specs for M2UA July 2000 "Unrecognised Message Type" + TEST NUMBER : 2.5.2 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : Unrecognised Message Type + PURPOSE: To check that if a message with message type not defined is received at AS, AS responds with ERROR message containing cause "Invalid Message Type". + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that a message with Message type not defined is sent to ASP. Let the other parameters in the message be like any other message. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active Message ---------------> Message Type = 0408 <-------------- ERROR Cause = Invalid Message Type DATA ---------------> Interface Id X Data ---------> TEST DESCRIPTION: 1. Send a message with message type 0408 or any other value which is not defined from SG to ASP. 2. Check A: ERROR message containing cause Invalid Message Type will be received at the SG. 3. Check B: State of ASP is not disturbed. 4. Repeat the above test cases by sending ASPUP, ASPDN, ASPAC, ASPIA messages from AS which the ASP is not expected to receive. In this case error will be reported to the SM and message will be discarded. Sachin-Sunil, HSS [Page 86] Internet Draft Test Specs for M2UA July 2000 "Invalid Interface identifier" + TEST NUMBER : 2.5.3 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 2.2 and 2.3.3.1 + TITLE : Invalid Message Handling + SUBTITLE : Invalid interface identifier + PURPOSE: To check that if a message with invalid interface identifier i.e. ASP does not handle traffic for that interface identifier then AS responds with ERROR message containing cause "Invalid interface identifier". + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that DATA message with invalid value of interface identifier is sent to ASP. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active DATA ---------------> Interface Id P <-------------- ERROR Cause = Invalid Interface Identifier DATA ---------------> Interface Id X Data ---------> TEST DESCRIPTION: 1. Send DATA message to the ASP with interface identifier which ASP doesn't handle. 2. Check A: AS will respond with ERROR message containing cause Invalid interface identifier. 3. Check B: State of ASP at AS is not disturbed. 4. Repeat the above test case for other messages like ESTABLISH CONFIRM, RELEASE CONFIRM, RELEASE INDICATION, STATE CONFIRM, STATE INDICATION, DATA RETRIEVAL CONFIRM, DATA RETRIEVAL INDICATION and DATA RETRIEVAL COMPLETE INDICATION. Sachin-Sunil, HSS [Page 87] Internet Draft Test Specs for M2UA July 2000 "Invalid Reason parameter in RELEASE CONFIRM and INDICATION message" + TEST NUMBER : 2.5.4 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Invalid Message Handling + SUBTITLE: Invalid Reason parameter in RELEASE CONFIRM and INDICATION message + PURPOSE: To check that if RELEASE CONFIRM and INDICATION messages with Invalid Reason parameter is received then it is reported to the upper layer. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Arrange the data in SG such that SCON message with congestion level with value 04 or more is sent to the ASP. In N/w Appearance parameter in SCON message, fill value A and for affected DPC fill any value. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active RELEASE CONFIRM -------------> Reason = 0xA Release Confirm --------> TEST DESCRIPTION: 1. Send RELEASE CONFIRM message with Reason parameter not defined i.e. value greater than 0x9. 2. Check A: Release primitive should be received at the SU. 3. Repeat the test case for RELEASE INDICATION message from SG to ASP with invalid value of Reason parameter. Release indication primitive will be received at the SU. Sachin-Sunil, HSS [Page 88] Internet Draft Test Specs for M2UA July 2000 "Invalid State Parameter in STATE CONFIRM message" + TEST NUMBER : 2.5.5 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Invalid State Parameter in STATE CONFIRM message + PURPOSE: To check that if STATE CONFIRM message is received with invalid value of State parameter then ASP discards the STATE CONFIRM message. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that STATE CONFIRM message with interface identifier X and invalid value of State parameter is sent to SG. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <------ State Request <------------ STATE REQUEST STATE CONFIRM -------------> State = 0x6 DATA -------------> Interface Id X Data -------> TEST DESCRIPTION: 1. Send STATE REQUEST message with state value 0x5 to the SG. Send state confirm message with state 0x6 in response to this message from SG. 2. Check A: STATE CONFIRM message will be discarded and no message will be received at SG. 3. Check B: State of ASP is not disturbed. 4. Repeat the above test case if STATE INDICATION message is sent from SG to ASP with state parameter greater than 0xf. Sachin-Sunil, HSS [Page 89] Internet Draft Test Specs for M2UA July 2000 "Invalid Action Parameter in RETRIEVAL CONFIRM message" + TEST NUMBER : 2.5.6 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Invalid Action Parameter in RETRIEVAL CONFIRM message + PURPOSE: To check that if RETRIEVAL CONFIRM message is received with invalid value of Action parameter then ASP discards the message. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that RETRIEVAL CONFIRM message with interface identifier and invalid value of Action parameter is sent to SG. Fsn_bsn parameter may be having any value. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <------ Retrieval Request <------------ RETRIEVAL REQUEST RETRIEVAL CONFIRM -------------> Action = 0x4 DATA -------------> Interface Id X Data -------> TEST DESCRIPTION: 1. Send RETRIEVAL REQUEST message with action value 0x1 from ASP to SG. Send RETRIEVAL CONFIRM message with action 0x4 in response to this message from SG to ASP. 2. Check A: RETRIEVAL CONFIRM message will be discarded and no message will be received at the ASP. 3. Check B: State of ASP is not disturbed. 4. Repeat the above test case for invalid value of fsn_bsn field like -2 etc. Response should be same. Sachin-Sunil, HSS [Page 90] Internet Draft Test Specs for M2UA July 2000 "ERROR message with invalid error code" + TEST NUMBER : 2.5.7 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Invalid Message Handling + SUBTITLE : ERROR message with invalid error code + PURPOSE: To check that if ERROR message with Invalid Error code parameter is received then M2UA at ASP doesn't take any action but discard the message. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and AS is Active. Arrange the data in SG such that ERROR message with invalid error code parameter( error code > 0x6) is sent to the ASP. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <------ State Request <------------ STATE REQUEST ERROR -------------> Error Code = 0x6 TEST DESCRIPTION: 1. Send STATE REQUEST message from ASP to the SG. In response to this message, send ERROR message with error code greater than or equal to 0x6 from SG to the ASP. 2. Check A: Error will be reported to the SM. 3. Further actions are implementation dependent. Implementation may close the association in this case. Sachin-Sunil, HSS [Page 91] Internet Draft Test Specs for M2UA July 2000 "Message length less than the length of mandatory Parameters" + TEST NUMBER : 2.5.8 + Reference: draft-ietf-sigtran-m2ua-03.txt + 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: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that RELEASE INDICATION message is sent to ASP with length parameter filled with value equal to the length of M2UA message header only. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active RELEASE INDICATION -------------> DATA -------------> Interface Id X Data -------> TEST DESCRIPTION: 1. Send RELEASE INDICATION message with length parameter filled with value equal to the length of M2UA message header only. 2. Check A: RELEASE INDICATION message will be discarded and no message will be received at the ASP. 3. Check B: State of ASP is not disturbed. 4. Repeat the above test case for other messages like STATE INDICATION, RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, RELEASE CONFIRMATION and RELEASE INDICATION. Sachin-Sunil, HSS [Page 92] Internet Draft Test Specs for M2UA July 2000 "Interface Identifier not present in MAUP messages" + TEST NUMBER : 2.5.9 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Interface Identifier not present in MAUP messages + PURPOSE: To check that if a MAUP message without Interface Identifier is sent to ASP then ASP responds with ERROR message with cause "Invalid Interface id'. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that RELEASE INDICATION message without Interface Identifier (Tag 0x1 is not there after common header) is sent to ASP. Reason parameter is having valid value. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active RELEASE INDICATION -------------> <------------- ERROR Invalid Interface Id DATA -------------> Interface Id X Data -------> TEST DESCRIPTION: 1. Send RELEASE INDICATION message without interface identifier to the ASP. 2. Check A: RELEASE INDICATION message will be discarded and SG will receive ERROR message with cause Invalid Interface Id. 3. Check B: State of ASP is not disturbed. 4. Repeat the above test case for other messages like STATE INDICATION, RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, RELEASE CONFIRMATION and RELEASE INDICATION. Note: A new Cause value may be added in the ERROR message. Sachin-Sunil, HSS [Page 93] Internet Draft Test Specs for M2UA July 2000 "Length of Interface Identifier parameter in M2UA message header is other than four" + TEST NUMBER : 2.5.10 + Reference: draft-ietf-sigtran-m2ua-03.txt + TITLE : Invalid Message Handling + SUBTITLE : Length of Interface Identifier parameter in M2UA message header is other than 4 + PURPOSE: To check that if a MAUP message with length field in M2UA message header less than four is sent to ASP then ASP responds with ERROR message with cause "Invalid Interface Id". + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in SG such that RELEASE INDICATION message with length in M2UA message header less than four is sent to ASP. Reason parameter is having the value RELEASE_MGMT. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active RELEASE INDICATION -------------> Length in M2UA Header = 3 <------------- ERROR Invalid Interface Id DATA -------------> Interface Id X Data -------> TEST DESCRIPTION: 1. Send RELEASE INDICATION message with length in M2UA message header less than four to the ASP. 2. Check A: RELEASE INDICATION message will be discarded and ERROR message will be received at the ASP with cause Invalid Interface Id. 3. Check B: State of ASP is not disturbed. 4. Repeat the above test case for other messages like STATE INDICATION, RETRIEVAL INDICATION, RETRIEVAL COMPLETE INDICATION, RELEASE CONFIRMATION and RELEASE INDICATION. Sachin-Sunil, HSS [Page 94] Internet Draft Test Specs for M2UA July 2000 "Link Establish and Release Confirmation" + TEST NUMBER : 2.6.1 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 + TITLE : Link management + SUBTITLE : Link Establish and Release Confirmation + PURPOSE: To check that if Establish request is received from SU at ASP then ESTABLISH REQUEST message is sent to ASP and if Establish Confirmation is received from SG then SU is indicated that establish indication has been received. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data at SG such that ESTABLISH CONFIRMATION and RELEASE CONFIRMATION messages are sent to the SG with the interface identifier X. Reason Parameter in the RELEASE CONFIRMATION message should be Release_Mgmt. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active a) <----------- Establish request <----------- ESTABLISH REQUEST ESTABLISH CONFIRMATION -------------> Establish Confirm --------> b) <----------- Release request <----------- RELEASE REQUEST Reason = Release_Mgmt RELEASE CONFIRMATION -------------> Release Confirm --------> TEST DESCRIPTION: 1. Send Establish request primitive from the SU at the ASP to M2UA. 2. Check A: ESTABLISH REQUEST message should be received at the SG. Send ESTABLISH CONFIRMATION message to the ASP in response to the received message with interface identifier X. 3. Check B: Establish confirmation indication should be received at the SU. 4. Repeat the above test case for Release Request primitive from SU at ASP to M2UA. RELASE REQUEST message should be received at SG. Send RELEASE CONFIRMATION message in response to the received message. Release Confirmation indication should be sent to the SU with the reason received in RELEASE CONFIRMATION message. Sachin-Sunil, HSS [Page 95] Internet Draft Test Specs for M2UA July 2000 "Release Indication message" + TEST NUMBER : 2.6.2 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 + TITLE : Link management + SUBTITLE: Release Indication message + PURPOSE: To check that if RELEASE INDICATION message is received at ASP then SU is reported of it. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data at SG such that RELEASE INDICATION messages are sent to the ASP with the interface identifier X. Reason Parameter in the RELEASE INDICATION message can be any valid value. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active RELEASE INDICATION -------------> Release Ind --------> TEST DESCRIPTION: 1. Send RELEASE INDICATION message from SG to ASP with interface identifier X. 2. Check A: Release ind primitive will be received at the SU with the reason received in the message. Sachin-Sunil, HSS [Page 96] Internet Draft Test Specs for M2UA July 2000 "STATE REQUEST and CONFIRMATION message" + TEST NUMBER : 2.6.3 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.1.1 and 2.3.1.4 + TITLE : Link management + SUBTITLE : STATE REQUEST and CONFIRMATION message + PURPOSE: To check that if State request primitive is received from SU at ASP then STATE REQUEST message is sent from ASP to the SG with state received from SU and if STATE CONFIRM message is received from SG then SU is indicated of that. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that State Request primitive is sent to M2UA from SU at ASP with state Status_Emer_Set. STATE CONFIRM Message is sent from SG to the ASP with Interface identifier X and State parameter Status_Emer_Set. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active a) <----------- State request Status_Emer_Set <----------- STATE REQUEST STATE CONFIRM -------------> State Confirm --------> b) STATE INDICATION -------------> State Indication--------> TEST DESCRIPTION: 1. Send State request primitive from the SU at the ASP to M2UA. 2. Check A: STATE REQUEST message should be received at the SG. Send STATE CONFIRM message to the ASP in response to the received message with interface identifier X. 3. Check B: State confirmation indication should be received at the SU. 4. Repeat the above test case for STATE INDICATION message from SG to ASP. State Indication should be received at the SU with the state received in STATE INDICATION message. Sachin-Sunil, HSS [Page 97] Internet Draft Test Specs for M2UA July 2000 "Retrieval Request and Confirm" + TEST NUMBER : 2.6.4 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.1 and 2.3.1.6 + TITLE : Link management + SUBTITLE : Retrieval Request and Confirm + PURPOSE: To check that if Retrieval request primitive is received from SU at ASP with interface identifier and action Action_Rtrv_BSN then RETRIEVAL REQUEST message is sent to SG and if RETRIEVAL CONFIRM message is received from SG the SU is indicated of that. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that Retrieval Request primitive is sent to M2UA from SU at ASP with action Action_Rtrv_BSN. Also RETRIEVAL CONFIRM message is sent from SG to the ASP with Interface identifier X and action parameter Action_Rtrv_BSN. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <----------- Retrieval Request Action_Rtrv_BSN <------------ RETRIEVAL REQUEST RETRIEVAL CONFIRM -------------> Action_Rtrv_BSN Retrieval Confirm --------> TEST DESCRIPTION: 1. Send Retrieval Request primitive from SU at ASP with action Action_Rtrv_BSN and interface identifier X. 2. Check A: RETRIEVAL REQUEST message will be received at SG with action Action_Rtrv_BSN. 3. Send RETRIEVAL CONFIRM message from SG to ASP with action Action_Rtrv_BSN from SG to ASP and fsn_bsn field any value. 4. Check B: Retrieval confirm primitive will be received at SU. 5. Repeat the above test case for different valid values of action Parameter. Sachin-Sunil, HSS [Page 98] Internet Draft Test Specs for M2UA July 2000 "Retrieval Indication and Retrieval Complete Indication " + TEST NUMBER : 2.6.5 + Reference: draft-ietf-sigtran-m2ua-03.txt Clause 3.3.1 and 2.3.1.7 + TITLE : Link management + SUBTITLE : Retrieval Indication and Retrieval Complete Indication + PURPOSE: To check that if RETRIEVAL INDICATION and RETRIEVAL COMPLETE INDICATION messages are received from SG then SU are indicated of that. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that Retrieval Request primitive is sent to M2UA from SU at ASP with action Action_Rtrv_MSGS. Also RETRIEVAL CONFIRM, RETRIEVAL INDICATION and RETRIEVAL COMPLETE INDICATION messages are sent from SG to the ASP with Interface identifier X . EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <----------- Retrieval Request Action_Rtrv_Msgs <------------ RETRIEVAL REQUEST RETRIEVAL CONFIRM -------------> Action_Rtrv_Msgs Retrieval Confirm --------> RETRIEVAL INDICATION ------------> Retrieval Indication--------> RETRIEVAL COMPLETE ------------> INDICATION Retrieval Complete Ind--------> TEST DESCRIPTION: 1. Send Retrieval Request primitive from SU at ASP with action Action_Rtrv_Msgs and interface identifier X. RETRIEVAL REQUEST message will be received at SG. 2. Send RETRIEVAL CONFIRM, RETRIEVAL INDICATION and RETRIEVAL COMPLETE INDICATION messages from SG to ASP with interface id X. 3. Check B: Retrieval indication and retrieval complete indication primitive will be received at SU. Sachin-Sunil, HSS [Page 99] Internet Draft Test Specs for M2UA July 2000 "NTFY(ASP-Up) is received in response to ASPDN message" + TEST NUMBER : 2.7.1 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Duplicate Message Handling + SUBTITLE : NTFY(ASP-Up) is received in response to ASPDN message + PURPOSE: To check that if NTFY (ASP-Up) message is received in response to the ASPDN then the NTFY message is discarded and ASPDN is sent again. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Up. Arrange the data in SG such that NTFY (ASP-Up) is sent to the ASP in response to ASPDN message with interface identifier X. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is Up <--------- ASP-Down <----------- ASPDN NTFY(ASP-Up) ------------> <----------- ASPDN TEST DESCRIPTION: 1. Send ASP-Down Primitive to the ASP. ASPDN message will be sent to the SG. Send NTFY message with status ASP-Up in response to the ASPDN message. 2. Check A: ASPDN message is received at the SG. 3. Repeat the above test case if NTFY message is sent with status ASP-Active. Sachin-Sunil, HSS [Page 100] Internet Draft Test Specs for M2UA July 2000 "NTFY(ASP-Active) is received in response to ASPIA message" + TEST NUMBER : 2.7.2 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : Duplicate Message Handling + SUBTITLE : NTFY(ASP-Active) is received in response to ASPIA message + PURPOSE: To check that if NTFY (ASP-Active) message is received in response to the ASPIA then the NTFY message is discarded and ASPIA is sent again. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is active. Arrange the data in SG such that NTFY (ASP-Active) with interface identifier X is sent to ASP in response to ASPIA message. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <--------- ASP-Inactive <----------- ASPIA NTFY(ASP-Active) ------------> <----------- ASPIA TEST DESCRIPTION: 1. Send ASP-Inactive Primitive to the AS. ASPIA message will be sent to the SG. Send NTFY message with status ASP-Active in response to the ASPIA message. 2. Check A: ASPIA message is received again at the SG. 3. Repeat the above test case if NTFY with ASP-Up is received in response to the ASPIA message. Sachin-Sunil, HSS [Page 101] Internet Draft Test Specs for M2UA July 2000 "DATA message from SG in ASP-Down state" + TEST NUMBER : 2.8 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : DATA message in ASP-Down State + SUBTITLE : DATA message from SG in ASP-Down state + PURPOSE: To check that if DATA message is received in ASP-Down state then it is discarded. + TEST CONFIGURATION: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP and ASP is Active. Arrange the data in ASP such that ASP inactive and ASP down primitives are sent from SM to M2UA. Also arrange data at SG such that NTFY and DATA message with interface identifier X and Y is sent to the SG. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is active <--------- ASP-Inactive <----------- ASPIA NTFY(ASP-Up) ------------> M-ASP-Status --------> <--------- ASP-Dowm <----------- ASPDN NTFY(ASP-Down) ------------> M-ASP-Status --------> DATA ------------> Interface Id X Error ---------> <----------- ASPDN TEST DESCRIPTION: 1. Send ASP-Inactive primitive from SM to M2Ua at ASP. ASPIA message will be received at SG. Send NTFY(ASP-Up) message to the ASP. Send ASP-Down primitive from SM to the M2UA at ASP. ASPDN message will be received at SG. Send NTFY(ASP-Down) in response to the ASP. 2. Send DATA message from the SG with interface identifier X. 3. Check A: DATA message should be discarded and ASPDN message should be sent to SG. Sachin-Sunil, HSS [Page 102] Internet Draft Test Specs for M2UA July 2000 "ERROR Handling" + TEST NUMBER : 2.9 + Reference: draft-ietf-sigtran-m2ua-02.txt + 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: E + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is in active state at the SG. Arrange data in SG such that ERROR with cause invalid version is sent to the AS. EXPECTED MESSAGE SEQUENCE : SG ASP SU ASP is active <------- Release Req <--------------- RELEASE REQUEST ERROR ---------------> Cause = invalid version Error --------> TEST DESCRIPTION: 1. Send ERROR message with cause invalid version from SG to ASP. 2. Check A: AS should report the error to its SM. 3. Check B: Further actions at the SG are implementation specific. 4. Repeat the test case for other cause values in ERROR message. Sachin-Sunil, HSS [Page 103] Internet Draft Test Specs for M2UA July 2000 "ASP in more than one AS" + TEST NUMBER : 2.10 + Reference: draft-ietf-sigtran-m2ua-02.txt Clause 3.3.3.4 + TITLE : ASP TEST CONFIGURATION + SUBTITLE : ASP configured to handle traffic for more than one AS + PURPOSE: To check that if an ASP has been configured to handle traffic for more than one AS then in ASPAC and ASPIA message more than one interface identifiers are sent. + TEST CONFIGURATION: F + PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP has been configured to handle traffic for interface identifier X, Y, P and Q. ASP is active. Arrange data in ASP such that ASP-Active is sent from SM with the list of AS or interface identifiers ASP is configured for. EXPECTED MESSAGE SEQUENCE : SG ASP SM ASP is Down <--------- ASP-Up <----------- ASPUP NTFY(ASP-Up) ------------> M-ASP-Status --------> <--------- ASP-Active <----------- ASPAC Interface Id X,Y,P,Q NTFY(ASP-Active) ------------> M-ASP-Status --------> <--------- ASP-inactive <----------- ASPIA TEST DESCRIPTION: 1. Send ASP-Up primitive from SM to ASP. ASPUP message will be sent from ASP to SG. Send NTFY (ASP-Up) from the SG. Now send ASP-Active primitive from SM. 2. Check A: ASPAC message is received at the SG containing interface identifier P, Q, X and Y. 3. Repeat the above test case for ASP-Inactive primitive from SM. ASPIA message should be sent to SG containing all interface identifier. Sachin-Sunil, HSS [Page 104] Internet Draft Test Specs for M2UA July 2000 "ASP in more than one SG" + TEST NUMBER : 2.11 + Reference: draft-ietf-sigtran-m2ua-02.txt + TITLE : ASP TEST CONFIGURATION + SUBTITLE : ASP configured to handle traffic for more than one AS + PURPOSE: To check that if an ASP has been configured to handle traffic for more than one SG then message are routed correctly among the two SG + TEST CONFIGURATION: G + PRE-TEST CONDITIONS: ASP is having SCTP association with SG1 and SG2. ASP is down. Arrange data in SM at ASP such that ASP-Up and ASP-Active primitives are sent to M2UA for SG1 and SG2. Also Arrange data in SG1 and SG2 such that NTFY messages are sent to ASP. EXPECTED MESSAGE SEQUENCE : SG1 SG2 ASP SM + SU ASP is Down <------- ASP-Up(for SG1) <-------------------------- ASPUP NTFY(ASP-Up) ---------------> M-ASP-Status -------> <------- ASP-Up(for SG2) <---------------- ASPUP NTFY(ASP-Up) --------> M-ASP-Status -------> <------- ASP-Active(for SG1) <-------------------------- ASPAC NTFY(ASP-Active) ---------------> M-ASP-Status -------> <------- ASP-Active(for SG2) <---------------- ASPAC NTFY(ASP-Active)-------> M-ASP-Status -------> <------- Data Sachin-Sunil, HSS [Page 105] Internet Draft Test Specs for M2UA July 2000 <--------------------------- DATA SG1 and Interface id X <------- Data <------------- DATA SG2 and Interface id X TEST DESCRIPTION: 1. Send ASP-Up primitive from SM to ASP for SG1 and SG2. 2. Check A: ASPUP message will be sent from ASP to SG1 and SG2. Send NTFY (ASP-Up) from the SG1 and SG2. Now send ASP-Active primitive from SM for SG1 and SG2. 3. Check B: ASPAC message is received at the SG1 and SG2. 4. Send Data primitive from SU to send data to SG1. 5. Check C: DATA message will be received at SG1. 6. Repeat the test set 5 to send data to SG2. Sachin-Sunil, HSS [Page 106] Internet Draft Test Specs for M2UA July 2000 5. Acknowledgement Authors are highly grateful to Mukesh and Kuldeep from HSS for their valuable comments and encouragement. 6. Authors Address Sachin Jindal, Sunil Mahajan email: smahajan@hss.hns.com Hughes Software Systems Plot#31, Sector 18 Electronic City Gurgaon, Haryana INDIA - 122015 Tel# +91-124-6346666 Fax# +91-124-6342810 7. References [1] Ken Morneault, Mallesh Kalla, G. Sidebottom, Ram Dantu, Tom George, SS7 MTP2-User Adaptation Layer (M2UA) Sachin-Sunil, HSS [Page 107]