OpenSS7 SS7 for the Common Man | © Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved. Last modified: Fri, 28 Nov 2008 10:52:01 GMT | |||||||||||||||||
| ||||||||||||||||||
| draft-bhola-conformance-test-iua-01Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-bhola-conformance-test-iua-01.txt. Network Working Group Vikas Bhola INTERNET-DRAFT Gayatri Singla Hughes Software Systems Expires in 6 months 17th Dec,2002 Conformance Test Specification for IUA <draft-bhola-conformance-test-iua-01.txt> Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress'. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft presents a test specification for RFC 3057 which defines the ISDN Q.921-User Adaptation protocol along with IUA Outstanding Issues <draft-ietf-sigtran-iua-imp-guide-02.txt>. This test specification can be used to test IUA implementations for conformance to the IUA protocol definition. Next revision of the draft will cover the additions done to the protocol revision and any subsequent RFC published by IETF. Vikas & Gayatri [Page 1] Internet Draft IUA Conformance Test Plan Dec 2002 Table of contents ================= 1. Introduction 1.1 Terminology 2. Test Setup 2.1 Test Environment 2.1.1 Simulated Test Setup 2.2 Various Configurations for the Test Suite 2.2.1 Various test Configurations at SG side 2.2.2 Various test Configurations at ASP side 3. Test Scenarios 3.1 ASPM Messages 3.1.1 Valid ASPM cases when ASP is Under Test 3.1.1.1.....ASPM_V_ASP_01 ASP Up and Active State Transition flow 3.1.1.2.....ASPM_V_ASP_02 ASP Inactive and Down State Transition flow 3.1.1.3.....ASPM_V_ASP_03 ASPUP Procedures when two ASPs are in two AS 3.1.1.4.....ASPM_V_ASP_04 ASP ACTIVE Procedures when two ASP's are in two AS 3.1.1.5.....ASPM_V_ASP_05 ASPUP Procedures when two ASPs are in one AS 3.1.1.6.....ASPM_V_ASP_06 ASPAC Procedures when two ASPs are in one AS 3.1.1.7.....ASPM_V_ASP_07 ASPAC Procedures when one ASP is in two AS 3.1.1.8.....ASPM_V_ASP_08 Heartbeat Procedures 3.1.1.9.....ASPM_V_ASP_09 Heartbeat Message Generation 3.1.1.10....ASPM_V_ASP_10 Text Based Interface identifiers in AS 3.1.1.11....ASPM_V_ASP_11 Routing Verification when Two ASP's are in two different AS(Text+Integer) 3.1.2 Invalid ASPM cases when ASP is Under Test 3.1.2.1.....ASPM_I_ASP_01 ASPM Message received in wrong state of ASP 3.1.2.2.....ASPM_I_ASP_02 ASPDN ACK in Active state of ASP 3.1.2.3.....ASPM_I_ASP_03 ASPSM Timer expiry Cases 3.1.2.4.....ASPM_I_ASP_04 ASPTM Timer expiry Cases 3.1.2.5.....ASPM_I_ASP_05 ASPIA ACK in response to ASPAC 3.1.2.6.....ASPM_I_ASP_06 Association re-establishment in case of Heartbeat timer expiry 3.1.3 Valid ASPM cases when SG is Under Test 3.1.3.1.....ASPM_V_SG_01 AS Inactive/Active State Transition in single ASP-SG scenario. 3.1.3.2.....ASPM_V_SG_02 AS Inactive and Down State Transition, in single ASP-SG scenario. 3.1.3.3.....ASPM_V_SG_03 Handling of the AS State Transition from Active to DOWN, in single ASP-SG scenario. 3.1.3.4.....ASPM_V_SG_04 ASPUP procedures when one ASP is in two AS 3.1.3.5.....ASPM_V_SG_05 ASPAC procedures when one ASP is in two AS 3.1.3.6.....ASPM_V_SG_06 ASPUP procedures when two ASP's are in two AS 3.1.3.7.....ASPM_V_SG_07 ASPAC procedures when two ASP's are in two AS 3.1.3.8.....ASPM_V_SG_08 ASUP procedures when Two ASP's are in one AS 3.1.3.9.....ASPM_V_SG_09 ASP ACTIVE procedures when two ASP's are in one AS(Override) Vikas & Gayatri [Page 2] Internet Draft IUA Conformance Test Plan Dec 2002 3.1.3.10....ASPM_V_SG_10 Text Based Interface identifiers in AS 3.1.3.11....ASPM_V_SG_11 Routing Verification when Two ASP's are in two different AS(Text+Integer) 3.1.3.12....ASPM_V_SG_12 Loadshare procedures 3.1.3.13....ASPM_V_SG_13 Notify-Insufficient Resources 3.1.3.14....ASPM_V_SG_14 AS-Active again before pending timer expires 3.1.3.15....ASPM_V_SG_15 Heartbeat Procedures 3.1.3.16....ASPM_V_SG_16 Optional parameter handling 3.1.3.17....ASPM_V_SG_17 ASPAC/ASPIA message handling when it contains no interface identifier 3.1.4 Invalid ASPM cases when SG is Under Test 3.1.4.1.....ASPM_I_SG_01 Retransmitted ASPSM Message received 3.1.4.2.....ASPM_I_SG_02 Retransmitted ASPTM Message received 3.1.4.3.....ASPM_I_SG_03 ASPUP message handling in ACTIVE state of ASP 3.1.4.4.....ASPM_I_SG_04 ASPAC message handling in DOWN state of ASP 3.1.4.5.....ASPM_I_SG_05 Traffic Mode Parameter Missing in ASPAC 3.2 QPTM Messages 3.2.1 Valid QPTM cases when ASP is Under Test 3.2.1.1.....QPTM_V_ASP_01 Link Establishment Procedures 3.2.1.2.....QPTM_V_ASP_02 Link Release Request/Confirm Procedures 3.2.1.3.....QPTM_V_ASP_03 Link Release/Establish Indication Procedures 3.2.1.4.....QPTM_V_ASP_04 Unitdata Procedures 3.2.2 Valid QPTM cases when SG is Under Test 3.2.2.1.....QPTM_V_SG_01 Link Establishment Procedures 3.2.2.2.....QPTM_V_SG_02 Link Release Request/Confirm Procedures 3.2.2.3.....QPTM_V_SG_03 Link Release/Establish Indication Procedures 3.2.2.4.....QPTM_V_SG_04 Unitdata Procedures 3.2.2.5.....QPTM_V_SG_05 Mapping Interface Identifier within multiple Associations/Streams 3.3 MGMT Messages 3.3.1 MGMT cases when ASP is Under Test 3.3.1.1.....MGMT_V_ASP_01 TEI Status Request/Confirm Procedures 3.3.1.2.....MGMT_V_ASP_02 TEI Status Query/Indication Procedures 3.3.2 MGMT cases when SG is Under Test 3.3.2.1.....MGMT_V_SG_01 TEI Status Request/Confirm Procedures 3.3.2.2.....MGMT_V_SG_02 TEI Status Query/Indication Procedures 3.3.3 Invalid scenario handling when SG is under test 3.3.3.1.....MGMT_I_SG_01 Invalid Version Error 3.3.3.2.....MGMT_I_SG_02 Invalid Interface identifier 3.3.3.3.....MGMT_I_SG_03 Unsupported Message Class/Type 3.3.3.4.....MGMT_I_SG_04 Unsupported Traffic Handling mode 3.3.3.5.....MGMT_I_SG_05 Unexpected Message 3.3.3.6.....MGMT_I_SG_06 Invalid Stream Identifier 3.3.3.7.....MGMT_I_SG_07 Unsupported Interface Identifier Type 3.3.3.8.....MGMT_I_SG_08 Refused - Management Blocking 3.4 ASP Identifier Cases 3.4.1 ASP Identifier Valid Cases 3.4.1.1.....ASPI_V_ASP_01 ASP Identifier Based Routing 3.4.2 ASP Identifier Invalid Cases 3.4.2.1.....ASPI_I_SG_01 ASP Identifier Required 3.4.2.2.....ASPI_I_SG_02 Invalid ASP Identifier 3.5 Miscellaneous Cases 3.5.1 MISC cases when SG is Under Test 3.5.1.1.....MISC_V_SG_01 SCTP Restart Handling Vikas & Gayatri [Page 3] Internet Draft IUA Conformance Test Plan Dec 2002 3.5.1.2.....MISC_V_SG_02 SCTP Comm-lost Handling 3.5.1.3.....MISC_V_SG_03 Establishing SCTP Association from SG 3.5.1.4.....MISC_V_SG_04 Payload Protocol id as 1 3.5.2 MISC cases when ASP is Under Test 3.5.2.1.....MISC_V_ASP_01 Multiple SG Scenario 4 Acknowledgements 5 References 6 Authors' Address 1. Introduction IUA is a protocol used for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This Draft presents a test specification for RFC 3057 which defines the ISDN Q.921-User Adaptation protocol along with IUA Outstanding Issues <draft-ietf-sigtran-iua-imp-guide-02.txt>. 1.1 Terminology IUT - IUT refers to the Implementation Under Test. It refers to IUA stack(Configured as SG or ASP) Peer - It refers to the peer simulator(Simulating SG or ASP) For rest of standard terminology please refer Section 1.2 of rfc3057. 2. TEST SETUP ========== 2.1 Test Environment 2.1.1 Simulated Test Setup +-------+ | USER | | STUB | +-------+ | PCO| | +-------+ +-------+ | | | | | IUT |-----------------------|PEER | | | PCO |END | +-------+ +-------+ Vikas & Gayatri [Page 4] Internet Draft IUA Conformance Test Plan Dec 2002 In the simulated test setup : IUT is the Implementation Under Test i.e. IUA stack. The User stub is the simulated Q.921 user, which will invoke the different primitives. Peer End is the remote end for sending and receiving the messages. PCO in the above figure reflects the "Point of Control and Observation". SCTP will be used as a an underlying layer on both ends(This is not explicitly shown in the above Figure). 2.2 VARIOUS CONFIGURATIONS FOR THE TEST SUIT ========================================= 2.2.1 VARIOUS TEST CONFIGURATION AT SG SIDE Configuration A: This simple configuration is used for all procedures of tests concerning only one AS. Configuration A is shown in figure 1. AS is handling traffic for Interface Identifier X or a range of interface identifiers. AS is having only one ASP (ASP1). Interface Identifiers can be 1. Integer Based 2. Text Based +-------------+ +--------------+ | | | AS IID=X | | SG | | ------- | | (IUT) |-------------------------------| | ASP1 | | | | | ------- | +-------------+ +--------------+ Peer Fig 1: Configuration A Configuration B: This configuration is used for all the procedures of tests concerning two or more ASP in one AS. Configuration B is shown in figure 2. AS handles the traffic for Interface identifiers X-Z. AS can be in OVERRIDE or LOADSHARE mode of traffic handling. Vikas & Gayatri [Page 5] Internet Draft IUA Conformance Test Plan Dec 2002 +--------------+ | AS IID X-Z | +-------------+ | ------- | | |-------------------------------|-| ASP1 | | | | | ------- | | SG | | ------- | | (IUT) | | | ASP2 | | | |-------------------------------|- ------- | +-------------+ +--------------+ Peer Fig 2: Configuration B Configuration C: This configuration is used for all the procedures of tests concerning one ASP in two AS which is handling traffic for both AS. Configuration C is shown in figure 3. AS1 handles the traffic for Interface Identifier X and AS2 handles traffic for Interface Identifier Y. ASP1 is in both AS. +--------------+ | | | -------- | ----------| | ASP1 | | +-------------+ | | ------- | | | | | | | |-------------------- | AS 1 | | SG | | | | (IUT) | +--------------+ | |--------------------- | | | +-------------+ | | | +--------------+ | | AS 2 | | | -------- | | | | ASP1 | | | | -------- | | | -------- | ----------| | ASP2 | | | -------- | +--------------+ Peer Fig 3: Configuration C Vikas & Gayatri [Page 6] Internet Draft IUA Conformance Test Plan Dec 2002 2.2.2 VARIOUS TEST CONFIGURATION AT ASP SIDE Configuration D: This simple configuration is used for all procedures of tests concerning only one AS. Configuration D is shown in figure 4. AS is handling traffic for Interface Identifier X or a range of interface identifiers. AS is having only one ASP (ASP1). Interface Identifiers can be 1. Integer Based 2. Text Based +-------------+ +--------------+ | | | AS IID=X | | SG | | ------- | | |-------------------------------| | ASP1 | | | | | ------- | +-------------+ +--------------+ Peer IUT Fig 4: Configuration D Configuration E: This configuration is used for all the procedures of tests concerning two or more ASP in one AS. Configuration E is shown in figure 5. AS handles the traffic for Interface identifiers X-Z. AS can be in OVERRIDE or LOADSHARE mode of traffic handling. +--------------+ | AS IID X-Z | +-------------+ | ------- | | |-------------------------------|-| ASP1 | | | | | ------- | | SG | | ------- | | | | | ASP2 | | | |-------------------------------|- ------- | +-------------+ +--------------+ Peer IUT Fig 5: Configuration E Vikas & Gayatri [Page 7] Internet Draft IUA Conformance Test Plan Dec 2002 Configuration F: This configuration is used for all the procedures of tests concerning one ASP in two AS which is handling traffic for both AS. Configuration F is shown in figure 6. AS1 handles the traffic for Interface Identifier X and AS2 handles traffic for Interface Identifier Y. ASP1 is in both AS. +--------------+ | | | -------- | ----------| | ASP1 | | +-------------+ | | ------- | | | | | | | |-------------------- | AS 1 | | SG | | | | | +--------------+ | |--------------------- | | | +-------------+ | Peer | | +--------------+ | | AS 2 | | | -------- | | | | ASP1 | | | | -------- | | | -------- | ----------| | ASP2 | | | -------- | +--------------+ IUT Fig 6: Configuration F Configuration G: This configuration is used for all the procedures of tests concerning two SG's and one ASP. ASP1 is connected to both SG1 and SG2. Vikas & Gayatri [Page 8] Internet Draft IUA Conformance Test Plan Dec 2002 +-------------+ | | | | | SG1 |--------------- | | | +--------------+ | | | | AS1 IID X-Z | +-------------+ | | ------- | ---------------| | ASP1 | | ---------------| ------- | | +--------------+ | | +-------------+ | | | | | | | | SG2 |-------------- | | | | +-------------+ Fig 7: Configuration G 3. TEST SCENARIOS 3.1 ASPM Messages 3.1.1 Valid ASPM cases when ASP is Under Test --------------------------------------------------------------- 3.1.1.1 ASPM_V_ASP_01 : ASP Up and Active State Transition flow --------------------------------------------------------------- Test Objective: To verify the ASP Up and Active state transition Procedures at an ASP end. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3.1.1 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP and SG. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-UP request from LM for ASP1. Verify that an ASPUP message is sent to the peer. b) Send an ASPUP ACK from the peer. Vikas & Gayatri [Page 9] Internet Draft IUA Conformance Test Plan Dec 2002 Verify that an M-ASP-UP confirm primitive is invoked by the ASP. c) Verify that the ASP state is moved to ASP-INACTIVE. d) Invoke an M-ASP-ACTIVE request from LM for ASP1. Verify that an ASPAC message is sent to the SG. ASPAC message can be empty or may contain IID/IID's. e) Send an ASPAC ACK in response to the ASPAC. Verify that an M-ASP-ACTIVE confirm primitive is invoked by the ASP. f) Verify that the ASP state is moved to ASP-ACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-UP----------> Request ---------------ASPUP--------------> <--------------ASPUP-ACK----------- <-------M-ASP-UP--------- confirm ASP state is now ASP-INACTIVE <---------NOTIFY(AS-INACTIVE)------ AS state is now AS-INACTIVE -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPAC-ACK----------- <------M-ASP-ACTIVE----- Confirm ASP state is now ASP-ACTIVE <---------NOTIFY(AS-ACTIVE)------ AS state is now AS-ACTIVE --------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.2 ASPM_V_ASP_02 : ASP Inactive and Down State Transition flow --------------------------------------------------------------- Test Objective: To verify the ASP Inactive and Down state transition Procedures at ASP end. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3.1.1 Vikas & Gayatri [Page 10] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP and SG. ASP is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-INACTIVE request from LM for ASP1. Verify that an ASPIA message is sent to the peer. ASPIA message can be empty or may contain IID/IID's. b) Send an ASPIA ACK from the peer. Verify that an M-ASP-INACTIVE Confirm indication is given to LM. c) Also verify that ASP state is moved to ASP-INACTIVE. d) Invoke an M-ASP-DOWN request from LM for ASP1. Verify that an ASPDN message is sent to the SG. e) Send an ASPDN ACK from peer(SG) in response to the ASPDN. Verify that M-ASP-DOWN Confirm indication is given to LM. f) Verify that state of ASP is moved to ASP-DOWN. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) ASP state is ASP-ACTIVE --------M-ASP-INACTIVE---> Request ----------------ASPIA-------------> <---------------ASPIA-ACK---------- <-------M-ASP-INACTIVE--- confirm ASP state is ASP-INACTIVE <---------NOTIFY(AS-INACTIVE)------ -------M-ASP-DOWN-----> Request ---------------ASP-DOWN-----------> <--------------ASP-DOWN-ACK------- <------M-ASP-DOWN----- Confirm ASP state is now ASP-DOWN -------------------------------------------------------------- Vikas & Gayatri [Page 11] Internet Draft IUA Conformance Test Plan Dec 2002 -------------------------------------------------------------- 3.1.1.3 ASPM_V_ASP_03 : ASPUP Procedures when two ASP's are in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check the ASPUP procedures when two ASP's are in two AS. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- F AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling traffic for IID range 15-20. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-UP request from LM for ASP1. An ASPUP message should be sent to the peer(SG). b) Send an ASPUP ACK and two Notify (AS-Inactive) messages in response, corresponding to AS1 and AS2 from peer to ASP side. Verify that ASP1 is moved to ASP-INACTIVE state. c) Invoke an M-ASP-UP request from LM for ASP2. An ASPUP message should be sent to the peer(SG). d) Send an ASPUP ACK from peer to the ASP side. Verify that state of ASP2 is moved to ASP-INACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) ASP1 state is ASP-DOWN --------M-ASP-UP-------> Request (for ASP1) ----------------ASPUP-------------> <---------------ASPUP-ACK---------- <-------M-ASP-UP------- confirm ASP1 state is ASP-INACTIVE <-------NOTIFY (AS-Inactive)------- for AS1 <-------NOTIFY (AS-Inactive)------- for AS2 --------M-ASP-UP-------> Request (for ASP2) ----------------ASPUP-------------> Vikas & Gayatri [Page 12] Internet Draft IUA Conformance Test Plan Dec 2002 <---------------ASPUP-ACK---------- <-------M-ASP-UP------- confirm ASP2 state is ASP-INACTIVE -------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.4 ASPM_V_ASP_04 : ASP ACTIVE Procedures when two ASP's are in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check the ASPAC procedures when two ASP's are in two AS. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- F AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling traffic for IID range 15-20. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1 and ASP2 are in ASP-INACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-ACTIVE request from LM of ASP1 for AS1. Verify that an ASPAC message is sent to the SG for IID (1-5). b) Send an ASPAC ACK (IID 1-5)and Notify (AS-Active)from peer(SG) to ASP. Verify that state of ASP1(in AS1) is moved to ASP-ACTIVE. c) Invoke an M-ASP-ACTIVE request from LM of ASP2 (for say IID 16). Verify that an ASPAC message is sent to the peer(SG) for IID 16. d) Send an ASPAC ACK (IID 15-20) and Notify (AS-Active)from peer to ASP side. ASPAC ACK may contain tag 0x8 for specifying the ranges. Verify that ASP2 state is moved to ASP-ACTIVE. e) Invoke the primitive for Unit Data Request Message from SU of ASP1. Verify that a Unit Data Request Message is sent to the peer. f) Send Unit Data Indication Message from peer to ASP1 for say IID 4. Verify that the corresponding indication is given to SU. Vikas & Gayatri [Page 13] Internet Draft IUA Conformance Test Plan Dec 2002 g) Invoke the primitive for Unit Data Request Message from SU of ASP2. Verify that a Unit Data Request Message is sent to the peer. h) Send Unit Data Indication Message from peer to ASP2 for say IID 16. Verify that the corresponding indication is given to SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-ACTIVE----> Request ----------------ASPAC-------------> <---------------ASPAC-ACK---------- <------M-ASP-ACTIVE----- confirm ASP1 state is ASP-ACTIVE <-------NOTIFY (AS-Active)------- --------M-ASP-ACTIVE----> Request ----------------ASPAC-------------> <---------------ASPAC-ACK---------- <-------M-ASP-ACTIVE------- confirm ASP2 state is ASP-ACTIVE <-------NOTIFY (AS-Active)------- -------Unit Data Request-----------> <---Unit Data Indication (IID 4)---- -------Unit Data Request-----------> <---Unit Data Indication (IID 16)--- -------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.5 ASPM_V_ASP_05 : ASPUP Procedures when two ASP's are in one AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check the ASPUP procedures when two ASP's are in one AS. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- E Vikas & Gayatri [Page 14] Internet Draft IUA Conformance Test Plan Dec 2002 (AS can have text or integer based identifiers) ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-UP request from LM for ASP1. Verify that an ASPUP message is sent to the peer(SG). b) Send an ASPUP ACK and Notify (AS-Inactive) messages from peer to ASP side. Verify that the state of ASP1 is now ASP-INACTIVE. c) Invoke an M-ASP-UP request from LM for ASP2. Verify that an ASPUP message is sent to the peer. d) Send an ASPUP ACK from peer in response. Verify that the State of ASP2 is now ASP-INACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-UP--------> Request (ASP1) ---------------ASPUP-------------> <--------------ASPUP-ACK--------- <-------M-ASP-UP--------- confirm (ASP1) ASP1 state is now ASP-INACTIVE <----------NOTIFY (AS-Inactive)--- --------M-ASP-UP--------> Request (ASP2) ---------------ASPUP-------------> <--------------ASPUP-ACK---------- <-------M-ASP-UP--------- confirm (ASP2) ASP2 state is now ASP-INACTIVE -------------------------------------------------------------- Vikas & Gayatri [Page 15] Internet Draft IUA Conformance Test Plan Dec 2002 -------------------------------------------------------------- 3.1.1.6 ASPM_V_ASP_06 : ASPAC Procedures when two ASP's are in one AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check the ASPAC procedures when two ASP's are in one AS. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- E (AS can have text or integer based identifiers) AS is in Override mode. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-INACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-ACTIVE request from LM for ASP1. Verify that an ASPAC message is sent to the SG. b) Send an ASPAC ACK to ASP1 and two Notify (AS-Active) messages one each to ASP1 and ASP2 from peer. Verify that state of ASP1 is now ASP-ACTIVE. c) Send a Unit Data Request Message from ASP1 to the peer by invoking the Unitdata Request primitive from SU. d) Send Unit Data Indication Message from peer to ASP1. Verify that the corresponding indication is given to SU. e) Invoke an M-ASP-ACTIVE request from LM for ASP2. Verify that an ASPAC message is sent to the peer. f) Send an ASPAC ACK from peer to ASP2 in response. Verify that ASP2 is moved to ASP-ACTIVE state. g) Send a Notify(Alternate ASP Active) from peer to ASP1. ASP1 should be moved to ASP-INACTIVE state. h) Send a Unit Data Request Message from ASP2 to the peer by invoking the Unitdata Request primitive from SU. i) Send Unit Data Indication Message from peer to ASP2. Verify that the corresponding indication is given to SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-ACTIVE----> Request (ASP1) Vikas & Gayatri [Page 16] Internet Draft IUA Conformance Test Plan Dec 2002 ---------------ASP ACTIVE-------------> <--------------ASP ACTIVE-ACK--------- <-------M-ASP-ACTIVE---- confirm (ASP1) ASP1 state is now ASP-ACTIVE <----------NOTIFY (AS-Active)--- to ASP1 <----------NOTIFY (AS-Active)--- to ASP2 -------Unit Data Request-----------> <------Unit Data Indication--------- --------M-ASP-ACTIVE---> Request (ASP2) ---------------ASP ACTIVE-----------> <--------------ASP ACTIVE-ACK---------- <-------M-ASP-ACTIVE---- confirm (ASP2) ASP2 state is now ASP-ACTIVE <-----NOTIFY (Alternate ASP Active)---- ASP1 state is now ASP-INACTIVE -------Unit Data Request-----------> <------Unit Data Indication--------- -------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.7 ASPM_V_ASP_07 : ASPAC Procedures when one ASP is in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check the ASPAC procedures when one ASP is in two AS. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- F AS1 and AS2 can serve traffic for either integer or text based identifiers. --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1 is in ASP-INACTIVE state. ASP2 is in ASP-DOWN state. --------------------------------------------------------------- Test Description : a) Invoke an M-ASP-ACTIVE request from LM for ASP1 (in AS1). Verify that an ASPAC message is sent to the peer. Vikas & Gayatri [Page 17] Internet Draft IUA Conformance Test Plan Dec 2002 b) Send an ASPAC ACK from peer(SG) to ASP1. Also Send a Notify (AS-Active) message from peer to ASP1. Verify that the State of ASP1 in AS1 is now marked ASP-ACTIVE. c) Send a Unit Data Request Message from ASP1 to the peer by invoking the Unitdata Request primitive from SU. d) Send a Unit Data Indication message from peer to ASP1 for AS1. Verify that the corresponding indication is given to SU. e) Invoke an M-ASP-ACTIVE request from LM for ASP1 (in AS2). Verify that an ASPAC message is sent to the peer. f) Send an ASPAC ACK from peer to ASP1. Send a Notify (AS-Active) message from peer to ASP1. State of ASP1 in AS2 is now marked ASP-ACTIVE. g) Send a Unit Data Request Message from ASP1 to peer by invoking the Unitdata Request primitive from SU. h) Send Unit Data Indication Message from peer to ASP1 for AS2. Verify that corresponding indication is invoked at SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-ACTIVE-----> Request (ASP1) ---------------ASPAC--------------> <-------------ASPAC-ACK ----------- <------M-ASP-ACTIVE----- Confirm (ASP1) ASP1 state is now ASP-ACTIVE in AS1 <-----------NOTIFY (AS-ACTIVE)----- -------Unit Data Request---------> <-------Unit Data Indication------ -------M-ASP-ACTIVE-----> Request (ASP1) --------------ASPAC -------------> <-----------ASPAC-ACK ------------ <------M-ASP-ACTIVE----- Confirm (ASP1) ASP1 is now ASP-ACTIVE in AS2 <-----------NOTIFY (AS-Active)----- ------------Unit Data Request----> <-------Unit Data Indication----- -------------------------------------------------------------- Vikas & Gayatri [Page 18] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.1.1.8 ASPM_V_ASP_08 : Heartbeat Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that if the IUA stack receives a heartbeat message, it responds with an Heartbeat Ack. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10 --------------------------------------------------------------- Test Configuration :- D --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Heartbeat message containing some heartbeat data received from peer(SG). b) Verify that IUA stack sends a Heartbeat Ack (with the same heartbeat Data) to the peer stack (SG). The IUA stack MUST acknowledge the Heartbeat message with an Heartbeat Ack even if it doesn't support Heartbeat generation. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) <--------------Heartbeat----------- --------------Heartbeat Ack--------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.9 ASPM_V_ASP_09 : Heartbeat Message Generation --------------------------------------------------------------- Test Objective: The main aim of this case is to check the heartbeat message generation if an implementation generates it. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10 --------------------------------------------------------------- Test Configuration :- D --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state. --------------------------------------------------------------- Vikas & Gayatri [Page 19] Internet Draft IUA Conformance Test Plan Dec 2002 Test Description : a) Verify that Heartbeat message is sent periodically to the peer. b) Send Heartbeat Ack to the IUT. Verify that Heartbeat timer is started again. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------------Heartbeat------------> <--------------Heartbeat Ack-------- --------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.10 ASPM_V_ASP_10 : Text Based Interface identifiers in AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check data transfer when AS is having text based interface identifiers. This case is valid for the implementations that support text based interface identifiers. ---------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.5 --------------------------------------------------------------- Test Configuration :- D AS1 is handling traffic for two text based interface identifiers say "smile" and "john". ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer(SG). ASP1 is in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Invoke an M-ASP-ACTIVE request from LM for ASP1. b) Verify that an ASPAC message is sent to the SG for both IID's(smile and john). c) Send an ASPAC ACK and Notify (AS-Active)from peer in response. Verify that ASP and AS states are moved to ASP-ACTIVE/AS-ACTIVE. d) Send a Unit Data Request Message from ASP to peer by invoking the Unit Data Request primitive from SU. e) Send a Unit Data Indication Message from peer to ASP. Verify that corresponding indication primitive is given to SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) Vikas & Gayatri [Page 20] Internet Draft IUA Conformance Test Plan Dec 2002 -------M-ASP-ACTIVE-----> Request --------ASPAC (smile and john)------> <-------------ASPAC-ACK ------------- <------M-ASP-ACTIVE----- Confirm AS1/ASP1 state is now AS-ACTIVE/ASP-INACTIVE <----------NOTIFY (AS-Active)-------- --------------Unit Data Request-----> <-----------Unit Data Indication----- --------------------------------------------------------------- --------------------------------------------------------------- 3.1.1.11 ASPM_V_ASP_11 : Routing Verification when Two ASP's are in two different AS(Text+Integer) --------------------------------------------------------------- Test Objective: The main aim of this case is to check data transfer when one AS has integer based interface identifier and other text based interface identifier. This case is valid for the implementations that support both text and integer based interface identifiers. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.5 --------------------------------------------------------------- Test Configuration :- F AS1 serves traffic for integer based identifier say 1. AS2 serves traffic for text based identifier say john. --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and peer(SG). ASP1, ASP2 are in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Invoke an M-ASP-ACTIVE request from LM for ASP2. Verify that an ASPAC message is sent to the SG. b) Send an ASPAC ACK from peer to ASP2. Verify that state of ASP2 in AS2 is now marked ASP-ACTIVE. Also send Notify (AS-Active) message to ASP2. c) Invoke an M-ASP-ACTIVE request from LM for ASP1 in AS1. Verify that an ASPAC message is sent to the SG. d) Send an ASPAC ACK from peer to ASP1. Verify that state of ASP1 in AS1 is now marked ASP-ACTIVE. Also send a Notify (AS-Active) message from peer to ASP1. e) Send a Unit Data Request Message from ASP1 to peer by invoking the Unit Data Request primitive from SU. Vikas & Gayatri [Page 21] Internet Draft IUA Conformance Test Plan Dec 2002 f) Send Unit Data Indication Message from peer for ASP1. Verify that corresponding indication primitive is given to SU. g) Send a Unit Data Request Message from ASP2 to peer by invoking the Unit Data Request primitive from SU. h) Send Unit Data Indication Message from peer for ASP2. Verify that corresponding indication primitive is given to SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-ACTIVE-----> Request (ASP2) ----------ASPAC (IID john)---------> <-------ASPAC-ACK (IID john)------- <------M-ASP-ACTIVE----- Confirm (ASP2) ASP2 is now ASP-ACTIVE in AS2 <--------NOTIFY(AS-Active)--------- -------M-ASP-ACTIVE-----> Request (ASP1) ------------ASPAC (IID 1)----------> <---------ASPAC-ACK (IID 1)-------- <------M-ASP-ACTIVE----- Confirm (ASP1) ASP1 is now ASP-ACTIVE in AS1 <--------NOTIFY(AS-Active)--------- -----------Unit Data Request-------> <-------Unit Data Indication-------- -----------Unit Data Request-------> <-------Unit Data Indication-------- --------------------------------------------------------------- 3.1.2 Invalid ASPM cases when ASP is Under Test --------------------------------------------------------------- 3.1.2.1 ASPM_I_ASP_01 : ASPM Message received in wrong state of ASP --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle an ASPM message when received in wrong state of the ASP. Vikas & Gayatri [Page 22] Internet Draft IUA Conformance Test Plan Dec 2002 ---------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.14, 3.16 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-ACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPIA ACK message from peer to ASP1. Verify that ASP state is moved to ASP-INACTIVE. b) Send a ASPDN ACK message from peer to ASP1. Verify that ASP state is moved to ASP-DOWN. c) Invoke an M-ASPUP request from LM(ASP1). Verify that an ASPUP message reaches the peer. d) Send a ASPUP ACK message from peer to ASP1. Verify that state of ASP is moved to ASP-INACTIVE. e) Invoke an M-ASP Active request from LM(ASP1). Verify that an ASPAC message reaches the peer. f) Send a ASPAC ACK message from peer to ASP1. Verify that state of ASP is moved to ASP-ACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) <-------------ASPIA-ACK------------ ASP state moved to ASP-INACTIVE <-------------ASPDN ACK------------ ASP state moved to ASP-DOWN --------M-ASP-UP----------> Request ---------------ASPUP--------------> <--------------ASPUP-ACK----------- <-------M-ASP-UP--------- confirm ASP state is now ASP-INACTIVE <---------NOTIFY(AS-Inactive)------ -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPAC-ACK----------- Vikas & Gayatri [Page 23] Internet Draft IUA Conformance Test Plan Dec 2002 <------M-ASP-ACTIVE----- Confirm ASP state is now ASP-ACTIVE <---------NOTIFY(AS-Active)------ --------------------------------------------------------------- --------------------------------------------------------------- 3.1.2.2 ASPM_I_ASP_02 : ASPDN ACK in Active state of ASP --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle ASPDN ACK in Active state of ASP. ---------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.14 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-ACTIVE state. --------------------------------------------------------------- Test Description : a) Send a ASPDN ACK message from peer to ASP1. b) Verify that ASP state is moved to ASP-DOWN. c) Invoke an M-ASPUP request from LM(ASP1). Verify that an ASPUP message reaches the peer. d) Send a ASPUP ACK message from peer to ASP1. Verify that state of ASP is moved to ASP-INACTIVE. e) Invoke an M-ASP Active request from LM(ASP1). Verify that an ASPAC message reaches the peer. f) Send a ASPAC ACK message from peer to ASP1. Verify that state of ASP is moved to ASP-ACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) <-------------ASPDN ACK------------ ASP state moved to ASP-DOWN --------M-ASP-UP----------> Request ---------------ASPUP--------------> <--------------ASPUP-ACK----------- Vikas & Gayatri [Page 24] Internet Draft IUA Conformance Test Plan Dec 2002 <-------M-ASP-UP--------- confirm ASP state is now ASP-INACTIVE <-------NOTIFY(AS-INACTIVE)-------- -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPAC-ACK----------- <------M-ASP-ACTIVE----- Confirm ASP state is now ASP-ACTIVE <-------NOTIFY(AS-ACTIVE)-------- --------------------------------------------------------------- --------------------------------------------------------------- 3.1.2.3 ASPM_I_ASP_03 : ASPSM Timer expiry Cases --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle ASPSM timer expiry procedures. ---------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.13, 3.14 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-DOWN state. --------------------------------------------------------------- Test Description : a) Invoke an M-ASPUP request from LM(ASP1). Verify that an ASPUP message reaches the peer. b) Don't send any response(ASPUP-ACK) message from peer. Verify that after max retransmissions, the ASP remains in ASP-DOWN state and a negative indication is given to LM. c) Again ,invoke an M-ASPUP request from LM(ASP1). Verify that an ASPUP message reaches the peer. d) Send ASP-UP-ACK and Notify (AS-Inactive) from peer. Verify that the state of the ASP moves from ASP-DOWN to ASP-INACTIVE. e) Invoke an M-ASP Down request from LM(ASP1). Verify that an ASPDN message reaches the peer. f) Don't send any response(ASPDN-ACK) message from peer. Verify that after max retransmissions, the ASP is brought to Vikas & Gayatri [Page 25] Internet Draft IUA Conformance Test Plan Dec 2002 ASP-DOWN state and a negative indication is given to LM. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-UP-----> Request --------------ASPUP---------------> --------------ASPUP---------------> --------------ASPUP---------------> --------------ASPUP---------------> --------------ASPUP---------------> After Max(say 4) retransmissions, ASP remains in ASP-DOWN state LM again invokes M-ASPUP request -------M-ASP-UP-----> Request --------------ASPUP---------------> <-------------------------------- ASP-UP ACK <-------------------------------- Notify (AS-INACTIVE) ASP1 is in ASP-INACTIVE state -------M-ASP-DOWN-----> Request --------------ASPDN---------------> --------------ASPDN---------------> --------------ASPDN---------------> --------------ASPDN---------------> --------------ASPDN---------------> After Max(say 4) retransmissions, ASP is brought to ASP-DOWN state --------------------------------------------------------------- --------------------------------------------------------------- 3.1.2.4 ASPM_I_ASP_04 : ASPTM Timer expiry Cases --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle ASPTM(ASPAC, ASPIA) timer expiry procedures. ---------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.15, 3.16 --------------------------------------------------------------- Vikas & Gayatri [Page 26] Internet Draft IUA Conformance Test Plan Dec 2002 Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-INACTIVE state. --------------------------------------------------------------- a) Invoke an M-ASP Active request from LM(ASP1). Verify that an ASPAC message reaches the peer. b) Don't send any response(ASPAC-ACK) message from peer. Verify that after max retransmissions, the ASP remains in ASP-INACTIVE state and a negative indication is given to LM. c) Invoke an M-ASP Active request from LM(ASP1). Verify that an ASPAC message reaches the peer. d) Send ASP-ACTIVE-ACK and Notify (AS-active) from peer. Verify that state of an ASP moves from ASP-INACTIVE to ASP-ACTIVE. e) Invoke an M-ASP Inactive request from LM(ASP1). Verify that an ASPIA message reaches the peer. f) Don't send any response(ASPIA-ACK) message from peer. Verify that after max retransmissions, the ASP is brought to ASP-INACTIVE state and a negative indication is given to LM. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> --------------ASPAC---------------> --------------ASPAC---------------> --------------ASPAC---------------> --------------ASPAC---------------> After Max retransmissions, ASP remains in ASP-INACTIVE state LM again invokes M-ASP-ACTIVE request -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------------------------- ASP-ACTIVE ACK <-------------------------------- Notify (AS-ACTIVE) -------M-ASP-INACTIVE-----> Request --------------ASPIA---------------> Vikas & Gayatri [Page 27] Internet Draft IUA Conformance Test Plan Dec 2002 --------------ASPIA---------------> --------------ASPIA---------------> --------------ASPIA---------------> --------------ASPIA---------------> After Max retransmissions, ASP brought to ASP-INACTIVE state --------------------------------------------------------------- --------------------------------------------------------------- 3.1.2.5 ASPM_I_ASP_05 : ASPIA ACK in response to ASPAC --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that ASPAC retransmissions if ASPIA ACK is received in response to ASPAC. ---------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.8 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Invoke an M-ASP Active request from LM(ASP1). Verify that an ASPAC message reaches the peer. b) Send ASPIA-ACK message from peer. Verify that ASP remains in ASP-INACTIVE state. ASPAC retransmissions may continue or are stopped. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) -------M-ASP-ACTIVE-----> Request --------------ASPAC---------------> <-------------ASPIA-ACK------------ ASPAC retransmissions may continue or stopped ASP state remains in ASP-INACTIVE --------------------------------------------------------------- Vikas & Gayatri [Page 28] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.1.2.6 ASPM_I_ASP_06 : Association re-establishment in case of Heartbeat timer expiry --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Association re-establishment procedures if no Heartbeat Ack is received. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10 --------------------------------------------------------------- Test Configuration :- D --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Verify that Heartbeat message is sent periodically to the peer. b) Verify that if no Heartbeat Ack is received from the peer within 2*T heartbeat timer interval, the SCTP association is disconnected and re-establishment is tried if signaling process is configured as client. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------------Heartbeat-----------> No HeartbeatAck received within 2*T heartbeat interval. Association disconnected and re-establishment tried. --------------------------------------------------------------- 3.1.3 Valid ASPM cases when SG is Under Test --------------------------------------------------------------- 3.1.3.1 ASPM_V_SG_01 : AS Inactive/Active State Transition in single ASP-SG scenario. --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify the ASP Up and Active Procedures at SG end in single ASP-SG scenario. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between Vikas & Gayatri [Page 29] Internet Draft IUA Conformance Test Plan Dec 2002 peer(ASP1) and SG. --------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG. b) Verify that the SG sends an ASPUP ACK and Notify (AS-INACTIVE) to ASP1. Verify that the ASP and AS states are moved to ASP-INACTIVE/ AS-INACTIVE. c) Send an ASPAC message from the peer to SG. d) Verify that the SG sends an ASPAC-ACK and NOTIFY (AS-ACTIVE) message to the peer. Verify that the ASP and AS states are moved to ASP-ACTIVE/ AS-ACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> ----------NOTIFY (AS-INACTIVE)-----> ASP and AS state moved to ASP-INACTIVE/AS-INACTIVE <---------------ASPAC------------- --------------ASPAC-ACK-----------> ----------NOTIFY (AS-ACTIVE)-----> ASP and AS state moved to ASP-ACTIVE/AS-ACTIVE --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.2 ASPM_V_SG_02 : AS Inactive and Down State Transition, in single ASP-SG scenario. --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify the ASP Inactive and Down Procedures at SG end, in single ASP-SG scenario. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1/AS are in ASP-ACTIVE/AS-ACTIVE state respectively. --------------------------------------------------------------- Vikas & Gayatri [Page 30] Internet Draft IUA Conformance Test Plan Dec 2002 Test Description : a) Send an ASPIA message from peer to SG. b) Verify that SG sends an ASPIA ACK and Notify (AS-Pending) to the peer. Verify that the ASP state is moved to ASP-INACTIVE and AS state is moved to AS-PENDING. c) Allow the pending timer to expire. Verify that after pending timer expiry, SG sends a NOTIFY(AS-Inactive) to the peer. Also verify that AS state is now moved to AS-INACTIVE state. d) Send an ASPDN message from peer to SG. Verify that SG sends ASPDN-ACK to the peer. e) Verify that ASP and AS state is moved to ASP-DOWN/AS-DOWN. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPIA-------------- ----------------ASPIA-ACK-----------> ------------NOTIFY(AS-PENDING)------> ASP state moves to ASP-INACTIVE AS state moves to AS-PENDING Pending timer Expires ------NOTIFY(AS-INACTIVE)----------> <--------------ASPDN--------------- -------------ASPDN-ACK------------ ASP and AS state moved to ASP-DOWN/AS-DOWN --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.3 ASPM_V_SG_03 : Handling of the AS State Transition from Active to DOWN, in single ASP-SG scenario. --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify the ASP Down Procedures at SG end in single ASP-SG scenario, when the ASP is in active state. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 Vikas & Gayatri [Page 31] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP and AS state are in ASP-ACTIVE and AS-ACTIVE state respectively. --------------------------------------------------------------- Test Description : a) Send an ASPDN message from peer to SG. b) Verify that the SG sends an ASPDN ACK to the peer. Verify that the ASP state moves to ASP-DOWN and AS state moves to AS-PENDING. c) Allow the pending timer to expire. Verify that after pending timer expiry, AS state moves to AS-DOWN. d) Verify that SG does not send any Notify message to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPDN-------------- ----------------ASPDN-ACK-----------> ASP state moves to ASP-DOWN AS state moves to AS-PENDING Pending timer Expires AS state moves to AS-DOWN --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.4 ASPM_V_SG_04 : ASPUP procedures when one ASP is in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the ASPUP procedures when one ASP is in two AS. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- C AS1 and AS2 can serve traffic for either integer or text based identifiers. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1, ASP2 are in ASP-DOWN state. Vikas & Gayatri [Page 32] Internet Draft IUA Conformance Test Plan Dec 2002 AS1 and AS2 are in AS-DOWN state. --------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG. b) Verify that SG sends an ASPUP ACK and two Notify (AS-Inactive) in response, corresponding to AS1 and AS2. Verify that state of ASP1 in AS1 and AS2 is now ASP-INACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP-------------- ----------------ASPUP-ACK-----------> ----------NOTIFY (AS-Inactive)------> ----------NOTIFY (AS-Inactive)------> ASP1 is now ASP-INACTIVE in both AS1 and AS2 --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.5 ASPM_V_SG_05 : ASPAC procedures when one ASP is in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the ASPAC procedures when one ASP is in two AS. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- C AS1 and AS2 can serve traffic for either integer or text based identifiers. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1, ASP2 are in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer to the SG for AS1. b) Verify that SG sends an ASPAC ACK and Notify (AS-Active) message to ASP1 in response. Verify that state of ASP1 in AS1 is now marked ASP-ACTIVE. c) Send a Unit Data Request Message from peer(ASP1) to SG. Verify that the corresponding indication is invoked at NIF. d) Invoke the primitive for Unit Data Indication Message from Vikas & Gayatri [Page 33] Internet Draft IUA Conformance Test Plan Dec 2002 NIF for AS1. Message should be sent to ASP1. e) Send an ASPAC message from peer to the SG for AS2. f) Verify that SG sends an ASPAC ACK and Notify (AS-Active) message to ASP1 in response. Verify that State of ASP1 in AS2 is now marked ASP-ACTIVE. g) Send a Unit Data Request Message from ASP1 to SG. Verify that the corresponding indication is invoked at NIF. h) Invoke the primitive for Unit Data Indication Message from NIF for AS2. Message should be sent to ASP1. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPAC-------------- ----------------ASPAC-ACK-----------> ----------NOTIFY (AS-Active)--------> AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE <-------Unit Data Request--------- -------Unit Data Indication------> <----------------ASPAC-------------- ----------------ASPAC-ACK-----------> ----------NOTIFY (AS-Active)------> ASP1 is now ASP-ACTIVE in AS2 <-------Unit Data Request--------- -------Unit Data Indication------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.6 ASPM_V_SG_06 : ASPUP procedures when two ASP's are in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check ASPUP procedures when two ASP's are in two AS. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 Vikas & Gayatri [Page 34] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Test Configuration :- C AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling traffic for IID range 15-20. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state. AS1 and AS2 are in AS-DOWN state. --------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer(ASP1) to the SG. b) Verify that SG sends an ASPUP ACK and two Notify (AS-Inactive) in response, corresponding to AS1 and AS2. Verify that ASP1, AS1 and AS2 states are moved to ASP-INACTIVE/AS-INACTIVE. c) Send an ASPUP message from peer(ASP2) to the SG. d) Verify that SG sends an ASPUP ACK in response. Verify that no Notify message is sent by SG. Verify that ASP2 state is moved to ASP-INACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------------ASPUP----------- --------------ASPUP-ACK---------> ------NOTIFY (AS-Inactive, AS1)--> ------NOTIFY (AS-Inactive, AS2)--> AS1/AS2/ASP1 state is now AS-INACTIVE/ASP-INACTIVE <---------------ASPUP----------- --------------ASPUP-ACK---------> ASP2 state is now ASP-INACTIVE --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.7 ASPM_V_SG_07 : ASPAC procedures when two ASP's are in two AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check data transfer when AS is having integer based interface identifiers. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Vikas & Gayatri [Page 35] Internet Draft IUA Conformance Test Plan Dec 2002 Test Configuration :- C AS1 at SG is handling traffic for say IID range 1-5, AS2 is handling traffic for IID range 15-20. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1 and ASP2 are in Inactive state. AS1 and AS2 are in AS-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer to the SG for IID (1-5). b) Verify that SG sends an ASPAC ACK (IID 1-5)and Notify (AS-Active)in response. Verify that state of ASP1(in AS1)and AS1 is moved to ASP-ACTIVE/AS-ACTIVE. c) Send an ASPAC message from peer to the SG for IID 16. d) Verify that SG sends an ASPAC ACK (IID 15-20)and Notify (AS-Active)in response. Verify that state of ASP2 and AS2 is moved to ASP-ACTIVE/ AS-ACTIVE. e) Send a Unit Data Request Message from peer(ASP1) to SG. Verify that corresponding indication is given to NIF. f) Invoke the primitive for Unit Data Indication Message from NIF for say IID 4. Message should be sent to ASP1 in AS1. g) Send a Unit Data Request Message from peer(ASP2) to SG. Verify that corresponding indication is given to NIF. h) Invoke the primitive for Unit Data Indication Message from NIF for say IID 16. Message should be sent to ASP2 in AS2. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <-----------ASPAC (IID 1-5)--------- ----------ASPAC-ACK (IID 1-5)-------> ----------NOTIFY(AS-Active)---------> AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE <-----------ASPAC (IID 16)---------- ----------ASPAC-ACK (IID 15-20)-----> ----------NOTIFY(AS-Active)---------> AS2/ASP2 state is now AS-ACTIVE/ASP-ACTIVE Vikas & Gayatri [Page 36] Internet Draft IUA Conformance Test Plan Dec 2002 <------Unit Data Request------------- -----Unit Data Indication (IID 4)---> <------Unit Data Request------------- -----Unit Data Indication (IID 16)--> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.8 ASPM_V_SG_08 : ASPUP procedures when Two ASP's are in one AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check ASPUP procedures when two ASP's are in a single AS. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- B (AS can have text or integer based identifiers) ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between both ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-DOWN state. AS1 is in AS-DOWN state. --------------------------------------------------------------- Test Description : a) Send An ASPUP message from peer(ASP1) to the SG. b) Verify that SG sends an ASPUP ACK and Notify (AS-Inactive) in response. Verify that state of ASP1 and AS1 is now ASP-INACTIVE/ AS-INACTIVE. c) Send an ASPUP message from peer(ASP2) to the SG. d) Verify that SG sends an ASPUP ACK in response. Verify that no Notify message is sent by SG as AS state is already AS-INACTIVE. Verify that state of ASP2 is now ASP-INACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> -----------NOTIFY (AS-Inactive)----> Vikas & Gayatri [Page 37] Internet Draft IUA Conformance Test Plan Dec 2002 AS1/ASP1 state is now AS-INACTIVE/ASP-INACTIVE <---------------ASPUP------------- ---------------ASPUP-ACK----------> ASP2 state is now ASP-INACTIVE --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.9 ASPM_V_SG_09 : ASP ACTIVE procedures when two ASP's are in one AS(Override) --------------------------------------------------------------- Test Objective: The main aim of this case is to check ASPAC procedures when two ASP's are in a single AS in OVERRIDE mode. and also to verify for the generation of Notify (Alternate ASP Active) message. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- B (AS can have text or integer based identifiers) ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between both ASP1,ASP2 and SG. ASP1 and ASP2 are in ASP-INACTIVE state. AS1 is in AS-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer(ASP1) to the SG. b) Verify that SG sends an ASPAC ACK to ASP1. Also verify that SG sends two Notify (AS-Active) messages one each to ASP1 and ASP2 . Verify that ASP1 and AS1 is now moved to ASP-ACTIVE/AS-ACTIVE state. c) Send a Unit Data Request Message from peer(ASP1) to SG. Verify that corresponding indication is given to NIF. d) Invoke primitive for Unit Data Indication Message multiple times from NIF. Verify that messages are sent to ASP1 only. e) Send an ASPAC message from peer(ASP2) to the SG. f) Verify that SG sends an ASPAC ACK to ASP2 in response. Verify that ASP2 is moved to ASP-ACTIVE state. g) Also verify that SG sends a Notify(Alternate ASP Active) to Vikas & Gayatri [Page 38] Internet Draft IUA Conformance Test Plan Dec 2002 peer(ASP1). Verify that ASP1 should be moved to ASP-INACTIVE state. AS1 should remain in AS-ACTIVE state. h) Send a Unit Data Request Message from peer(ASP2) to SG. i) Invoke multiple primitives for Unit Data Indication Message from NIF. Verify that message should be sent to ASP2 only. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------------ASPAC ------------- ------------ASPAC-ACK -------------> ----------NOTIFY (AS-Active)-------> ----------NOTIFY (AS-Active)-------> AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE <-------Unit Data Request----------- --------Unit Data Indication--------> --------Unit Data Indication--------> <---------------ASPAC ------------- ------------ASPAC-ACK -------------> -------NOTIFY (Alt ASP Active)-----> for ASP1 ASP2 state is now ASP-ACTIVE ASP1 state is now ASP-INACTIVE <-------Unit Data Request----------- --------Unit Data Indication--------> (ASP2) --------Unit Data Indication--------> (ASP2) --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.10 ASPM_V_SG_10 : Text Based Interface identifiers in AS --------------------------------------------------------------- Test Objective: The main aim of this case is to check data transfer when AS is having text based interface identifiers. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Vikas & Gayatri [Page 39] Internet Draft IUA Conformance Test Plan Dec 2002 Test Configuration :- A AS1 is handling traffic for two text based interface identifiers say "smile" and "john". ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-INACTIVE state. AS1 is in AS-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer to SG for both IID's(smile and john). b) Verify that SG sends an ASPAC ACK and Notify (AS-Active) in response. Verify that ASP and AS states are moved to ASP-ACTIVE/AS-ACTIVE. c) Send a Unit Data Request Message from peer to SG. Verify that corresponding indication is given to NIF. d) Send a Unit Data Indication Message from SG to Peer by invoking the Unit Data Indication primitive from NIF. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <-------ASPAC (smile and john)----- -------------ASPAC-ACK ------------> ----------NOTIFY (AS-Active)-------> AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE <-------Unit Data Request----------- -------Unit Data Indication--------- --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.11 ASPM_V_SG_11 : Routing Verification when Two ASP's are in two different AS(Text+Integer) --------------------------------------------------------------- Test Objective: The main aim of this case is to check data transfer when one AS has integer based interface identifier and other text based interface identifier. This case is valid for the implementations that support both text and integer based interface identifiers. --------------------------------------------------------------- Vikas & Gayatri [Page 40] Internet Draft IUA Conformance Test Plan Dec 2002 Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- C AS1 serves traffic for integer based identifier say 1. AS2 serves traffic for text based identifier say john. --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. ASP1, ASP2 are in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer(ASP2) to the SG. b) Verify that SG sends an ASPAC ACK to ASP2. Also Verify that SG sends Notify (AS-Active) messages to ASP2 and ASP1. Verify that State of ASP2 in AS2 is now marked ASP-ACTIVE. c) Send an ASPAC message from peer(ASP1) to the SG for AS1. d) Verify that SG sends an ASPAC ACK to ASP1. Also verify that SG sends a Notify (AS-Active) message to ASP1. Verify that the state of ASP1 in AS1 is now marked ASP-ACTIVE. e) Send a Unit Data Request Message from peer(ASP1) to SG. Verify that corresponding indication is given to NIF. f) Invoke the primitive for Unit Data Indication Message from NIF for AS1. Verify that Message reaches the peer (ASP1). g) Send a Unit Data Request Message from ASP2 to SG. Verify that corresponding indication is given to NIF. h) Invoke the primitive for Unit Data Indication Message from NIF for AS2. Verify that Message reaches the peer (ASP2). --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <------------ASPAC (IID john)------ -----------ASPAC-ACK (IID john)----> ----------NOTIFY (AS-Active)-------> ----------NOTIFY (AS-Active)-------> AS2/ASP2 state is now AS-ACTIVE/ASP-ACTIVE <----------ASPAC (IID 1)----------- ----------ASPAC-ACK (IID 1)--------> ---------NOTIFY (AS-Active)--------> Vikas & Gayatri [Page 41] Internet Draft IUA Conformance Test Plan Dec 2002 ASP1 is now ASP-ACTIVE in AS1 <----------Unit Data Request-------- -------Unit Data Indication-------> <----------Unit Data Request-------- -------Unit Data Indication-------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.12 ASPM_V_SG_12 : Loadshare procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the loadshare procedures --------------------------------------------------------------- Test Configuration :- B --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.5 --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. AS is in Loadshare mode. ASP1 and ASP2 are in ASP-ACTIVE state. Minimum two ASP's are required to handle traffic. --------------------------------------------------------------- Test Description : a) Invoke Unit Data Indication Primitive multiple times from NIF. b) Multiple Unit Data indication messages are sent from SG to peer. These Messages are sent to ASP1 or ASP2 depending on the Loadshare algorithm. For example if the Loadshare Algorithm is Round-Robin, the data may be sent first to peer(ASP1) and then to peer(ASP2) in a round-robin fashion. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <-------Unit Data Request---------- -----Unit Data Indication (ASP1)---> -----Unit Data Indication (ASP2)---> --------------------------------------------------------------- Vikas & Gayatri [Page 42] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.1.3.13 ASPM_V_SG_13 : Notify-Insufficient Resources --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the generation of Notify - Insufficient Resources message. --------------------------------------------------------------- Test Configuration :- B --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.2 --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. AS is in Loadshare mode. ASP1 and ASP2 are in ASP-ACTIVE state. Minimum two ASP's are required to handle traffic. --------------------------------------------------------------- Test Description : a) Send an ASPIA message from peer(ASP1) to the SG. Verify that SG sends an ASPIA ACK and Notify (Insufficient resources) to ASP1 in response. Verify that ASP1 state is moved to ASP-INACTIVE. b) Invoke Unit Data Indication Primitive multiple times from NIF. Verify that Multiple Unit Data indication messages are sent from SG to the peer. These Messages are sent to ASP2 only. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <-----------------ASPIA------------- ---------------ASPIA-ACK------------> ----Notify(Insufficient Resources)--> ASP1 state is ASP-INACTIVE -----Unit Data Indication (ASP2)---> -----Unit Data Indication (ASP2)---> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.14 ASPM_V_SG_14 : AS-Active again before pending timer expires --------------------------------------------------------------- Vikas & Gayatri [Page 43] Internet Draft IUA Conformance Test Plan Dec 2002 Test Objective: The main aim of this scenario is to check that if an ASP becomes Active before pending timer expiry, the AS state is moved to AS-ACTIVE. Also all the buffered Data should be routed to that ASP (Implementation Dependent). ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP association is established between ASP and SG. ASP and AS is in ASP-ACTIVE/AS-ACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPIA message from peer to the SG. b) Verify that SG sends an ASPIA ACK and Notify (AS-Pending) in response. c) Verify that a pending timer is started at SG. Also verify that AS state is moved to AS-PENDING and ASP state is moved to ASP-INACTIVE. d) Try sending multiple data indication messages from SG. Verify that all the data should get buffered. e) Send an ASPAC message from peer to the SG before the pending timer expiry. f) Verify that SG sends an ASPAC ACK and Notify (AS-Active) in response. Verify that all the buffered data is sent to the ASP. -------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------------ASPIA-------------- --------------ASPIA-ACK------------> ------------NOTIFY (AS-Pending)----> AS state is AS-PENDING and ASP state is ASP-INACTIVE Data Indication primitive invoked from NIF and Data buffered Before Pending timer expiry, <------------------ASPAC----------- -----------------ASPAC-ACK---------> ----------NOTIFY(AS-Active)--------> Vikas & Gayatri [Page 44] Internet Draft IUA Conformance Test Plan Dec 2002 Buffered messages sent to peer ---------Unit Data Indication------> ---------Unit Data Indication------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.15 ASPM_V_SG_15 : Heartbeat Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that if the IUA stack receives a heartbeat message, it responds with an Heartbeat Ack. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.9, 3.3.2.10 --------------------------------------------------------------- Test Configuration :- A --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 can be in ASP-ACTIVE/ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send Heartbeat message containing some heartbeat data from the peer stack. b) Verify that Stack(SG) sends Heartbeat Ack to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <--------------Heartbeat----------- --------------Heartbeat Ack--------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.16 ASPM_V_SG_16 : Optional parameter handling --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that IUA stack is able to handle an IUA message with any optional parameter. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.2, 3.3.2.5 --------------------------------------------------------------- Test Configuration :- A Vikas & Gayatri [Page 45] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-DOWN state. --------------------------------------------------------------- Test Description : a) Send ASPUP message with info string from the peer. b) Verify that the SG sends an ASPUP ACK and Notify(AS-Inactive) message to the peer. c) Send an ASPAC message from peer with info string and interface identifier parameter. d) Verify that SG sends an ASPAC ACK and Notify(AS-ACTIVE) message to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> ----------NOTIFY (AS-INACTIVE)-----> ASP and AS state moved to ASP-INACTIVE/AS-INACTIVE <---------------ASPAC------------- --------------ASPAC-ACK-----------> ----------NOTIFY (AS-ACTIVE)-----> ASP and AS state moved to ASP-ACTIVE/AS-ACTIVE --------------------------------------------------------------- --------------------------------------------------------------- 3.1.3.17 ASPM_V_SG_17 : ASPAC/ASPIA message handling when it contains no interface identifier --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the ASPAC/ASPIA message handling when it contains no interface identifier. ---------------------------------------------------------------- Reference : RFC 3057, Section 3.3.2.5, 3.3.2.6, 3.3.2.7, 3.3.2.8 --------------------------------------------------------------- Test Configuration :- C AS1 and AS2 can serve traffic for either integer or text based Vikas & Gayatri [Page 46] Internet Draft IUA Conformance Test Plan Dec 2002 identifiers. ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-INACTIVE state in both AS1 and AS2. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer to SG without any interface identifier. b) Verify that SG sends an ASPAC ACK and two Notify (AS-Active) in response, corresponding to AS1 and AS2. Verify that state of ASP1 in AS1 and AS2 is now ASP-ACTIVE. c) Verify that it is possible to send data for all interface Integers. d) Send an ASPIA message from peer to SG without any interface identifier. e) Verify that SG sends an ASPIA ACK and two Notify (AS-Pending) in response, corresponding to AS1 and AS2. Verify that state of ASP1 in AS1 and AS2 is now ASP-INACTIVE. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPAC-------------- (Without Interface Identifier) ----------------ASPAC-ACK-----------> (for both the AS) ----------NOTIFY (AS-Active)--------> (for AS1) ----------NOTIFY (AS-Active)--------> (for AS2) ASP1 is now ASP-ACTIVE in both AS1 and AS2 Data exchange for both all IID's <----------------ASPIA-------------- (Without Interface Identifier) ----------------ASPIA-ACK-----------> (for both the AS) ----------NOTIFY (AS-Pending)------> (for AS1) ----------NOTIFY (AS-Pending)------> (for AS2) ASP1 is now ASP-INACTIVE in both AS1 and AS2 --------------------------------------------------------------- Vikas & Gayatri [Page 47] Internet Draft IUA Conformance Test Plan Dec 2002 3.1.4 Invalid ASPM cases when SG is Under Test --------------------------------------------------------------- 3.1.4.1 ASPM_I_SG_01 : Retransmitted ASPSM Messages received --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle a retransmitted ASPSM (ASPUP/ASPDN) message. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-DOWN state. --------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG. b) Verify that the SG sends an ASPUP ACK and Notify (AS-INACTIVE) to the peer(ASP1). Verify that the ASP and AS states are moved to ASP-INACTIVE/ AS-INACTIVE. c) Again send an ASPUP message from peer to SG. d) Verify that the SG sends an ASPUP ACK to the peer(ASP1). e) Send an ASPDN message from the peer to SG. f) Verify that the SG sends an ASPDN-ACK message to the peer. Verify that the ASP and AS states are moved to ASP-DOWN/AS-DOWN. g) Again send an ASPDN message from peer to SG. h) Verify that the SG sends an ASPDN ACK to the peer(ASP1). --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> ----------NOTIFY (AS-INACTIVE)-----> ASP and AS state move to ASP-INACTIVE/AS-INACTIVE Vikas & Gayatri [Page 48] Internet Draft IUA Conformance Test Plan Dec 2002 <----------------ASPUP------------- ---------------ASPUP-ACK-----------> <----------------ASPDN------------- ---------------ASPDN-ACK-----------> ASP and AS state move to ASP-DOWN/AS-DOWN <----------------ASPDN------------- ---------------ASPDN-ACK-----------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.4.2 ASPM_I_SG_02 : Retransmitted ASPTM Message received --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle a retransmitted ASPTM (ASPAC/ASPIA) message. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from the peer to SG. b) Verify that the SG sends an ASPAC-ACK and NOTIFY (AS-ACTIVE) message to the peer. Verify that the ASP and AS states are moved to ASP-ACTIVE/ AS-ACTIVE. c) Again, send an ASPAC message from the peer to SG. d) Verify that the SG sends an ASPAC-ACK message to the peer. e) Send an ASPIA message from the peer to SG. f) Verify that the SG sends an ASPIA ACK and NOTIFY (AS-PENDING) message to the peer. g) Verify that after pending timer expiry, SG sends a Notify(AS-INACTIVE) message to the peer. Verify that the ASP and AS states are moved to ASP-INACTIVE/ AS-INACTIVE. Vikas & Gayatri [Page 49] Internet Draft IUA Conformance Test Plan Dec 2002 h) Again, send an ASPIA message from the peer to SG. i) Verify that the SG sends an ASPIA-ACK message to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------------ASPAC------------- --------------ASPAC-ACK-----------> ----------NOTIFY (AS-ACTIVE)-----> ASP and AS state move to ASP-ACTIVE/AS-ACTIVE <---------------ASPAC------------- --------------ASPAC-ACK-----------> <---------------ASPIA------------- --------------ASPIA-ACK-----------> ----------NOTIFY (AS-PENDING)-----> Pending timer starts Pending timer expires ----------NOTIFY (AS-INACTIVE)----> ASP and AS state move to ASP-INACTIVE/AS-INACTIVE <---------------ASPIA------------- --------------ASPIA-ACK-----------> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.4.3 ASPM_I_SG_03 : ASPUP message handling in ACTIVE state of ASP --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle ASPUP in ACTIVE state of ASP. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- C ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1,ASP2 and SG. ASP1 is in ASP-ACTIVE state in both AS1 and AS2. --------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 50] Internet Draft IUA Conformance Test Plan Dec 2002 a) Send an ASPUP message from peer to SG. b) Verify that the SG sends an ASPUP ACK and an Error(Unexpected message) to the peer(ASP1). c) Verify that the state of ASP1 is moved to ASP-INACTIVE in both AS1 and AS2. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPUP------------- ---------------ASPUP-ACK-----------> -----ERROR(Unexpected Message)-----> --------------------------------------------------------------- --------------------------------------------------------------- 3.1.4.4 ASPM_I_SG_04 : ASPAC message handling in DOWN state of ASP --------------------------------------------------------------- Test Objective: The main aim of this scenario is to verify that IUA stack is able to handle ASPAC in DOWN state of ASP. ---------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-DOWN state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer to SG. b) Verify that the SG Discards the message. c) SG may silently discard the message or also send an Error(Unexpected Message) to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPAC------------- -----ERROR(Unexpected Message)-----> --------------------------------------------------------------- Vikas & Gayatri [Page 51] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.1.4.5 ASPM_I_SG_05 : Traffic Mode Parameter Missing in ASPAC --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that IUA stack is able to handle an ASPAC message received without the mandatory Traffic Handling mode parameter. --------------------------------------------------------------- Reference : RFC 3057, Section 4.3 --------------------------------------------------------------- Test Configuration :- A --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and SG. ASP1 is in ASP-INACTIVE state. --------------------------------------------------------------- Test Description : a) Send an ASPAC message from peer without the mandatory Traffic Mode parameter. b) Verify that SG rejects the message and ASP remains in ASP-INACTIVE state. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------------ASPAC------------- Message Rejected --------------------------------------------------------------- 3.2 QPTM Messages 3.2.1 Valid QPTM cases when ASP is Under Test --------------------------------------------------------------- 3.2.1.1 QPTM_V_ASP_01 : Link Establishment Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Link Establishment and Data Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 Vikas & Gayatri [Page 52] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke Establish Request primitive from SU. Verify that an Establish request message is sent from ASP1 to the peer. b) Send an Establish Confirm message from peer to the ASP side. Verify that an Establish confirm primitive is invoked at ASP side. c) Invoke the Data request primitive from SU. Verify that a Data request message is sent from ASP1 to the peer. d) Send a Data Indication message from peer to the ASP side. Verify that a Data Indication primitive is given to SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) Establish Request Primitive --------------------> --------Establish Request-----------> <-------Establish Confirm------------ Establish Confirm Primitive <-------------------- Data request Primitive --------------------> --------Data Request------------------> <-------Data Indication---------------- Data Indication Primitive <-------------------- --------------------------------------------------------------- --------------------------------------------------------------- 3.2.1.2 QPTM_V_ASP_02 : Link Release Request/Confirm Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Link Vikas & Gayatri [Page 53] Internet Draft IUA Conformance Test Plan Dec 2002 Release Procedures with various reasons. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke Release Request primitive from SU with reason as RELEASE_MGMT. Verify that a Release request message with reason as RELEASE_MGMT is sent from ASP1 to the peer. b) Send a Release Confirm message from peer to the ASP side. Verify that a Release confirm primitive is invoked at ASP side. c) Verify the same for reasons RELEASE_DM, RELEASE_OTHER. ---------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) Release Request Primitive --------------------> --------Release Request-----------> (reason as RELEASE_MGMT) <-------Release Confirm------------ Release Confirm Primitive <-------------------- --------------------------------------------------------------- --------------------------------------------------------------- 3.2.1.3 QPTM_V_ASP_03 : Link Release/Establish Indication Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Release/Establish Indication Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Vikas & Gayatri [Page 54] Internet Draft IUA Conformance Test Plan Dec 2002 Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke Establish Request primitive from SU. Verify that an Establish request message is sent from ASP1 to the peer. b) Send a Release Indication message from peer with reason as RELEASE_MGMT to the ASP side. Verify that a Release Indication primitive is invoked at ASP side. c) Verify the same for reasons RELEASE_PHY, RELEASE_DM, RELEASE_OTHER. d) Send an Establish Indication message from peer. Verify that an Establish Indication primitive is given to SU. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) Establish Request Primitive --------------------> --------Establish Request-----------> <-------Release Indication----------- (RELEASE_MGMT) Release Indication Primitive <-------------------- <--------Establish Indication------- Establish Indication Primitive <-------------------- --------------------------------------------------------------- --------------------------------------------------------------- 3.2.1.4 QPTM_V_ASP_04 : Unitdata Procedures --------------------------------------------------------------- Test Objective: To verify Unitdata Procedures --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- D Vikas & Gayatri [Page 55] Internet Draft IUA Conformance Test Plan Dec 2002 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke Unitdata Request primitive from SU. Verify that a Unitdata request message is sent from ASP1 to the peer. b) Verify that message padding is proper. c) Send a Unit Indication message from peer to the ASP side. Verify that a Unitdata Indication primitive is invoked at ASP side. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) Unitdata Request Primitive --------------------> --------Unitdata Request-----------> <-------Unitdata Indication--------- Unitdata Indication Primitive <-------------------- --------------------------------------------------------------- 3.2.2 Valid QPTM cases when SG is Under Test --------------------------------------------------------------- 3.2.2.1 QPTM_V_SG_01 : Link Establishment Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Establishment and Data Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively. ---------------------------------------------------------------- Vikas & Gayatri [Page 56] Internet Draft IUA Conformance Test Plan Dec 2002 Test Description : a) Send an Establish request message from peer to SG. Verify that an Establish request primitive is invoked at SG side. b) Invoke Establish Confirm primitive from SG. Verify that an Establish Confirm message is sent to the peer. c) Send a Data Request message from peer to the ASP side. Verify that Data Request primitive is invoked. d) Invoke the Data Indication primitive from SG. Verify that a Data Indication message is sent from SG to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <--------Establish Request----------- Establish Request Primitive <-------------------- Establish Confirm Primitive --------------------> -------Establish Confirm------------> <--------Data Request------------------ Data request Primitive <-------------------- Data Indication Primitive --------------------> -------Data Indication----------------> --------------------------------------------------------------- --------------------------------------------------------------- 3.2.2.2 QPTM_V_SG_02 : Link Release Request/Confirm Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Link Vikas & Gayatri [Page 57] Internet Draft IUA Conformance Test Plan Dec 2002 Release Procedures with various reasons. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively. ---------------------------------------------------------------- Test Description : a) Send a Release request message with reason as RELEASE_MGMT from peer to the SG. Verify that a Release request primitive is invoked at SG side. b) Invoke Release confirm primitive from NIF. Verify that a Release Confirm message is sent to the peer. c) Verify the same for reasons RELEASE_DM, RELEASE_OTHER --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <--------Release Request----------- (reason as RELEASE_MGMT) Release Request Primitive <-------------------- Release Confirm Primitive --------------------> -------Release Confirm------------> --------------------------------------------------------------- --------------------------------------------------------------- 3.2.2.3 QPTM_V_SG_03 : Link Release/Establish Indication Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the Release/Establish Indication Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- A Vikas & Gayatri [Page 58] Internet Draft IUA Conformance Test Plan Dec 2002 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively. ---------------------------------------------------------------- Test Description : a) Send an Establish Request message from the peer to SG. Verify that an Establish Request primitive is invoked at the SG. b) Invoke Release Indication primitive from NIF with reason as RELEASE_MGMT. Verify that a Release Indication message is sent to the peer with reason as RELEASE_MGMT. c) Verify the same for reasons RELEASE_PHY, RELEASE_DM, RELEASE_OTHER d) Invoke Establish Indication primitive from NIF. Verify that an Establish Indication message is sent to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <--------Establish Request----------- Establish Request Primitive <-------------------- Release Indication Primitive --------------------> -------Release Indication-----------> (RELEASE_MGMT) Establish Indication Primitive --------------------> --------Establish Indication--------> --------------------------------------------------------------- --------------------------------------------------------------- 3.2.2.4 QPTM_V_SG_04 : Unitdata Procedures --------------------------------------------------------------- Test Objective: To verify Unitdata Procedures Vikas & Gayatri [Page 59] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state respectively. ---------------------------------------------------------------- Test Description : a) Invoke Unitdata Indication primitive from NIF. Verify that a Unitdata Indication message is sent to the peer. b) Send a Unit Request message from peer to the SG. Verify that a Unitdata Request primitive is given to NIF. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) Unitdata Indication Primitive --------------------> --------Unitdata Indication-----------> <-------Unitdata Request--------------- Unitdata Request Primitive <-------------------- --------------------------------------------------------------- --------------------------------------------------------------- 3.2.2.5 QPTM_V_SG_05 : Mapping Interface Identifier within multiple Associations/Streams --------------------------------------------------------------- Test Objective: The main aim of this case is to check the mapping of Interface Identifier to Association/Stream. ---------------------------------------------------------------- Reference : RFC 3057, Section 1.5.1 --------------------------------------------------------------- Test Configuration :- B ---------------------------------------------------------------- Pre-requirement Condition : SCTP association (with Multiple Streams) is established between ASP1,ASP2 and SG. ASP1,ASP2 are in ASP-ACTIVE state. AS is in Loadshare mode. AS is having multiple interface identifiers say 1-5. --------------------------------------------------------------- Vikas & Gayatri [Page 60] Internet Draft IUA Conformance Test Plan Dec 2002 Test Description : a) Send a Unitdata Indication message from SG for an IID (say 1) by invoking the corresponding primitive. Check the Association(X) and Stream number(y) being used for sending data. b) Now send a Unitdata Indication message from SG for another IID (say 2) by invoking the corresponding primitive. Check the Association(P) and Stream number (q) being used for sending data. c) Algorithm for mapping data to different Association/Stream within an AS is implementation dependent. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) ------Unit Data Indication--------> (Association id X Stream y) ------Unit Data Indication--------> (Association id P Stream q) --------------------------------------------------------------- 3.3 MGMT Messages 3.3.1 MGMT cases when ASP is Under Test --------------------------------------------------------------- 3.3.1.1 MGMT_V_ASP_01 : TEI Status Request/Confirm Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the TEI Request/Confirm Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.3 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Invoke an M-TEI STATUS request API from the LM(ASP). Verify that a TEI Status request message is sent to the peer. Vikas & Gayatri [Page 61] Internet Draft IUA Conformance Test Plan Dec 2002 b) Send TEI STATUS Confirm message from peer with status as ASSIGNED. Verify that a TEI Status confirm primitive is given to LM. c) Invoke an M-TEI STATUS request API from the LM(ASP). Verify that a TEI Status request message is sent to the peer. d) Send TEI STATUS Confirm message from peer with status as UNASSIGNED. Verify that a TEI Status confirm primitive is given to LM. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-TEI-STATUS---> Request ---------TEI Status Request--------> <--------TEI Status Confirm--------- (ASSIGNED) <-------M-TEI-STATUS--- Confirm --------M-TEI-STATUS---> Request ---------TEI Status Request--------> <--------TEI Status Confirm--------- (UNASSIGNED) <-------M-TEI-STATUS--- Confirm --------------------------------------------------------------- --------------------------------------------------------------- 3.3.1.2 MGMT_V_ASP_02 : TEI Status Query/Indication Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the TEI Query/Indication Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.3 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 62] Internet Draft IUA Conformance Test Plan Dec 2002 a) Invoke an M-TEI QUERY request API from the LM(ASP). Verify that a TEI Status Query request message is sent to the peer. b) Send TEI STATUS Indication message from peer with status as ASSIGNED. Verify that a TEI Status indication primitive is given to LM. c) Invoke an M-TEI QUERY request API from the LM(ASP). Verify that a TEI Status Query request message is sent to the peer. d) Send TEI STATUS Indication message from peer with status as UNASSIGNED. Verify that a TEI Status indication primitive is given to LM. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-TEI-QUERY---> Request ---------TEI Query Request---------> <-----TEI Status Indication-------- (ASSIGNED) <-------M-TEI-STATUS--- Indication --------M-TEI-QUERY---> Request ---------TEI Query Request---------> <-----TEI Status Indication-------- (UNASSIGNED) <-------M-TEI-STATUS--- Indication --------------------------------------------------------------- 3.3.2 MGMT cases when SG is Under Test --------------------------------------------------------------- 3.3.2.1 MGMT_V_SG_01 : TEI Status Request/Confirm Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the TEI Request/Confirm Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.3 --------------------------------------------------------------- Vikas & Gayatri [Page 63] Internet Draft IUA Conformance Test Plan Dec 2002 Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-ACTIVE/ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Send TEI STATUS Request message from peer. Verify that a TEI Status request primitive is given to LM. b) Invoke an M-TEI STATUS confirm API with status as ASSIGNED from the LM(SG). Verify that a TEI Status confirm message with status as ASSIGNED is sent to the peer. c) Send TEI STATUS Request message from peer. Verify that a TEI Status request primitive is given to LM. d) Invoke an M-TEI STATUS confirm API with status as UNASSIGNED from the LM(SG). A TEI Status confirm message with status as UNASSIGNED is sent to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------TEI Status Request-------- <-------M-TEI-STATUS--- Request -------M-TEI-STATUS---> Confirm --------TEI Status Confirm---------> (ASSIGNED) <---------TEI Status Request-------- <-------M-TEI-STATUS--- Request -------M-TEI-STATUS---> Confirm --------TEI Status Confirm---------> (UNASSIGNED) --------------------------------------------------------------- Vikas & Gayatri [Page 64] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.3.2.2 MGMT_V_SG_02 : TEI Status Query/Indication Procedures --------------------------------------------------------------- Test Objective: The main aim of this case is to check the TEI Query/Indication Procedures. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.3 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. ASP1 is in ASP-ACTIVE state. ---------------------------------------------------------------- Test Description : a) Send TEI QUERY Request message from peer. Verify that a TEI Query request primitive is given to LM. b) Invoke an M-TEI STATUS Indication API with status as ASSIGNED from the LM(SG). Verify that a TEI Status Indication message with status as ASSIGNED is sent to the peer. c) Send TEI QUERY Request message from peer. Verify that a TEI Query request primitive is given to LM. d) Invoke an M-TEI STATUS Indication API with status as UNASSIGNED from the LM(SG). Verify that a TEI Status Indication message with status as UNASSIGNED is sent to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------TEI Query Request-------- <-------M-TEI-QUERY--- Request -------M-TEI-STATUS---> Indication --------TEI Status Indication---------> (ASSIGNED) <---------TEI Query Request-------- <-------M-TEI-QUERY--- Request Vikas & Gayatri [Page 65] Internet Draft IUA Conformance Test Plan Dec 2002 -------M-TEI-STATUS---> Indication --------TEI Status Indication---------> (UNASSIGNED) --------------------------------------------------------------- 3.3.3 Invalid scenario handling when SG is under test --------------------------------------------------------------- 3.3.3.1 MGMT_I_SG_01 : Invalid Version Error --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error message if it receives any message with an invalid Version. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to the SG with an invalid version say 2. b) Verify that SG generates an Error message with reason as "Invalid Version". Verify that ASP is in ASP-DOWN state. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <---------------ASPUP---------------- (Version 2) --------ERROR (Invalid Version)-----> --------------------------------------------------------------- --------------------------------------------------------------- 3.3.3.2 MGMT_I_SG_02 : Invalid Interface identifier Vikas & Gayatri [Page 66] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message for all the interface identifiers for which the AS is not configured. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A AS1 at SG is handling traffic for say IID range 1-5 ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state respectively. ---------------------------------------------------------------- Test Description : a) Send An ASPAC message from peer to the SG for IID's (1-10). b) Verify that SG sends an ASPAC ACK (IID 1-5)and Notify(AS-Active) in response. Verify that ASP1 and AS1 states are moved to ASP-ACTIVE/ AS-ACTIVE. c) Also Verify that SG sends error messages for IID's 6-10 with reason as 2 (Invalid Interface Identifier). The diagnostic Information must contain the common and IUA message headers of the offending message so that the Invalid Interface Identifier can be identified. d) Send a Unit Data Request message from peer to the SG. Verify that a Unitdata Request primitive is invoked at SG. e) Invoke the primitive for Unit Data Indication Message from NIF for say IID 1. Message should be sent to ASP1 in AS1. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------ASPAC (IID 1-10)---------- -----------ASPAC-ACK (IID 1-5)-------> -----------NOTIFY (AS-Active)--------> -----------ERROR (IID 6)-------------> -----------ERROR (IID 7)-------------> -----------ERROR (IID 8)-------------> -----------ERROR (IID 9)-------------> -----------ERROR (IID 10)------------> <-----------Unitdata Request--------- Vikas & Gayatri [Page 67] Internet Draft IUA Conformance Test Plan Dec 2002 ------------Unitdata Indication-----> --------------------------------------------------------------- --------------------------------------------------------------- 3.3.3.3 MGMT_I_SG_03 : Unsupported Message Class/Type --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if an Unsupported Message Class/Type is received in a message. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Send a message from peer to the SG with message class as 7. b) Verify that SG sends an Error Message with reason as "Unsupported Message Class". c) Send a message from peer to the SG with message class as 3 and message type as 9. d) Verify that SG sends an Error Message with reason as "Unsupported Message Type". --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------Message (Class 7)---------- -----------ERROR---------------------> (Unsupported Message Class) <----------Message (Type 9)---------- -----------ERROR---------------------> (Unsupported Message Type) --------------------------------------------------------------- --------------------------------------------------------------- 3.3.3.4 MGMT_I_SG_04 : Unsupported Traffic Handling mode Vikas & Gayatri [Page 68] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if an Unsupported Traffic Handling mode is received in a message. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state. AS is configured in override mode. ---------------------------------------------------------------- Test Description : a) Send a ASPAC message from peer to SG with Traffic Handling Mode as "Loadshare". b) Verify that SG sends an Error Message with reason as "Unsupported Traffic Handling Mode". Also Verify that the same Error message is sent to the peer if the SG doesn't support loadsharing. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------ASPAC (Loadshare)---------- -----------ERROR---------------------> (Unsupported Traffic handling Mode) --------------------------------------------------------------- --------------------------------------------------------------- 3.3.3.5 MGMT_I_SG_05 : Unexpected Message --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if a QPTM message is received in Inactive state of ASP. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state. ---------------------------------------------------------------- Test Description : a) Send a Unitdata Request message from peer to SG. Vikas & Gayatri [Page 69] Internet Draft IUA Conformance Test Plan Dec 2002 b) Verify that SG sends an Error Message with reason as "Unexpected Message". --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------Unitdata ----------------- -----------ERROR---------------------> (Unexpected Message) --------------------------------------------------------------- --------------------------------------------------------------- 3.3.3.6 MGMT_I_SG_06 : Invalid Stream Identifier --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if a Management message is received on a stream other than 0. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. SCTP Association has multiple streams. AS/ASP1 is in AS-DOWN/ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG on a stream other than 0. b) Verify that SG sends an Error Message with reason as "Invalid stream identifier". --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------ASPUP (Stream 1)----------- -----------ERROR---------------------> (Invalid Stream Identifier) --------------------------------------------------------------- Vikas & Gayatri [Page 70] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.3.3.7 MGMT_I_SG_07 : Unsupported Interface Identifier Type --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if it doesn't support text based interface Identifiers. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-INACTIVE/ASP-INACTIVE state. ---------------------------------------------------------------- Test Description : a) Send an ASPAC message having text based interface identifier. b) Verify that SG sends an Error Message with reason as "Unsupported Interface Identifier Type". --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------ASPAC (Text Based)--------- -----------ERROR---------------------> (Unsupported Interface Identifier Type) --------------------------------------------------------------- --------------------------------------------------------------- 3.3.3.8 MGMT_I_SG_08 : Refused - Management Blocking --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if the ASP is locked out for management reasons. --------------------------------------------------------------- Reference : RFC 3057, Section 3.3.3.1 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. ASP is locked out for management reasons. ---------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG. Vikas & Gayatri [Page 71] Internet Draft IUA Conformance Test Plan Dec 2002 b) Verify that SG sends an Error Message with reason as "Refused - Management Blocking". c) Verify that AS/ASP state is still AS-DOWN/ASP-DOWN. d) Unlock the ASP. e) Send an ASPUP message from peer to SG. f) Verify that SG sends an ASPUP ACK and Notify (AS-Inactive) message to the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------ASPUP -------------------- -----------ERROR---------------------> (Refused - Management Blocking) <----------ASPUP -------------------- -----------ASPUP-ACK------------------> -----------Notify (AS-Inactive)-------> --------------------------------------------------------------- 3.4 ASP Identifier Cases --------------------------------------------------------------- 3.4.1.1 ASPI_V_ASP_01 : ASP Identifier Case --------------------------------------------------------------- Test Objective: The main aim of this case is to verify ASP identifier based routing. --------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.7 --------------------------------------------------------------- Test Configuration :- B (Stack to Stack) --------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1, ASP2 and SG. AS is in Loadshare mode. ASP1 and ASP2 are in ASP-DOWN state. --------------------------------------------------------------- Test Description : Vikas & Gayatri [Page 72] Internet Draft IUA Conformance Test Plan Dec 2002 ASPUP PROCEDURES a) Invoke an M-ASP-UP request from LM for ASP1. b) ASPUP message sent from ASP1 containing ASP identifier. c) SG sends ASPUP ACK and Notify message. d) ASP Id should be present in Notify Message. e) State of ASP1 in AS1 is now marked ASP-INACTIVE. f) Invoke an M-ASP-UP request from LM for ASP2. g) ASPUP message sent from ASP2 containing ASP identifier. h) SG sends ASPUP ACK message. i) State of ASP2 in AS1 is now marked ASP-INACTIVE. ASP ACTIVE PROCEDURES a) Invoke an M-ASP-ACTIVE request from LM for ASP1. b) An ASPAC message is sent to the SG. c) SG sends an ASPAC ACK to ASP1. d) Also SG sends a Notify (AS-Active) message to ASP2 and ASP1. e) State of ASP1 in AS1 is now marked ASP-ACTIVE. f) Invoke an M-ASP-ACTIVE request from LM for ASP2. g) An ASPAC message is sent to the SG. h) SG sends an ASPAC ACK to ASP2. i) State of ASP2 in AS1 is now marked ASP-ACTIVE. UNIT DATA PROCEDURES a) Send a Unit Data Request Message from ASP1 to SG. b) Send a Unit Data Request Message from ASP2 to SG. c) Send multiple Unit Data Indication Messages from SG. They will be sent to ASP1 or ASP2 according to the Loadshare Algorithm. For example if the Algorithm is round robin, first data message may be sent to ASP1, second to ASP2 and so on. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP SG LM/NIF --------M-ASP-UP--------> Request (ASP1) -------ASPUP--------> <------ASPUP-ACK----- <-------M-ASP-UP--------- confirm (ASP1) <------NOTIFY-------- (AS-Inactive) AS1/ASP1 state is now AS-INACTIVE/ASP-INACTIVE --------M-ASP-UP--------> Request (ASP2) -------ASPUP--------> <------ASPUP-ACK----- <-------M-ASP-UP--------- confirm (ASP2) Vikas & Gayatri [Page 73] Internet Draft IUA Conformance Test Plan Dec 2002 ASP2 state is now ASP-INACTIVE -------M-ASP-ACTIVE-----> Request (ASP1) ----ASPAC (IID vikas)--> <---ASPAC-ACK (IID vikas)-- <------M-ASP-ACTIVE----- Confirm (ASP1) <------NOTIFY-------- (AS-Active) AS1/ASP1 state is now AS-ACTIVE/ASP-ACTIVE -------M-ASP-ACTIVE-----> Request (ASP2) ----ASPAC (IID vikas)-----> <---ASPAC-ACK (IID vikas)-- <------M-ASP-ACTIVE----- Confirm (ASP2) ASP2 state is now ASP-ACTIVE -------Unit Data-----> Request <-------Unit Data----- Indication <-------Unit Data----- Indication --------------------------------------------------------------- --------------------------------------------------------------- 3.4.2.1 ASPI_I_SG_01 : ASP Identifier Required --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if ASP identifier is required and ASPUP message doesn't contain the same. --------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.19 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG without the ASP identifier parameter. b) Verify that SG sends an Error Message with reason as "ASP Identifier Required". --------------------------------------------------------------- Expected Message Sequence Vikas & Gayatri [Page 74] Internet Draft IUA Conformance Test Plan Dec 2002 LM/NIF SG Peer(ASP) <----------ASPUP -------------------- -----------ERROR---------------------> (ASP Identifier Required) --------------------------------------------------------------- --------------------------------------------------------------- 3.4.2.2 ASPI_I_SG_02 : Invalid ASP Identifier --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that SG returns an Error Message if an invalid ASP identifier is received in an ASPUP message. --------------------------------------------------------------- Reference : IUA Outstanding Issues Section 3.19 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP1 and peer. AS/ASP1 is in AS-DOWN/ASP-DOWN state. ---------------------------------------------------------------- Test Description : a) Send an ASPUP message from peer to SG with an invalid ASP identifier parameter. b) Verify that SG sends an Error Message with reason as "Invalid ASP Identifier". --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) <----------ASPUP -------------------- -----------ERROR---------------------> (Invalid ASP Identifier) --------------------------------------------------------------- 3.5 Miscellaneous Cases 3.5.1 MISC cases when SG is Under Test --------------------------------------------------------------- Vikas & Gayatri [Page 75] Internet Draft IUA Conformance Test Plan Dec 2002 3.5.1.1 MISC_V_SG_01 : SCTP Restart Handling --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the SCTP Restart handling by the IUA stack. ---------------------------------------------------------------- Reference : RFC 3057 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP association is established between ASP1 and SG. ASP1 is in ASP-ACTIVE state. --------------------------------------------------------------- Test Description : a) Restart the peer(ASP) side (IUA stack). b) Verify that an SCTP_RESTART indication is invoked at the SG side. c) Verify that ASP is now marked as ASP-DOWN at SG side. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) ASP is in ASP-ACTIVE state ASP side (IUA stack) restarts SCTP association established. An SCTP_RESTART indication given to IUA by SCTP at SG side ASP is marked ASP-DOWN. --------------------------------------------------------------- --------------------------------------------------------------- 3.5.1.2 MISC_V_SG_02 : SCTP Comm-lost Handling --------------------------------------------------------------- Test Objective: The main aim of this case is to verify the SCTP Comm-Lost handling by the IUA stack. ---------------------------------------------------------------- Reference : RFC 3057 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : SCTP association is established between ASP1 and SG. ASP1 is in ASP-ACTIVE state. --------------------------------------------------------------- Test Description : a) Kill the ASP side (IUA stack). Vikas & Gayatri [Page 76] Internet Draft IUA Conformance Test Plan Dec 2002 b) After some time SCTP(SG) detects association failure via the Heartbeat procedures. c) SCTP invokes an SCTP_CDI indication towards IUA. d) Verify that ASP is brought to ASP-DOWN State. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) IUA(at SG) receives a CDI indication from SCTP ASP is brought to ASP-DOWN state at SG. --------------------------------------------------------------- --------------------------------------------------------------- 3.5.1.3 MISC_V_SG_03 : Establishing SCTP Association from SG --------------------------------------------------------------- Test Objective: The main aim of this case is to verify that it is possible to establish association from SG. ---------------------------------------------------------------- Reference : RFC 3057 --------------------------------------------------------------- Test Configuration :- A ---------------------------------------------------------------- Pre-requirement Condition : IUA stack is Initialized. SG is client and ASP is server. --------------------------------------------------------------- Test Description : a) Invoke M-SCTP Establish Request from SG. b) Verify that an SCTP Association is established with the peer. --------------------------------------------------------------- Expected Message Sequence LM/NIF SG Peer(ASP) M-SCTP ESTABLISH request -----------------------> SCTP Association Established --------------------------------------------------------------- Vikas & Gayatri [Page 77] Internet Draft IUA Conformance Test Plan Dec 2002 --------------------------------------------------------------- 3.5.1.4 MISC_V_SG_04 : Payload Protocol id as 1 --------------------------------------------------------------- Test Objective: To verify that payload protocol id 1 is filled by IUA when sending any message --------------------------------------------------------------- Reference : RFC 3057, Section 7.1 --------------------------------------------------------------- Test Configuration :- D ---------------------------------------------------------------- Pre-requirement Condition : SCTP Association is established between ASP and SG. ---------------------------------------------------------------- Test Description : a) Invoke an M-ASP-UP request from LM for ASP1. Verify that an ASPUP message is sent to the peer. b) Verify that the payload protocol identifier filled by IUA in SCTP payload is 1. --------------------------------------------------------------- Expected Message Sequence LM/SU ASP Peer(SG) --------M-ASP-UP----------> Request ---------------ASPUP--------------> --------------------------------------------------------------- 3.5.2 MISC cases when ASP is Under Test --------------------------------------------------------------- 3.5.2.1 MISC_V_ASP_01 : Multiple SG Scenario --------------------------------------------------------------- Test Objective: The main aim of this case is to check the ability of the IUA stack to reroute Data to the alternate SG if an association to one SG fails. ---------------------------------------------------------------- Reference : RFC 3057 --------------------------------------------------------------- Test Configuration :- G (Stack to Stack) ---------------------------------------------------------------- Pre-requirement Condition : SCTP association is established between ASP1 and SG1, SG2. ASP1 is in ASP-ACTIVE state via both the SG's. --------------------------------------------------------------- Vikas & Gayatri [Page 78] Internet Draft IUA Conformance Test Plan Dec 2002 Test Description : a) SG1 or Association between ASP1 and peer(SG1) goes down. In other words, IUA receives a SCTP_CDI indication from SCTP corresponding to the association for SG1. b) Invoke Unitdata request primitive from ASP. ASP should be able to route the data via peer(SG2). --------------------------------------------------------------- Expected Message Sequence LM/SU ASP SG1 SG2 <-------SCTP_COMM_LOST------- (with SG1) -----------Unit Data Request-------> --------------------------------------------------------------- 4. Acknowledgements The authors would like to thank Ken Morneault, Dipak Bash, Akhtar Iqbal, Manish Sharma, Sandeep Mahajan, Anshoo Sharma, A Anuradha for their insightful comments and suggestions. 5. References [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects' [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3] IUA (ISDN Q.921-User Adaptation Layer) RFC 3057 [4] IUA(RFC 3057)Outstanding Issues draft-ietf-sigtran-iua-imp-guide-02.txt. Morneault K. Vikas & Gayatri [Page 79] Internet Draft IUA Conformance Test Plan Dec 2002 6. Authors' Address Vikas Bhola Gayatri Singla Hughes Software Systems Electronic City, Plot 31, Sector 18 , Gurgaon 122015 Haryana, India Email: vbhola@hss.hns.com gsingla@hss.hns.com Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. | |||||||||||||||||
OpenSS7 SS7 for the Common Man |
| |||||||||||||||||
Last modified: Fri, 28 Nov 2008 10:52:01 GMT © Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved. |